[00:00] Amaranth: Compiz Cube is geometrically incorrect.... [00:00] * jdong ducks [00:00] we can report them to you here in person so you don't go through withdrawal [00:00] jdong: Die. [00:00] lol [00:00] Most people don't seem to know what a cube is anyway [00:01] Amaranth: I'm sure they'd understand right prism better ;-) [00:01] Cube, regular-polygon-based-prism. Who knows the diffderence these days? [00:01] and your screen resolution is not 1:1 so it's never a cube :P [00:01] "Compiz Isometrically Projected Right Prism (tm)" [00:01] Amaranth: we have designer ice cube trays to blame for this [00:01] * jdong files a copyright... [00:01] jdong: It's not isometrically projected :P [00:01] "yes, so what if it's shaped like a penguin, penguins are also cubes" [00:02] macslow was supposed to be making a replacement for cube [00:02] but i suck at geometry so i can't remember what it's called [00:03] What would it do differently? [00:03] support vsize === emgent`out is now known as emgent [00:04] Aaah. Stack them cubes! [00:05] hello [00:06] can we play Compiz Jenga anytime soon? [00:06] and when the stack topples X crashes? [00:06] (not that Compiz doesn't do that already anyway) === danielm_ is now known as danielm [01:09] Heya gang [01:14] Yo! bddebian! [01:14] Hi RAOF === kiko is now known as kiko-zzz [01:47] Fujitsu: well, Debian had introduced the bashism in the fix for another CVE issue [02:20] hi all! could I ask the kind MOTU people to resync the REVU uploaders keyring please? :) [02:36] Fujitsu: ping [02:36] LaserJock: Pong. [02:37] Fujitsu: what would you think about using LP's mailing list for motuscience? [02:38] LaserJock: I'm not sure why we'd perfer that over the l.u.c one. [02:38] Fujitsu, who uploaded a new VLC right before mine? [02:38] you know? [02:38] Fujitsu: cause then I would have to deal with spam clean up? :-) [02:38] i just solved all the build failures w/ it right before hand [02:39] Fujitsu: I just wondered if you had an opinion, I don't particularly care either way [02:39] LaserJock: Aha, I see. That might be a good reason. [02:40] actually [02:40] Though it does mean that anybody who wants to subscribe has to be a member of the team, and have an LP account. [02:40] yeah [02:40] well, it seems like the list never really lived up to my goal [02:40] superm1: How far before? [02:40] 2 hours [02:40] There was one a week ago.. [02:40] which was to promote discussion of science packages and their use in Ubuntu [02:41] not just be the MOTU Science mailing list [02:41] long enough for me to jump in the shower, eat breakfast and check the build log at least :) [02:41] LaserJock: That sort of didn't work :( [02:41] Fujitsu: no, not at all, neither did the IRC channel [02:41] There's another vlc security patch that Hardy needs already :( [02:41] that's why I was sort of thinking of just making it a MOTU Science thing [02:42] but well, it's not a big deal either way [02:42] if I just send all non-member emails to /dev/null rather than having me manually delete them it'd be fine :-) [02:42] Yep. [02:42] Fujitsu, already?? post that 6 CVE upload i *just& did? [02:42] I've yet to find a real non-member email that was legit [02:42] man.... [02:42] superm1: Yep. [02:42] I filed a bug on it. [02:43] listadmin takes a lot of the pain out of spam-elimination. [02:43] you want to throw that bug my way and i'll take care of that one too? [02:43] But it's still not good. [02:43] superm1: That'd be great. I'll dig it up. [02:43] figure what the hell, i've done so many builds of VLC that my ccache should be able to handle it pretty quick :) [02:44] Bug #207284 [02:44] Launchpad bug 207284 in vlc "[CVE-2008-1489] buffer overflow in MP4 demuxer in vlc 0.8.6e " [Undecided,New] https://launchpad.net/bugs/207284 [02:44] okay thanks [02:44] I can't build anything at the moment; I accidentally pretty much demolished my LVM VG last night. [02:44] dang, I have waaaay too many LP team memberships :( [03:28] superm1: It was I. Sorry, I didn't even know you were working on vlc. [03:28] TheMuso, my mistake. i didn't mark myself as working on it [03:28] luckily all the changes that were in your upload were also in mine [03:28] :) [03:28] superm1: heh right., [03:29] who is buying some food? I am hungry! [03:29] * TheMuso just had pumpkin soup for lunch. :) [03:29] nixternal, you should bring me some white castle [03:29] superm1: I could very well be a citizen of Texas before the year is up btw [03:29] oh? [03:29] how is this? [03:29] my buddy wants me to come work for his company [03:29] neat! what kind of company? [03:30] the energy company for texas [03:30] don't even know who they are...he told me about the job and the money..the rest I could care less about [03:30] haha [03:30] * nixternal checks email to see exactly where at in Texas this will be [03:32] nixternal: I guess you won't have to do much complaining about snow there. [03:32] 512 area code [03:32] superm1: ERCOT's (Electric Reliability Council of Texas) IT department. [03:32] guess where? [03:32] AUSTIN!!!! [03:32] 512 that's in Austin! [03:32] nice! [03:33] holy shiznit, I just seen that..w00t, I like Austin [03:33] just gotta follow me [03:33] i see how it is [03:33] hahaha, damn I knew that could come back to haunt me [03:33] ;p [03:34] so when you gonna know? [03:34] waiting for him to get back with me..he is coming into Chicago next weekend [03:40] ScottK2: it is snowing right now! arghhh! [03:40] Global warming? where is it at!?!?! [03:42] nixternal: You have no idea. Back when I was a kid it was so cold ... [03:42] No, wait. [03:42] nixternal: I forgot. You're old too. [03:42] back when you were a kid dinosaurs roamed the earth :p [03:42] you took baths in tar pits :) [03:43] And they tasted yummy and we didn't worry about if they had good or bad cholesterol. [03:50] * Hobbsee mutters about you old men [03:50] *cough* [03:51] bddebian: Youngster. [03:51] bddebian: mok0 is almost as much older than you as Hobbsee's age. [03:51] He'll be the old man around here soon. [03:51] you are all old! [03:52] heh [03:55] Hobbsee: Us youngsters can always learn something from these oldies. :) [03:55] MEETING IN 5 MINUTES! [03:56] there is your, well now, 4 minute warning [03:56] Like how to spell PDP-11 [03:56] im actually present for one! [03:56] i'll come. [03:56] me too! :) [03:56] a rc bugfix with a new upstream requires ffe? [03:56] if the new upstream is bug fix only, then no [03:56] TheMuso: maybe. depends if they've lost touch with reality, in addition to being old :P [03:56] if the new upstream is api/abi changes or feature changes, than yes [03:59] Bah. Back when I was young we actually had reality. [03:59] None of this virtual stuff pumped through tubes and pipes. === ember_ is now known as ember [04:27] 3~/c [04:32] hm what happened to that floating "ubuntu" screensaver? [04:32] i remember it was around in gutsy.. [04:34] oh nvm. http://ubuntuforums.org/showthread.php?t=733479. Looks like the artwork team needs to be poked === santiago-php is now known as santiago-ve [05:56] good morning [06:46] good morning dholbach :) [06:47] hi gpocentek :) [07:10] Good morning [07:10] morning dholbach, gpocentek, warp10 [07:10] hey Hobbsee [07:11] hello Hobbsee [07:11] dholbach: you missed the meeting [07:13] Hobbsee: I know - it was 5 in the morning or something [07:13] good morning [07:13] ahh [07:17] Hi [07:17] Is there a chan for mactel support ? === \sh_away is now known as \sh === Seveaz is now known as Seveas === doko_ is now known as doko === cprov-out is now known as cprov [08:22] u-u-s is quite full again [08:22] holy cow :) [08:23] dholbach: welcome to u-u-s [08:24] oh it's not as if I never saw it before :) [08:28] * soren glazes out the window, pondering how u-u-s can be "full" :) === dholbach_ is now known as dholbach === dholbach_ is now known as dholbach === asac_ is now known as asac === dholbach_ is now known as dholbach === auntypattern_ is now known as auntypattern === auntypattern_ is now known as auntypattern [09:57] hello! [09:57] may I ask, is REVU closed for new submissions? [09:58] I've managed to dput a package into REVU several hours ago, but it does not show up on http://revu.tauware.de/ [10:28] artfwo: is your key in the REVU keyring? [10:28] yes, it should be [10:29] I have added myself to ~ubuntu-universe-contributors just yesterday [10:29] artfwo: ah, there needs to be a manual sync before you can dput I believe [10:30] and as REVU is a low priority at the current point in the cycle I don't think that is being done [10:31] james_w: but can I still upload my package, so it will get reviewed in order to prepare it for hardy+1 at least? [10:31] hi folks [10:32] artfwo: you will be able to do once that sync is done yes, but there won't be many (any?) people reviewing at this point in the cycle. [10:32] hi sistpoty|work [10:32] hi james_w [10:32] sistpoty|work: artfwo is just asking about uploading to REVU, he only join -contributors yesterday, so his key won't be included yet, is that correct? [10:33] james_w: yes... I'll start a keyring sync [10:33] will I need to re-upload my package afterwise after the sync? [10:33] <\sh> ScottK: let's sync phpgroupware from debian.... [10:34] artfwo: I think so [10:34] okay, thanks guys! [10:35] artfwo: no, I'll just put it back once the sync is done [10:36] okay :) [10:36] thanks sistpoty|work [10:36] np [10:42] superm1: Looks like we can't get vlc demoted, so we'll have to drop the x264 stuff from it. [10:43] <\sh> grmpf [10:45] <\sh> guys, what about removing multiverse package wink from the archives, according to this bug #208125 it won't run in any way, because of missing libexpat.so.0 and with libexpat.so.1 it doesn't work, too [10:45] Launchpad bug 208125 in wink "wink: error while loading shared libraries: libexpat.so.0" [Undecided,New] https://launchpad.net/bugs/208125 [10:46] remove it! down with multiverse1 [10:46] * persia seconds Hobbsee [10:47] Kill kill kill. [10:48] \sh: have you tried rebuilding it? [10:58] artfwo: supercollider is on revu now [10:59] thanks sistpoty|work! [10:59] just hope I will get some reviews to make a better package :) [10:59] artfwo: There's already a supercollider in the archives. Are you sure you want it on REVU? [11:00] persia: there was indeed an old version, but now it's gone from both debian and ubuntu [11:00] * persia is reminded of the removal, and checks why [11:00] so I decided to make my own binary [11:01] artfwo: Did you do the special no 64-bit dance to fix the issue with upstream storing two 32-bit values in a 64-bit integer? [11:02] (where one of the values was a pointer) [11:02] persia: of course, I have built an i386-only package, just like it should be [11:02] * persia thought it should work fine for powerpc, and lpia [11:03] indeed [11:04] I guess I'll have to make an update to enable building for these architectures [11:05] artfwo: If I remember correctly, some of the binaries could be run on 64-bit, just not others. I don't remember which were which, but you may want to enable them for people with multiple machines. [11:06] persia: yes, the synthesis server part may be compiled and runs on amd64 but it does not make much sense without the client part [11:06] As for why it was removed, see http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=pkg&data=supercollider&archive=no&version=&dist=unstable 363430 is 64-bit issues, 444537 is a now-solved scons bug, 446667 is a meta-bug, but 458856 likely deserves some attention. [11:06] artfwo: What if I have a 64-bit server humming away in a closet, and use a 32-bit low-noise workstation in my studio? [11:07] but it's the server that produces the actual sound [11:08] so in order to make some noise, you have to run the server on the machine with speakers [11:08] Depends on your setup. You could have an ADAT card in your computer room, and pipe the fiber back to your studio. [11:09] and that machine would require jackd installed, which cannot be controlled remotely [11:09] Anyway, this was very contentious last time it was made to not work on 64-bit, so it's likely safer to support 64-bit where possible. [11:10] jackd can be controlled remotely. qjackctl is an x client, and can be displayed safely over the network. [11:11] Also, if you've not already, best to keep the changelog, patches, etc. from https://launchpad.net/ubuntu/+source/supercollider/20060416-1build1 [11:11] that means, that everything else in the setup (like jack-rack, jamin, etc.) have to be x-clients and displayed through the lan [11:12] No. You run your supercollider client locally on your workstation. The tone generator runs the server, and passes it back to your mixer via ADAT. [11:12] yes, I'm aware of that build, but it's very very old [11:12] supercollider has changed very much since, so I have packaged it from scratch [11:12] Yes. It needs heaps of updating, but some of the packaging might be useful (e.g. package split, manpages, etc.). Also, it's considered polite to keep the changelog when reviving things, even if the code is significantly altered. [11:13] and reinventing the packaging will reduce your changes for an FFe ;) [11:13] s/changes/chances/ [11:14] does FF mean feature freeze? [11:16] persia: the package split in 20060416-1 does not suit the current supercollider versions [11:17] artfwo: If you can resurrect it, and close the outstanding bugs that got it rejected, lots of people would likely be happy. While I don't have a 32-bit station around to run the client these days, there were a number of vocal users last time I was chasing the packages, and I suspect they'd appreciate an effort to retain it for hardy. [11:17] artfwo: Then fix it :) [11:17] persia: and I have just checked, there's a shlib cross-dependency between scsynth and sclang [11:18] but I shall try to resurrect the package, if you advise so :) [11:19] Even if all you can keep is debian/changelog and parts of debian/copyright, it's better that way (as long as you document the changes in the new debian/changelog). The idea is to avoid surprising users, and telling them what has changed since the version they last used is the easiest way to do that. [11:19] indeed [11:21] then I shall update the REVU upload with another version based on the original package as soon as possible [11:22] artfwo: Thank for being flexible about that. For faster attention, I'd recommend filing a bug about it, providing a pointer to the updated package, using the phrases "regression from gutsy" and "feature freeze exception" in the bug description, and subscribing motu-release. [11:23] but there already is a bug! [11:23] Excellent! It just needs editing then :) [11:24] I shall set it as "in progress" and assign to myself then === gouki_ is now known as gouki [11:31] thanks for the attention persia and sistpoty|work, time to get to work! :) [11:31] artfwo: Thanks for updating the package [11:33] would give one more advice? is it okay to rename the toplevel source directory in .orig.tar.gz-archive? [11:34] Ideally you want the orig.tar.gz archive to be exactly what upstream provides. You more likely want to adjust debian/rules to accomodate the upstream changes than to change the new orig.tar.gz [11:35] but dh_make requires, that source directory must be package-version in lower case, while supercollider is just "SuperCollider-Source" with mixed case and no version number [11:36] artfwo: I personally disagree with at least 30% of dh_make, if not more. Anyway, dpkg-source is smart enough to deal with that in most cases. [11:36] artfwo: bah, forget what dh_make wants... dpkg-source (which will actually do the unpacking) will usually get it right ;) [11:37] but dh_make is recommened almost everywhere in the packaging docs through the Ubuntu wiki :-/ [11:38] artfwo: If someone doesn't understand packaging at all, dh_make can be a fast way to build an example for discussion. This avoids needing to investigate special cases when using other packages as examples. [11:39] Unfortunately, nobody who does a lot of packaging uses dh_make, so there's not a lot of motivation to get it to follow commonly-accepted best practices. [11:39] so, will the package builders work, if I just put debian/ into the source folder? [11:39] * persia wonders if anyone wants to volunteer to give dh_make a thourough review and prepare a revised version for introduction the day the intrepid archives open [11:40] artfwo: They ought. [11:40] okay, one more question, if I'm not bothering you [11:40] My personal style of packaging (very rarely used) is to unpack upstream, rename the provided directory, rename the tar file, manually create the four required files, and start seeing what breaks when I try to debuild. [11:41] !ask [11:41] Please don't ask to ask a question, ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely answer. :-) [11:41] thanks :) can I simply disable building certain subpackages for amd64 in debian/control instead of specifying all supported arches? [11:41] e.g. am I allowed to write something like "!amd64"? [11:42] That's a hard question. I think the answer is "no", but you might want to ask on #launchpad, as Soyuz might have some handler for it. [11:44] Anyway, I don't think you want to do that, as there are more 64-bit arches than just amd64. [11:44] alright, thank you once again for your help! :) [11:44] (and there is no guarantee that your package will actually work with any new architectures that might be released) [11:44] indeed [11:45] well, my approach would still be to set it to arch:any, and have it fail in debian/rules, if there is an unsupported architecture (as that is imo easiest for the porters) [11:45] wow, that was a knowledge-stuffed talk [11:46] sistpoty|work: The issue with supercollider is that it doesn't FTBFS, it just has strange pointer errors, and loses data when used on a 64-bit arch. [11:46] One can force FTBFS, but that clogs up all the FTBFS detectors... [11:47] persia: heh, yeah, that's why I'd make it fail in debian/rules (I vaguely remember that the arch field does the same, but am not too sure about that) [11:47] (or one can mangle P-a-s, but that's brute force, and requires manual demangling to undo, for which fewer people have access than to debian/control) [11:47] well, p-a-s is responsible in the end, not debian/control [11:48] sistpoty|work: checking the arch and passing an error condition counts as FTBFS for all the checkers we have though. [11:48] good point [11:48] but is there any way to check for the current buildarch in rules? [11:49] Aren't most packages not listed in P-a-s? I thought that was only used where special circumstances were required. On the other hand, this may have been an accidental Soyuz feature, now considered a bug, and fixed. [11:49] persia: not too sure... actually [11:50] sistpoty|work: For Debian, I do believe P-a-s rules (although I've only spent 10s of hours with the dak source, so I am certainly not very authoritative) [12:35] Hey [12:35] hey Iulian, effie_jayx [13:21] <\sh> persia: p-a-s comes first...even if debian/control tells something else... [13:21] <\sh> persia: e.g. wine has arch: any ... but p-a-s forces it only to coimpile on i386 and amd645 [13:22] <\sh> amd64 even [13:22] \sh: Right, but is every package not arch:any or arch:all required to be in P-a-s for Ubuntu to avoid FTBFS? [13:22] <\sh> persia: no [13:22] * persia wants an am645 [13:22] <\sh> persia: that you can see from the p-a-s file in cvs.debian.org [13:23] \sh: Soyuz != dak, and I seem to remember some variance in P-a-s as well (although there are efforts to synchronise) [13:23] :) [13:24] <\sh> persia: as ubuntu shares the p-a-s file with debian, I don't think the algorithm is different from debian...I think it's just another test..."look up p-a-s first, if the package is in, check the arch and do not allow compilation for other arch then those mentioned here...forget all about debian/control" (debian/control will be parsed first, of course) [13:25] persia: that's exactly what happens for ubuntu primary archive, although we explicitly ignore P-a-s for PPAs. [13:25] \sh: It's in sync now? Excellent. Anyway, I still believe it's better to handle it in debian/control than in debian/rules or P-a-s. [13:25] cprov: Thanks for the confirmation. [13:26] <\sh> persia: you mean ubuntu and debians p-a-s? hmm..when they are not in sync, why everybody tells us: we share p-a-s with debian [13:27] persia: P-a-s is synchronised hourly with the debian cvs. [13:27] \sh: This is the first time I've discussed P-a-s since the feisty cycle: I'm clearly out of date (and happy about it: synchronisation is good) [13:28] <\sh> persia: tbh...debian/control would make sense, if package maintainer would know all about the archs the package _could_ build on [13:28] hi cprov \sh [13:28] \sh: So, for an Ubuntu-local package, for which there isn't a maintainer, do you agree debian/control is best practice? [13:29] emgent: hi there. [13:29] <\sh> persia: sure...if we know that it only compiles on i386 and not on amd64 and when it's not in p-a-s :) sure debian/control [13:30] \sh: Based on cprov's statements, I'm certain that an Ubuntu-local package can never be in P-a-s. [13:31] As for which architectures to list in debian/control, I'd hope the default would be the full set, minus anything known not to work, rather than starting with i386, and adding architectures when someone files a bug. [13:32] persia: I think that the main question is: "will it never compile on other archs than i386 ?". If the answer is yes, than crop the debian/control, if you are unsure leave with the FTBFS for a while until you can get the source fixed. [13:32] note that I didn't even mention P-a-s, because it's too much of hack, IMO. [13:32] <\sh> persia: hmm...most of the time I think this is correct...but think about this: srcpackage_0.0.1-0ubuntu1 arch: any -> compiles on i386 and amd64 but not on sparc hppa lpia , some debian maintainer who is following ubuntu takes the package...and is requesting p-a-s listing of this package via elmo/lamont/infinity -> peng...p-a-s- package ;) [13:32] cprov: I'd agree with that. My experience is that almost nothing is i386-only: if nothing else it typically works for lpia [13:33] persia: yes, "any" is ideal. [13:33] \sh: If that ever happens, we're failing to pay enough attention to our FTBFS checkers. As we now track every LP build, and have full-archive rebuilds (not just main), I think we deserve it if we make that sort of mistake. [13:34] <\sh> persia: it happend with wine...:) someone said: amd64 is not building ... so they pushed wine to p-a-s and suddenly the amd64 build never showed up again [13:34] cprov: Ideal, yes. Unfortunately, there's still a heap of stuff that isn't 64-bit safe, so it needs to be limited to i386, powerpc, lpia, and sparc (plus more if anyone wants to submit to Debian) [13:35] Hi i would like to add an application to the ubuntu repository [13:35] \sh: That's just laziness. The right way to do it is to update the package. Unfortunately, that's not always politically feasible in Debian [13:35] !newpackages [13:35] Sorry, I don't know anything about newpackages - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [13:35] Bah. [13:35] <\sh> persia: and now...I need to know what it needs to add wine p-a-s lpia entry :) [13:35] \sh: Shouldn't that have been tracked in a bug? [13:36] <\sh> persia: I don't know...i never hunted for this action..I wasn't interessted...wine64 wasn't building, and wine32 on 64bit wasn#t working these days [13:37] <\sh> so actually I was happy to not get ftbfs on amd64 mails [13:37] chewit: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [13:37] \sh: I'd argue that if you were getting lots of FTBFS mails, and you knew it wasn't easily fixed, you ought to have updated debian/control [13:38] <\sh> persia: nope...the discussion was : we need to make wine running on amd64...no matter what it takes..but I think someone from debian thought differently :) [13:40] * persia believes updating a package to match reality while working on a solution is best practice, but should be catching up on the email backlog rather than arguing about insufficiently tranquilised dehydrated fruit [13:42] cody-somerville: congrats for your MOTUship :) [13:42] Thanks pochu :) [13:43] <\sh> persia: :) [13:47] Heya gang [13:47] cody-somerville: congrats [13:47] Thanks RainCT :) [13:47] Yeah, congrats cody-somerville :) [13:47] :D [13:48] <\sh> cody-somerville: let xubuntu rock dude :) [13:48] \o/ [13:50] <\sh> damn... [13:50] <\sh> what do i have to do with baltix...nothing [13:51] cody-somerville: congrats! [13:52] \sh: you're marked as a maintainer for them aswell? [13:52] ScottK: If you have a moment later could you have a look at https://bugs.launchpad.net/bugs/206280 please? [13:52] Launchpad bug 206280 in lm-sensors "[hardy] Error opening config file: /etc/sensors.conf" [Undecided,Confirmed] [13:52] Thanks jpatrick :) [13:55] <\sh> jpatrick: it's not that problem...I don't want to see fixed bugs in ubuntu anymore, I don't care about baltix ;) [13:56] <\sh> jpatrick: but my "working bugs list" grows exponentially with all the same bugs in baltix ... which are not fixed ;) [13:56] \sh: unsubscribe from them... [13:57] <\sh> persia: I#m not subscribed...those are all "related bugs" [13:58] \sh: We get bugmail on "related bugs" now? That explains why I have increasing difficulty catching up after an absence. Please file a bug :) [13:59] <\sh> persia: nope...but go to your LP page -> bugs -> the first view is "related bugs" page...and you'll find all the crap again for "baltix" or other distros (I'm not talking about upstream bugs) [14:00] I'm looking for a sponsor for bug 206180, anyone interested ? [14:00] Launchpad bug 206180 in prism "Please sponsor prism 0.8+svn20071115r8030-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/206180 [14:01] \sh: I see what you mean. I fixed some of those for Dapper. [14:02] When did xpm become deprecated? [14:04] persia, https://bugzilla.mozilla.org/show_bug.cgi?id=410215 [14:04] Mozilla bug 410215 in Widget: Gtk "GTK's .xpm decoding is weird, stop using XPM as the default window icon" [Normal,Resolved: fixed] [14:04] * persia thinks that was a bug in GTK rather than mozilla, and was fixed in the wrong place [14:05] anyway, all the mozilla tools moved away from xpm [14:06] Makes sense. SNG/PNG tends to look better anyway (although SNG is easier to patch). [14:08] <\sh> persia: so...it would be nice, if you can get only "upstream" and "ubuntu" related stuff, but not from derivatives [14:09] \sh: Depends. I'd be happier to see bugs in LP marked "Fix Released" for kanotix, rather than random IRC comments. [14:09] <\sh> persia: ok..then it should configurable :) [14:10] <\sh> +be [14:12] hi! [14:13] \sh: just wanted to know, do you get mail notifications from launchpad on claws-mail's bugs? :) [14:13] <\sh> colinl: depends :) [14:13] \sh: On a per-user and per-derivative/upstream basis. [14:14] <\sh> persia: yepp [14:14] <\sh> colinl: which bug you think of? [14:14] \sh: then I have to tell you, I prepared a list of upstream bugfixes that would be nice to have in 8.04 if possible :) : [14:14] https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/208230 [14:14] Launchpad bug 208230 in claws-mail "Fix of the most annoying bugs in 3.3.1" [Undecided,New] [14:15] <\sh> colinl: thx :) [14:16] thanks to you :) [14:16] it's nice that you handle this package :) [14:16] <\sh> colinl: I'm trying to deal with it during the weekend...hopefully nothing has to be changed for the lpia patch :) [14:17] I hope not ! === iceman__ is now known as iceman [14:17] I'll check, even :) [14:17] <\sh> colinl: actually I don't but as you know..the last uploader is the mule to do the next :) [14:17] :-)) [14:17] <\sh> damn...I'm doomed...just got rid of wine, now I get everything else...gnucash claws-mail...;) [14:17] * \sh needs a coffee [14:17] hehe [14:18] <\sh> colinl: so it's only claws-mail or also extra-plugins? [14:18] only claws-mail [14:18] extra-plugins shouldn't even require a rebuild, no .h change [14:18] <\sh> phew...I'm a lucky guy ;) [14:20] <\sh> colinl: but thx a lot for this list...this is a workflow which could be really copied from other upstream projects :) [14:20] <\sh> so now for some coffee and nicotine [14:20] :) [14:24] \sh: no conflict with the lpia (or other) patches... Just one thing, I made my patches -p0, I'll change that to -p1 patches [14:30] persia, do you take prism or should I keep looking for someone else? [14:31] <\sh> colinl: no need...if I know it's p0 its ok for me [14:32] \sh: ah, ok, well, I just did it anyway :) [14:32] \sh: thanks a bunch! [14:32] fta: Better to keep looking for other people. I'm still behind on that which I am obliged to do, and will be a bit before I'm chasing things I'd like to do. [14:33] ok [14:33] (although I'm now a prism user, and will likely catch it in my pre-FinalFreeze marathon, if it doesn't get hit first) [14:35] it's been in the sponsor queue for 4 days so i'm starting to doubt anyone will step up unless I beg :( [14:35] <\sh> colinl: no thank you for your work :) [14:37] :) [14:37] fta: Sponsor queue processing is just slow right now. Begging likely won't help much, although some non-regular sponsors may notice it. On the other hand, some regular sponsors make a point of not sponsoring those who beg too much. [14:38] i've just asked once so far [14:38] Which is probably good, as it likely encourages the first group, and doesn't hit the threshold for the second :) [14:39] anyway, nm. it's always the same song. I'm now used to it. [15:04] * \sh doesn't know enough of prism to judge if it's useful to sponsor now at this time of the release [15:13] dholbach; ping [15:14] bobbo: pong [15:14] dholbach; Bug #195806, i have emailed upstream a couple of times but have had no reply [15:14] Launchpad bug 195806 in purrr "please update purrr to version 0.8 [FFe-granted]" [Undecided,In progress] https://launchpad.net/bugs/195806 [15:15] bobbo: :-( [15:15] bobbo: can we extract patches to fix single issues? [15:16] dholbach; im not really sure what issues upstream had with it [15:17] dholbach; actually, upstream says "knew it to be internally ugly and still not thoroughly tested", which we cant exactly patch :/ [15:17] bobbo: can't we ask to release a pre-release? [15:17] hey dholbach, long time no see [15:18] hi schweeb - indeed - how are you doing? [15:18] great [15:18] dholbach; ask who? Upstream? (Sorry if nooby question) [15:18] been super busy at work, no time for linux play :) [15:18] I got a new laptop this week, so it's about time to get back into things though [15:19] bobbo: yes [15:19] rock and roll [15:19] :-) [15:19] dholbach; will fire off another email and pray they reply :) [15:20] bobbo: good luck [15:20] what's the MOTU population at now? [15:21] https://launchpad.net/~ubuntu-dev says 111 members [15:22] well done [15:22] * cody-somerville is the 111th member. [15:24] congrats [15:24] :-) [15:32] dholbach: jcastro is in charge of this UOW? i have e-mailed jono as it said on the wiki page :S [15:34] nxvl: just mail to jorge too :) [15:34] ok [15:34] :D [15:34] gracias [15:35] cody-somerville: congratulation ;-D [15:36] hi nxvl [15:37] hi dholbach nxvl [15:37] Thanks sebner :) [15:37] thanks schweeb :) [15:38] dholbach: bitte shoen [15:38] dholbach: it's hard to imagine jorge being responsible for things. [15:38] james_w: hi! [15:38] emgent: :D [15:38] jcastro: did you just hear schweeb? [15:38] haha, I've said it to his face before I'm sure [15:40] I could drive over to his house in half an hour and say it to his face if you'd like :) [15:40] dholbach: schweeb has too much time on his hands, feel free to assign him multiple MOTU tasks. === ogra_cmpc is now known as ogra [15:41] schweeb: get to work! [15:41] lol [15:41] http://wiki.ubuntu.com/5-A-Day [15:41] maybe I'll set up a VM [15:41] http://daniel.holba.ch/really-fix-it [15:41] I still have Vista on my laptop [15:41] there are apparently still driver issues w/ the sound card in this beast [15:42] ScottK: (or someone from ~ubuntu-release): could you please unsubscribe motu-release from bug #194919 and set it to confirmed instead of invalidating it? kthnxbye [15:42] Launchpad bug 194919 in openal "libopenal needs replacement" [Undecided,Invalid] https://launchpad.net/bugs/194919 [15:42] jcastro: VMWare or VPC? [15:43] siretart: Looking [15:45] <\sh> schweeb: excuses excuses... [15:46] siretart: Done. [15:47] thnx [15:47] <\sh> colinl: wow...one bug attachment to fix them all...rock [15:47] \sh: lol [15:47] my other one is this - my 64GB SSD drive is filling up pretty quickly :) [15:48] <\sh> schweeb: use ubuntu-mobile setup ... ;) [15:49] <\sh> well..i shouldn't chat...I should fixing claws-mail [15:50] heh [15:52] \sh: that should take care of everything reported since 3.3.1 in upstream tracker, debian, ubuntu and fedora trackers :) [15:56] \sh: I've sent the same tarball to the other soon-to-be-released distros :) [16:00] \sh: What do you think about bumping the wine backort to .58? Please comment in Bug #195896 [16:00] Launchpad bug 195896 in gutsy-backports "Please backpart Wine 0.9.56" [Undecided,New] https://launchpad.net/bugs/195896 [16:01] dholbach, jcastro, jono: I've got a proposal for a Python Packaging HowTo session for OpenWeek, would that be suitable for it? I thought that would fit better in DeveloperWeek, but as there's a Merge session I'm unsure [16:02] pochu: best to ask jcastro :) [16:02] I think he's highlighted :) [16:03] pochu: if not I'd love to make it a MOTU School session [16:04] james_w: that sounds good too if OpenWeek isn't suitable, as I guess the next DeveloperWeek will be in some time [16:06] yeah, I expect it will be a while [16:07] <\sh> colinl: rocking :) === kiko-zzz is now known as kiko [16:09]