[00:00] <jdong> Amaranth: Compiz Cube is geometrically incorrect....
[00:00]  * jdong ducks
[00:00] <slangasek> we can report them to you here in person so you don't go through withdrawal
[00:00] <Amaranth> jdong: Die.
[00:00] <jdong> lol
[00:00] <Amaranth> Most people don't seem to know what a cube is anyway
[00:01] <jdong> Amaranth: I'm sure they'd understand right prism better ;-)
[00:01] <RAOF> Cube, regular-polygon-based-prism.  Who knows the diffderence these days?
[00:01] <Amaranth> and your screen resolution is not 1:1 so it's never a cube :P
[00:01] <jdong> "Compiz Isometrically Projected Right Prism (tm)"
[00:01] <slangasek> Amaranth: we have designer ice cube trays to blame for this
[00:01]  * jdong files a copyright...
[00:01] <RAOF> jdong: It's not isometrically projected :P
[00:01] <slangasek> "yes, so what if it's shaped like a penguin, penguins are also cubes"
[00:02] <Amaranth> macslow was supposed to be making a replacement for cube
[00:02] <Amaranth> but i suck at geometry so i can't remember what it's called
[00:03] <RAOF> What would it do differently?
[00:03] <Amaranth> support vsize
[00:04] <RAOF> Aaah.  Stack them cubes!
[00:05] <emgent> hello
[00:06] <jdong> can we play Compiz Jenga anytime soon?
[00:06] <jdong> and when the stack topples X crashes?
[00:06] <jdong> (not that Compiz doesn't do that already anyway)
[01:09] <bddebian> Heya gang
[01:14] <RAOF> Yo!  bddebian!
[01:14] <bddebian> Hi RAOF
[01:47] <blueyed> Fujitsu: well, Debian had introduced the bashism in the fix for another CVE issue
[02:20] <artfwo> hi all! could I ask the kind MOTU people to resync the REVU uploaders keyring please? :)
[02:36] <LaserJock> Fujitsu: ping
[02:36] <Fujitsu> LaserJock: Pong.
[02:37] <LaserJock> Fujitsu: what would you think about using LP's mailing list for motuscience?
[02:38] <Fujitsu> LaserJock: I'm not sure why we'd perfer that over the l.u.c one.
[02:38] <superm1> Fujitsu, who uploaded a new VLC right before mine?
[02:38] <superm1> you know?
[02:38] <LaserJock> Fujitsu: cause then I would have to deal with spam clean up? :-)
[02:38] <superm1> i just solved all the build failures w/ it right before hand
[02:39] <LaserJock> Fujitsu: I just wondered if you had an opinion, I don't particularly care either way
[02:39] <Fujitsu> LaserJock: Aha, I see. That might be a good reason.
[02:40] <LaserJock> actually
[02:40] <Fujitsu> 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] <LaserJock> yeah
[02:40] <LaserJock> well, it seems like the list never really lived up to my goal
[02:40] <Fujitsu> superm1: How far before?
[02:40] <superm1> 2 hours
[02:40] <Fujitsu> There was one a week ago..
[02:40] <LaserJock> which was to promote discussion of science packages and their use in Ubuntu
[02:41] <LaserJock> not just be the MOTU Science mailing list
[02:41] <superm1> long enough for me to jump in the shower, eat breakfast and check the build log at least :)
[02:41] <Fujitsu> LaserJock: That sort of didn't work :(
[02:41] <LaserJock> Fujitsu: no, not at all, neither did the IRC channel
[02:41] <Fujitsu> There's another vlc security patch that Hardy needs already :(
[02:41] <LaserJock> that's why I was sort of thinking of just making it a MOTU Science thing
[02:42] <LaserJock> but well, it's not a big deal either way
[02:42] <LaserJock> if I just send all non-member emails to /dev/null rather than having me manually delete them it'd be fine :-)
[02:42] <Fujitsu> Yep.
[02:42] <superm1> Fujitsu, already?? post that 6 CVE upload i *just& did?
[02:42] <LaserJock> I've yet to find a real non-member email that was legit
[02:42] <superm1> man....
[02:42] <Fujitsu> superm1: Yep.
[02:42] <Fujitsu> I filed a bug on it.
[02:43] <Fujitsu> listadmin takes a lot of the pain out of spam-elimination.
[02:43] <superm1> you want to throw that bug my way and i'll take care of that one too?
[02:43] <Fujitsu> But it's still not good.
[02:43] <Fujitsu> superm1: That'd be great. I'll dig it up.
[02:43] <superm1> 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] <Fujitsu> Bug #207284
[02:44] <ubotu> 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] <superm1> okay thanks
[02:44] <Fujitsu> I can't build anything at the moment; I accidentally pretty much demolished my LVM VG last night.
[02:44] <LaserJock> dang, I have waaaay too many LP team memberships :(
[03:28] <TheMuso> superm1: It was I. Sorry, I didn't even know you were working on vlc.
[03:28] <superm1> TheMuso, my mistake.  i didn't mark myself as working on it
[03:28] <superm1> luckily all the changes that were in your upload were also in mine
[03:28] <superm1> :)
[03:28] <TheMuso> superm1: heh right.,
[03:29] <nixternal> who is buying some food? I am hungry!
[03:29]  * TheMuso just had pumpkin soup for lunch. :)
[03:29] <superm1> nixternal, you should bring me some white castle
[03:29] <nixternal> superm1: I could very well be a citizen of Texas before the year is up btw
[03:29] <superm1> oh?
[03:29] <superm1> how is this?
[03:29] <nixternal> my buddy wants me to come work for his company
[03:29] <superm1> neat! what kind of company?
[03:30] <nixternal> the energy company for texas
[03:30] <nixternal> 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] <superm1> haha
[03:30]  * nixternal checks email to see exactly where at in Texas this will be
[03:32] <ScottK2> nixternal: I guess you won't have to do much complaining about snow there.
[03:32] <nixternal> 512 area code
[03:32] <nixternal> superm1: ERCOT's (Electric Reliability Council of Texas) IT department.
[03:32] <nixternal> guess where?
[03:32] <nixternal> AUSTIN!!!!
[03:32] <superm1> 512 that's in Austin!
[03:32] <superm1> nice!
[03:33] <nixternal> holy shiznit, I just seen that..w00t, I like Austin
[03:33] <superm1> just gotta follow me
[03:33] <superm1> i see how it is
[03:33] <nixternal> hahaha, damn I knew that could come back to haunt me
[03:33] <nixternal> ;p
[03:34] <superm1> so when you gonna know?
[03:34] <nixternal> waiting for him to get back with me..he is coming into Chicago next weekend
[03:40] <nixternal> ScottK2: it is snowing right now! arghhh!
[03:40] <nixternal> Global warming? where is it at!?!?!
[03:42] <ScottK2> nixternal: You have no idea.  Back when I was a kid it was so cold ...
[03:42] <ScottK2> No, wait.
[03:42] <ScottK2> nixternal: I forgot.  You're old too.
[03:42] <nixternal> back when you were a kid dinosaurs roamed the earth :p
[03:42] <nixternal> you took baths in tar pits :)
[03:43] <ScottK2> 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] <bddebian> *cough*
[03:51] <ScottK2> bddebian: Youngster.
[03:51] <ScottK2> bddebian: mok0 is almost as much older than you as Hobbsee's age.
[03:51] <ScottK2> He'll be the old man around here soon.
[03:51] <nixternal> you are all old!
[03:52] <bddebian> heh
[03:55] <TheMuso> Hobbsee: Us youngsters can always learn something from these oldies. :)
[03:55] <nixternal> MEETING IN 5 MINUTES!
[03:56] <nixternal> there is your, well now, 4 minute warning
[03:56] <StevenK> Like how to spell PDP-11
[03:56] <superm1> im actually present for one!
[03:56] <superm1> i'll come.
[03:56] <nixternal> me too! :)
[03:56] <ember_> a rc bugfix with a new upstream requires ffe?
[03:56] <nixternal> if the new upstream is bug fix only, then no
[03:56] <Hobbsee> TheMuso: maybe.  depends if they've lost touch with reality, in addition to being old :P
[03:56] <nixternal> if the new upstream is api/abi changes or feature changes, than yes
[03:59] <ScottK2> Bah.  Back when I was young we actually had reality.
[03:59] <ScottK2> None of this virtual stuff pumped through tubes and pipes.
[04:27] <TheMuso> 3~/c
[04:32] <superm1> hm what happened to that floating "ubuntu" screensaver?
[04:32] <superm1> i remember it was around in gutsy..
[04:34] <superm1> oh nvm.  http://ubuntuforums.org/showthread.php?t=733479.  Looks like the artwork team needs to be poked
[05:56] <dholbach> good morning
[06:46] <gpocentek> good morning dholbach :)
[06:47] <dholbach> hi gpocentek :)
[07:10] <warp10> Good morning
[07:10] <Hobbsee> morning dholbach, gpocentek, warp10
[07:10] <warp10> hey Hobbsee
[07:11] <gpocentek> hello Hobbsee
[07:11] <Hobbsee> dholbach: you missed the meeting
[07:13] <dholbach> Hobbsee: I know - it was 5 in the morning or something
[07:13] <dholbach> good morning
[07:13] <Hobbsee> ahh
[07:17] <bersace> Hi
[07:17] <bersace> Is there a chan for mactel  support ?
[08:22] <dholbach> u-u-s is quite full again
[08:22] <dholbach> holy cow :)
[08:23] <Hobbsee> dholbach: welcome to u-u-s
[08:24] <dholbach> 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" :)
[09:57] <artfwo> hello!
[09:57] <artfwo> may I ask, is REVU closed for new submissions?
[09:58] <artfwo> 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] <james_w> artfwo: is your key in the REVU keyring?
[10:28] <artfwo> yes, it should be
[10:29] <artfwo> I have added myself to ~ubuntu-universe-contributors just yesterday
[10:29] <james_w> artfwo: ah, there needs to be a manual sync before you can dput I believe
[10:30] <james_w> and as REVU is a low priority at the current point in the cycle I don't think that is being done
[10:31] <artfwo> 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] <sistpoty|work> hi folks
[10:32] <james_w> 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] <james_w> hi sistpoty|work
[10:32] <sistpoty|work> hi james_w
[10:32] <james_w> 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] <sistpoty|work> james_w: yes... I'll start a keyring sync
[10:33] <artfwo> will I need to re-upload my package afterwise after the sync?
[10:33] <\sh> ScottK: let's sync phpgroupware from debian....
[10:34] <james_w> artfwo: I think so
[10:34] <artfwo> okay, thanks guys!
[10:35] <sistpoty|work> artfwo: no, I'll just put it back once the sync is done
[10:36] <artfwo> okay :)
[10:36] <james_w> thanks sistpoty|work
[10:36] <sistpoty|work> np
[10:42] <Fujitsu> 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] <ubotu> Launchpad bug 208125 in wink "wink: error while loading shared libraries: libexpat.so.0" [Undecided,New] https://launchpad.net/bugs/208125
[10:46] <Hobbsee> remove it!  down with multiverse1
[10:46]  * persia seconds Hobbsee
[10:47] <Fujitsu> Kill kill kill.
[10:48] <sistpoty|work> \sh: have you tried rebuilding it?
[10:58] <sistpoty|work> artfwo: supercollider is on revu now
[10:59] <artfwo> thanks sistpoty|work!
[10:59] <artfwo> just hope I will get some reviews to make a better package :)
[10:59] <persia> artfwo: There's already a supercollider in the archives.  Are you sure you want it on REVU?
[11:00] <artfwo> 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] <artfwo> so I decided to make my own binary
[11:01] <persia> 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] <persia> (where one of the values was a pointer)
[11:02] <artfwo> 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] <artfwo> indeed
[11:04] <artfwo> I guess I'll have to make an update to enable building for these architectures
[11:05] <persia> 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] <artfwo> 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] <persia> 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] <persia> 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] <artfwo> but it's the server that produces the actual sound
[11:08] <artfwo> so in order to make some noise, you have to run the server on the machine with speakers
[11:08] <persia> Depends on your setup.  You could have an ADAT card in your computer room, and pipe the fiber back to your studio.
[11:09] <artfwo> and that machine would require jackd installed, which cannot be controlled remotely
[11:09] <persia> 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] <persia> jackd can be controlled remotely.  qjackctl is an x client, and can be displayed safely over the network.
[11:11] <persia> Also, if you've not already, best to keep the changelog, patches, etc. from https://launchpad.net/ubuntu/+source/supercollider/20060416-1build1
[11:11] <artfwo> 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] <persia> 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] <artfwo> yes, I'm aware of that build, but it's very very old
[11:12] <artfwo> supercollider has changed very much since, so I have packaged it from scratch
[11:12] <persia> 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] <sistpoty|work> and reinventing the packaging will reduce your changes for an FFe ;)
[11:13] <sistpoty|work> s/changes/chances/
[11:14] <artfwo> does FF mean feature freeze?
[11:16] <artfwo> persia: the package split in 20060416-1 does not suit the current supercollider versions
[11:17] <persia> 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] <persia> artfwo: Then fix it :)
[11:17] <artfwo> persia: and I have just checked, there's a shlib cross-dependency between scsynth and sclang
[11:18] <artfwo> but I shall try to resurrect the package, if you advise so :)
[11:19] <persia> 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] <artfwo> indeed
[11:21] <artfwo> then I shall update the REVU upload with another version based on the original package as soon as possible
[11:22] <persia> 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] <artfwo> but there already is a bug!
[11:23] <persia> Excellent!  It just needs editing then :)
[11:24] <artfwo> I shall set it as "in progress" and assign to myself then
[11:31] <artfwo> thanks for the attention persia and sistpoty|work, time to get to work! :)
[11:31] <persia> artfwo: Thanks for updating the package
[11:33] <artfwo> would give one more advice? is it okay to rename the toplevel source directory in .orig.tar.gz-archive?
[11:34] <persia> 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] <artfwo> 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] <persia> 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] <sistpoty|work> artfwo: bah, forget what dh_make wants... dpkg-source (which will actually do the unpacking) will usually get it right ;)
[11:37] <artfwo> but dh_make is recommened almost everywhere in the packaging docs through the Ubuntu wiki :-/
[11:38] <persia> 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] <persia> 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] <artfwo> 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] <persia> artfwo: They ought.
[11:40] <artfwo> okay, one more question, if I'm not bothering you
[11:40] <persia> 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] <persia> !ask
[11:41] <ubotu> 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] <artfwo> thanks :) can I simply disable building certain subpackages for amd64 in debian/control instead of specifying all supported arches?
[11:41] <artfwo> e.g. am I allowed to write something like "!amd64"?
[11:42] <persia> 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] <persia> Anyway, I don't think you want to do that, as there are more 64-bit arches than just amd64.
[11:44] <artfwo> alright, thank you once again for your help! :)
[11:44] <persia> (and there is no guarantee that your package will actually work with any new architectures that might be released)
[11:44] <artfwo> indeed
[11:45] <sistpoty|work> 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] <artfwo> wow, that was a knowledge-stuffed talk
[11:46] <persia> 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] <persia> One can force FTBFS, but that clogs up all the FTBFS detectors...
[11:47] <sistpoty|work> 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] <persia> (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] <sistpoty|work> well, p-a-s is responsible in the end, not debian/control
[11:48] <persia> sistpoty|work: checking the arch and passing an error condition counts as FTBFS for all the checkers we have though.
[11:48] <sistpoty|work> good point
[11:48] <artfwo> but is there any way to check for the current buildarch in rules?
[11:49] <persia> 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] <sistpoty|work> persia: not too sure... actually
[11:50] <persia> 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] <Iulian> Hey
[12:35] <jpatrick> 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] <persia> \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] <persia> \sh: Soyuz != dak, and I seem to remember some variance in P-a-s as well (although there are efforts to synchronise)
[13:23] <cody-somerville> :)
[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] <cprov> persia: that's exactly what happens for ubuntu primary archive, although we explicitly ignore P-a-s for PPAs.
[13:25] <persia> \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] <persia> 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] <cprov> persia: P-a-s is synchronised hourly with the debian cvs.
[13:27] <persia> \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] <emgent> hi cprov \sh
[13:28] <persia> \sh: So, for an Ubuntu-local package, for which there isn't a maintainer, do you agree debian/control is best practice?
[13:29] <cprov> 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] <persia> \sh: Based on cprov's statements, I'm certain that an Ubuntu-local package can never be in P-a-s.
[13:31] <persia> 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] <cprov> 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] <cprov> 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] <persia> 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] <cprov> persia: yes, "any" is ideal.
[13:33] <persia> \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] <persia> 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] <chewit> Hi i would like to add an application to the ubuntu repository
[13:35] <persia> \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] <persia> !newpackages
[13:35] <ubotu> Sorry, I don't know anything about newpackages - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[13:35] <persia> Bah.
[13:35] <\sh> persia: and now...I need to know what it needs to add wine p-a-s lpia entry :)
[13:35] <persia> \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] <persia> chewit: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[13:37] <persia> \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] <pochu> cody-somerville: congrats for your MOTUship :)
[13:42] <cody-somerville> Thanks pochu :)
[13:43] <\sh> persia: :)
[13:47] <bddebian> Heya gang
[13:47] <RainCT> cody-somerville: congrats
[13:47] <cody-somerville> Thanks RainCT :)
[13:47] <bddebian> Yeah, congrats cody-somerville :)
[13:47] <cody-somerville> :D
[13:48] <\sh> cody-somerville: let xubuntu rock dude :)
[13:48] <cody-somerville> \o/
[13:50] <\sh> damn...
[13:50] <\sh> what do i have to do with baltix...nothing
[13:51] <jpatrick> cody-somerville: congrats!
[13:52] <jpatrick> \sh: you're marked as a maintainer for them aswell?
[13:52] <RainCT> ScottK: If you have a moment later could you have a look at https://bugs.launchpad.net/bugs/206280 please?
[13:52] <ubotu> Launchpad bug 206280 in lm-sensors "[hardy] Error opening config file: /etc/sensors.conf" [Undecided,Confirmed]
[13:52] <cody-somerville> 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] <persia> \sh: unsubscribe from them...
[13:57] <\sh> persia: I#m not subscribed...those are all "related bugs"
[13:58] <persia> \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] <fta> I'm looking for a sponsor for bug 206180, anyone interested ?
[14:00] <ubotu> Launchpad bug 206180 in prism "Please sponsor prism 0.8+svn20071115r8030-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/206180
[14:01] <persia> \sh: I see what you mean.  I fixed some of those for Dapper.
[14:02] <persia> When did xpm become deprecated?
[14:04] <fta> persia, https://bugzilla.mozilla.org/show_bug.cgi?id=410215
[14:04] <ubotu> 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] <fta> anyway, all the mozilla tools moved away from xpm
[14:06] <persia> 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] <persia> \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] <colinl> hi!
[14:13] <colinl> \sh: just wanted to know, do you get mail notifications from launchpad on claws-mail's bugs? :)
[14:13] <\sh> colinl: depends :)
[14:13] <persia> \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] <colinl> \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] <colinl> https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/208230
[14:14] <ubotu> 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] <colinl> thanks to you :)
[14:16] <colinl> 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] <colinl> I hope not !
[14:17] <colinl> 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] <colinl> :-))
[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] <colinl> hehe
[14:18] <\sh> colinl: so it's only claws-mail or also extra-plugins?
[14:18] <colinl> only claws-mail
[14:18] <colinl> 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] <colinl> :)
[14:24] <colinl> \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] <fta> 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] <colinl> \sh: ah, ok, well, I just did it anyway :)
[14:32] <colinl> \sh: thanks a bunch!
[14:32] <persia> 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] <fta> ok
[14:33] <persia> (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] <fta> 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] <colinl> :)
[14:37] <persia> 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] <fta> i've just asked once so far
[14:38] <persia> Which is probably good, as it likely encourages the first group, and doesn't hit the threshold for the second :)
[14:39] <fta> 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] <bobbo> dholbach; ping
[15:14] <dholbach> bobbo: pong
[15:14] <bobbo> dholbach; Bug #195806, i have emailed upstream a couple of times but have had no reply
[15:14] <ubotu> Launchpad bug 195806 in purrr "please update purrr to version 0.8 [FFe-granted]" [Undecided,In progress] https://launchpad.net/bugs/195806
[15:15] <dholbach> bobbo: :-(
[15:15] <dholbach> bobbo: can we extract patches to fix single issues?
[15:16] <bobbo> dholbach; im not really sure what issues upstream had with it
[15:17] <bobbo> dholbach; actually, upstream says "knew it to be internally ugly and still not thoroughly tested", which we cant exactly patch :/
[15:17] <dholbach> bobbo: can't we ask to release a pre-release?
[15:17] <schweeb> hey dholbach, long time no see
[15:18] <dholbach> hi schweeb - indeed - how are you doing?
[15:18] <schweeb> great
[15:18] <bobbo> dholbach; ask who? Upstream? (Sorry if nooby question)
[15:18] <schweeb> been super busy at work, no time for linux play :)
[15:18] <schweeb> I got a new laptop this week, so it's about time to get back into things though
[15:19] <dholbach> bobbo: yes
[15:19] <dholbach> rock and roll
[15:19] <dholbach> :-)
[15:19] <bobbo> dholbach; will fire off another email and pray they reply :)
[15:20] <dholbach> bobbo: good luck
[15:20] <schweeb> what's the MOTU population at now?
[15:21] <dholbach> https://launchpad.net/~ubuntu-dev says 111 members
[15:22] <schweeb> well done
[15:22]  * cody-somerville is the 111th member.
[15:24] <schweeb> congrats
[15:24] <dholbach> :-)
[15:32] <nxvl> dholbach: jcastro is in charge of this UOW? i have e-mailed jono as it said on the wiki page :S
[15:34] <dholbach> nxvl: just mail to jorge too :)
[15:34] <nxvl> ok
[15:34] <nxvl> :D
[15:34] <dholbach> gracias
[15:35] <sebner> cody-somerville: congratulation ;-D
[15:36] <james_w> hi nxvl
[15:37] <emgent> hi dholbach nxvl
[15:37] <cody-somerville> Thanks sebner :)
[15:37] <cody-somerville> thanks schweeb :)
[15:38] <nxvl> dholbach: bitte shoen
[15:38] <schweeb> dholbach: it's hard to imagine jorge being responsible for things.
[15:38] <nxvl> james_w: hi!
[15:38] <nxvl> emgent: :D
[15:38] <dholbach> jcastro: did you just hear schweeb?
[15:38] <schweeb> haha, I've said it to his face before I'm sure
[15:40] <schweeb> I could drive over to his house in half an hour and say it to his face if you'd like :)
[15:40] <jcastro> dholbach: schweeb has too much time on his hands, feel free to assign him multiple MOTU tasks.
[15:41] <dholbach> schweeb: get to work!
[15:41] <schweeb> lol
[15:41] <dholbach> http://wiki.ubuntu.com/5-A-Day
[15:41] <schweeb> maybe I'll set up a VM
[15:41] <dholbach> http://daniel.holba.ch/really-fix-it
[15:41] <schweeb> I still have Vista on my laptop
[15:41] <schweeb> there are apparently still driver issues w/ the sound card in this beast
[15:42] <siretart> 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] <ubotu> Launchpad bug 194919 in openal "libopenal needs replacement" [Undecided,Invalid] https://launchpad.net/bugs/194919
[15:42] <schweeb> jcastro: VMWare or VPC?
[15:43] <ScottK> siretart: Looking
[15:45] <\sh> schweeb: excuses excuses...
[15:46] <ScottK> siretart: Done.
[15:47] <siretart> thnx
[15:47] <\sh> colinl: wow...one bug attachment to fix them all...rock
[15:47] <schweeb> \sh: lol
[15:47] <schweeb> 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] <schweeb> heh
[15:52] <colinl> \sh: that should take care of everything reported since 3.3.1 in upstream tracker, debian, ubuntu and fedora trackers :)
[15:56] <colinl> \sh: I've sent the same tarball to the other soon-to-be-released distros :)
[16:00] <ScottK> \sh: What do you think about bumping the wine backort to .58?  Please comment in Bug #195896
[16:00] <ubotu> Launchpad bug 195896 in gutsy-backports "Please backpart Wine 0.9.56" [Undecided,New] https://launchpad.net/bugs/195896
[16:01] <pochu> 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] <dholbach> pochu: best to ask jcastro :)
[16:02] <pochu> I think he's highlighted :)
[16:03] <james_w> pochu: if not I'd love to make it a MOTU School session
[16:04] <pochu> james_w: that sounds good too if OpenWeek isn't suitable, as I guess the next DeveloperWeek will be in some time
[16:06] <james_w> yeah, I expect it will be a while
[16:07] <\sh> colinl: rocking :)
[16:09] <RainCT> Adri2000: hm.. can I have access to that server you said (for MoM testing)?
[16:09] <protonchris> murrayc: ping
[16:09] <murrayc> protonchris: pong
[16:10] <protonchris> Thanks for your note on the glom bug.  Yeah, I should of said that the new cairo caused the problem.
[16:10] <murrayc> No problem. I'm just pedantic.
[16:11] <murrayc> Thanks for your work on the Glom packages.
[16:12] <protonchris> I had to laugh this morning.  I got all of the packages that glom depends on updated and then cairomm breaks due to a new cairo
[16:13] <protonchris> No problem.  I really want glom to work well in hardy.
[16:14] <protonchris> murrayc: It looks like a patch for the current version of cairomm in hardy would fix the problem.  What do you think?
[16:15] <murrayc> protonchris: It should be harmless,if you can't wait for the fix in cairo.
[16:16] <murrayc> protonchris: By the way, you can usually find me and jonner (the cairomm maintainer) on #c++ on irc.gimp.org.
[16:17] <protonchris> murrayc: good to know.
[16:19] <protonchris> murrayc: my only concern is how long it will take for a new cairo version.
[16:19] <murrayc> protonchris: Fair enough.
[16:23] <Technoviking> looking for some packaging help, is anyone free?
[16:25] <ScottK> Technoviking: Just ask questions.  People may have time to answer specifics, but aren't up for an open ended helping session.
[16:26] <jpatrick> !ask | Technoviking
[16:26] <ubotu> Technoviking: 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. :-)
[16:26] <Technoviking> trying to build a package for audacious-skins (converted xmms-skins)
[16:27] <Technoviking> get the following error with debuild
[16:27] <RainCT> Technoviking: if it's a question just ask..
[16:27] <Technoviking> This package has a Debian revision number but there does not seem to be an appropriate original tar file or .orig directory in the parent directory; (expected audacious-skins_0.6..orig.tar.gz or audacious-skins-0.6.orig)
[16:27] <Technoviking> the two .. seem weird
[16:28] <james_w> so, it's looking for audacious-skins_0.6..orig.tar.gz in the parent directory
[16:28] <james_w> so you must rename the upstream tarball to be that.
[16:28] <james_w> do you have an upstream tarball?
[16:28] <Technoviking> converted xmms-skins taball to audacious-skins tarball
[16:29] <james_w> ah, I've just noticed what you mean by weird
[16:29] <\sh> cu later
[16:30] <james_w> check debian/changelog, I think you'll find the version number on the top line ends with a .
[16:30] <Technoviking> building from audacious-skins-0.6 dir
[16:31] <Technoviking> DOH!!!, that was it:)
[16:32] <Technoviking> and how do I get by debsign: gpg error occurred!  Aborting.... error have gpg install and configure
[16:36] <james_w> Technoviking: do you have a gpg key?
[16:36] <ScottK> Technoviking: Either match the email address and comment in the key exactly or use -k and feed it the keyid you want it to use.
[16:37] <protonchris> murrayc: Actually, I think patching cairo might make more sense since the API change make break other things.
[16:38] <Technoviking> so debuild -S -k <keyid>?
[16:38] <james_w> yep
[16:38] <murrayc> protonchris: That's also sensible.
[16:39] <ScottK> Technoviking: Yes, but no space between -k and the keyid
[16:39] <Adri2000> RainCT: sure, I will /query you
[16:40] <Technoviking> sweet, works great
[16:52] <Technoviking> where is instruction to propose a package for universe?
[16:52] <ScottK2> !revu | Technoviking
[16:52] <ubotu> Technoviking: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[16:53] <ScottK2> Technoviking: We aren't looking at new packages until after Hardy releases unless they are somehow really urgent for the distro.
[16:53] <Technoviking> ScottK, ok I will put in it my ppa for now
[17:00] <dholbach> have a great weekend everybody
[17:01] <jpatrick> dholbach: du auch!
[17:01] <dholbach> danke jpatrick :)
[17:01]  * jpatrick thinks that wasn't right in a way..
[17:01] <dholbach> it was fine :-)
[17:02] <jpatrick> :) ah, been ages since I did German
[17:02] <dholbach> enjoy the weekend
[17:36] <LaserJock> has anybody had problems with FTBFS in the last day or so?
[17:38] <LaserJock> the ghemical sync FTBFS on all arches because of:
[17:38] <LaserJock> The following packages have unmet dependencies:
[17:38] <LaserJock>   libmopac7-dev: Depends: libmopac7-1gf (= 1.13-2) but it is not going to be installed
[17:38] <LaserJock> but we've had 1.13-2 for almost a week
[17:44] <protonchris> murrayc: I just commented on bug 205701 .  Let me know if I am barking up the wrong tree.
[17:44] <ubotu> Launchpad bug 205701 in cairomm "Latest hardy cairomm is broken" [Undecided,Confirmed] https://launchpad.net/bugs/205701
[17:46] <sistpoty|work> LaserJock: hm... I cannot install build-deps on my hardy-chroot on spooky as well *shrug*
[17:47] <LaserJock> sistpoty|work: any build deps or those particular build deps?
[17:47] <sistpoty|work> LaserJock: apt-get build-dep ghemical
[17:47] <sistpoty|work> LaserJock: that fails
[17:47] <LaserJock> sistpoty|work: it fails on libmopac7?
[17:48] <colinl> bye, see you
[17:48] <sebner> sistpoty|work: audacious is ready :) I suppose the ACKs were also valid for the -2 ?
[17:48] <sistpoty|work> LaserJock: no, it fails on libghemical-dev
[17:48] <sistpoty|work> sebner: yes
[17:49] <sistpoty|work> LaserJock: that's interesting, I just installed libghemical-dev: Setting up libmopac7-1 (1.13-1
[17:49] <sistpoty|work> +)
[17:49] <sistpoty|work> where does that come from?
[17:49] <sebner> sistpoty|work: nice :)
[17:49] <LaserJock> sistpoty|work: well, these are all gfortran packages
[17:50] <LaserJock> I believe libghemical is in binary NEW because of needing a rename
[17:50] <LaserJock> so ghemical should fail on libghemical if anything
[17:50] <LaserJock> but libmopac7-1 (1.13.2) has been built for almost a week and is not in NEW
[17:50] <LaserJock> so I don't understand why it would fail on that
[17:50] <ScottK2> sebner: I new revision doesn't need an FFe unless you add features.
[17:51] <sistpoty|work> LaserJock: I guess I figure now: the old libghemical-dev gets installed, and it draws in the old libmopac7-1, which conflicts with libmopac7-1gf
[17:51] <LaserJock> ohhhh
[17:51] <sistpoty|work> LaserJock: hence it says libmopac7-1gf cannot get installed in soyuz *g*
[17:51] <LaserJock> of course!
[17:52] <sistpoty|work> (which could have been a lot easier to spot, if apt would give a little bit more hints what goes wrong *g*)
[17:52] <LaserJock> phew, the Universe is preserved!
[17:52] <sistpoty|work> :)
[17:53] <sebner> ScottK: ah true. sry :)
[17:54] <sistpoty|work> LaserJock: oh, seems like pitti is already gone :/
[17:55] <sistpoty|work> and that's what I'm doing right now as well... heading home. cya
[18:03] <jcastro> pochu: I like that idea, feel free to add it to the Prep page for OpenWeek
[18:10] <ScottK2> Only 10 packages left in Bug #204895.  Get them while they're hot.  Ping me if you need sponsoring.
[18:10] <ubotu> Launchpad bug 204895 in harvestman "Packages failed archive rebuild test possibly due to python-central transition" [Medium,Fix released] https://launchpad.net/bugs/204895
[18:14] <pochu> jcastro: added
[18:15] <jcastro> pochu: I see you on an old changelog for monodevelop, do you know if anyone is looking after it at all?
[18:15] <jcastro> even a PPA would be sufficient
[18:20] <pochu> jcastro: slomo__ knows of someone looking into it I think (I don't remember who was)
[18:20] <jcastro> k thanks
[18:38] <mario_limonciell> slangasek, pitti appears to have left already.  Do you know why we're not able to demote VLC to multiverse?  Fujitsu mentioned something on it, but I wasn't around when he said it
[18:40] <slangasek> mario_limonciell: ... to multiverse?  does it no longer belong in universe?
[18:41] <mario_limonciell> it hasn't for some time apparently.
[18:41] <mario_limonciell> it's got x264 statically part of the build
[18:41] <mario_limonciell> it should have been demoted some time ago
[18:41] <slangasek> and x264 is one of the taboo codecs?
[18:41] <mario_limonciell> x264 itself lives in multiverse
[18:41] <slangasek> ok
[18:42] <slangasek> well, I see that freeplayer is a reverse-dependency in universe.  I'm not aware that this is a reason why it can't be demoted, though
[18:43] <mario_limonciell> well the other option is to drop x264 support from it to avoid this conflict
[18:43] <mario_limonciell> so whichever you think is the better solution
[19:49]  * ScottK2 tries again ....
[19:50] <ScottK2> Bug #204895 has ~10 packages that need to be checked for changes needed due to recent python-central changes.
[19:50] <ubotu> Launchpad bug 204895 in harvestman "Packages failed archive rebuild test possibly due to python-central transition" [Medium,Fix released] https://launchpad.net/bugs/204895
[19:50] <ScottK2> These are pretty easy to spot in the builid logs and have relatively obvious solutions.
[19:50] <ScottK2> It you are new and want to get into packaging, this is a good place to start.
[19:50] <ScottK2> Ping me if you have questions.
[20:03] <sebner> ScottK: ping ^^
[20:06] <sebner> ScottK: ah sry. doesn't matter anymore ..
[20:07] <ScottK> sebner: ?
[20:07] <ScottK> Did you get it figured out?
[20:09] <sebner> ScottK: yes ^^
[20:13] <auntypattern> ScottK:  I haven't even finished reading the docs yet, and know next to nothing about packaging - can I volunteer ;) now or should I wait till I know enough to be dangerous?
[20:14] <ScottK2> auntypattern: You are always welcome to give it a try.
[20:14] <ScottK2> I'm glad to help as I have time.
[20:15] <ScottK2> The first step in that bug is to pick one of the packages not marked Fix Release, In Progress, on Invalid and then look up the build log and see why it failed to build.
[20:15] <auntypattern> ScottK: Ok will start there
[20:50] <ScottK2> sebner: What is your wammu debdiff meant to accomplish?
[20:51] <sebner> ScottK: build
[20:51] <sebner> ScottK: try to build it without the debdiff. FTBFS
[20:51] <ScottK2> sebner: Think about what change you made and what difference it'll make.
[20:52] <sebner> ScottK2: the difference is that it now builds. Or do I missed something?
[20:53] <ScottK2> I'm test building the current package now, but from the diff it looks like you removed two lines that were already commented out.
[20:54] <sebner> ScottK2: ah damn. That's my fault. I test builded it and it FTBFS and then I tried to comment it out and it worked. Then I prepared the debdiff. sry
[20:55] <ScottK2> sebner: OK.  Delete that one from the bug and ping me when you have a new one ready.
[20:55] <ScottK2> sebner: No problem.  This is how you learn.
[20:56] <ScottK2> sebner: Less here is always look at the debdiff after you make it to make sure it's what you thought you were getting.
[20:56] <ScottK2> Less/Lesson
[20:56] <sebner> ScottK2: Yeah I *always* check my debdiffs but it seems that I overread it -.-
[20:57] <ScottK2> ... carefully ... then
[20:59] <sebner> ScottK: updated. (only removed the "#")
[21:01] <sebner> ScottK2: ah but I found a mistake. Shouldn it be python-central (>= 0.6) at the builddep-indep?
[21:01] <ScottK2> sebner: Yes.
[21:01] <sebner> ScottK: now I'm ashamed
[21:01] <ScottK2> You figured it out, so don't be.
[21:02] <sebner> well I'm not a *total* beginner and it's my 3rd debdiff ....
[21:02] <ScottK2> sebner: Should python-central be build-dep or build-dep-indep?
[21:04] <sebner> ScottK2: indep!?
[21:04] <ScottK2> sebner: Why?
[21:05] <sebner> ScottK2: python-central 0.6 uses now a package and tool independent directory
[21:05] <sebner> to store the architecture independent files.
[21:05] <ScottK2> sebner: Yes, in general.  When would it go into build-dep anyway?
[21:06] <POX_> build-dep-indep is uses to build architecture independent packages
[21:06] <POX_> used
[21:06] <soren> When you're dealing with python extensions.
[21:06] <soren> ScottK2: ^
[21:06] <sebner> ^^. thx guys
[21:07] <sebner> ScottK: or when we would decide to only support i386?
[21:08] <POX_> you still need to use Build-Depends to f.e. make `debian/rules clean` command working
[21:08] <ScottK2> sebner: What POX_ said (his version is better than what I was typing).
[21:09] <sebner> k
[21:09] <ScottK2> Got the new debdiff yet?
[21:11] <sebner> currently uploading. LP is slowly today (at least for me)
[21:11] <ScottK2> It seems that way every day for me.
[21:11] <sebner> ^^
[21:12] <sebner> uploaded
[21:20]  * ScottK2 looks
[21:20]  * ScottK2 waits for LP to load ....
[21:25] <sebner> ScottK2: can't they speed it up somehow?
[21:27] <ScottK2> sebner: I try not to worry to much about Launchpad.  It's a closed development project that in my experience isn't particularly open to outsiders.  I just do the best I can and don't worry.
[21:27] <sebner> ScottK2: may  be the best we can do
[21:28] <ScottK2> sebner: Uploaded.  Thank you for your contribution to Ubuntu.
[21:29] <sebner> ScottK: I haven't heard that for a long time ^^. More should work on the u-u-s queue :P . However thanks for you help and the hints /me should do some more to gain experience with that
[21:50] <sebner> ScottK2: still around?
[22:11] <ScottK2> sebner: Here now for a moment
[22:12] <sebner> ScottK2: If a package builds without doing anything. should I set it to "Won't fix" or should I bump python-control in debian/control and look at the debian/rules ...
[22:13] <ScottK2> sebner: Look at the build logs from the rebuild test and see why it failed.  If it failed due to buildd problems (there are some of those) or for other reasons unrelated to python-central, mark it invalid.
[22:14] <sebner> ah. true. thanks
[22:15] <ScottK2> If it failed for another reasons, fix those.
[22:15] <sebner> ScottK: xD it failed on hpppa. I'm a dunce
[22:15] <ScottK2> sebner: Which package?
[22:16] <sebner> ScottK2: https://edge.launchpad.net/ubuntu/+source/revelation/0.4.11-3ubuntu1
[22:17] <ScottK2> sebner: Why did the build fail?
[22:18] <sebner> ScottK2: python-gnome2-desktop . unmet dependencies. I think because of the gnome final upgrade
[22:19] <ScottK2> sebner: On hppa or the one from the rebuild test listed in the bug?
[22:19] <sebner> ScottK2: on hppa
[22:20] <ScottK2> sebner: OK.  I'll look at that one.  You tell me why the one from the rebuild test failed.
[22:22] <tsmithe> could someone tell me if the test on grep in http://paste.ubuntu-nl.org/61417/ is correct? (i'm not sure about exit status in this case)
[22:22] <tsmithe> (line 9)
[22:22] <tsmithe> er, 12
[22:23] <ScottK2> sebner: Would a give-back on hppa work now?
[22:23] <sebner> ScottK2: sure
[22:25] <ScottK2> sebner: Why?
[22:26] <sebner> ScottK: because now we have 2.22.0-0ubuntu1 what means >=  2.21.3-0ubuntu1
[22:26] <ScottK2> sebner: Did it build on hppa?
[22:27] <sebner> ScottK2: at the python-central rebuild?
[22:29] <ScottK2> sebner: python-gnome2-desktop. In the archive.
[22:30] <sebner> ScottK2: yes
[22:32] <ScottK2> Then hop over to #ubuntu-devel and ask infinity to please give back revelation on hppa.
[22:32] <sebner> k :)
[22:34] <ScottK2> sebner: Now keep an eye on it and see if it works this time.
[22:35] <sebner> yep
[22:35] <ScottK2> You can mark that one invalid in the python-central bug
[22:36] <sebner> cool. thanks :)
[22:37] <cool> sebner, for what?
[22:37] <sebner> argh. damn it
[22:37] <sebner> cool: sry ^^
[22:37] <cool> heh
[22:39] <sebner> ScottK2: btw, what's the difference between  Won't fix and Invalid?
[22:40]  * sistpoty believes that dholbach should be a bug contact for hugs (sorry, bad joke)
[22:40] <cool> haha
[22:40] <cool> siretart, you talking about yesterdays hugs?
[22:40] <sistpoty> sebner: won't fix means, that the bug is there, but it won't get fixed
[22:41] <sebner> sistpoty: what could be a reason for that?
[22:41] <sistpoty> cool: actually I'm just generally kidding (as there is a source package called hugs, and there's also one called happy btw.)
[22:41] <sistpoty> sebner: let me find an example
[22:42] <cool> i know such bug
[22:42] <aquo> i want to document my package selection and make installations with a defined package-set reproducible ...
[22:42] <aquo> i know about "dpkg --get-selections" and so on ..
[22:43] <sistpoty> sebner: bug #194574 for example. it's present, but it's decided to not getting fixed because it has negative side effects
[22:43] <ubotu> Launchpad bug 194574 in cdbs "can cause broken symlinks in /usr/share/doc" [Low,Won't fix] https://launchpad.net/bugs/194574
[22:43] <aquo> i am thinking about creating meta-packages for hosting on my ppa
[22:43] <cool> i have lost all hopes that this would be fixed bug #43154
[22:43] <ubotu> Launchpad bug 43154 in mesa "freezes with 3D applications on VIA Unichrome K8M800, KM400" [High,Confirmed] https://launchpad.net/bugs/43154
[22:44] <cool> damn you VIA :x
[22:44] <sebner> sistpoty: ah, I see. thx :)
[22:44] <sistpoty> aquo: I guess that's a tough one... you could of course add everything from get-selections to a dependency of a meta-package, but that would nail it down to specific libraries as well
[22:44] <aquo> dpkg --get-selections is not modular enough for me, i want to differentiate betwee packages i need and their deps.
[22:45] <aquo> i defined around 40 different tasks and the packages i need for them
[22:45] <sistpoty> aquo: I wouldn't know of anything smart enough to find root nodes (i.e. packages, which draw in the necessary dependencies) though apart from manual selection
[22:46] <aquo> sistpoty: that is not the problems, i know all the root nodes, i am master of graphviz.
[22:46] <sistpoty> aquo: ah, so what's the problem then?
[22:47] <aquo> i am just thinking if creating metapackages is the right way to do so.
[22:47] <aquo> i took a look at the source of ubuntu-meta and build-essential ...
[22:47] <sistpoty> aquo: what do you want to achieve actually?
[22:47] <james_w> it sounds like a reasonable solution to me
[22:48] <james_w> I don't know if equivs can do this easily for you
[22:48] <aquo> james_w: i read about seeds ...
[22:48] <aquo> and i am not sure if it would better to create seeds, and create the meta-packages from seeds.
[22:48] <james_w> I don't think seeds are what you want, as apt doesn't understand what they are I believe
[22:49] <james_w> well, that's just an extra step isn't it?
[22:49] <james_w> you can just create one source package, and then build several binary packages that depend on what you want.
[22:49] <aquo> yes, but would it help me to master install cds with my own package-selection and their deps?
[22:50] <aquo> ubuntu-meta uses some scripts to create the package lists from the seeds ...
[22:51] <james_w> ah, for cds. then seeds might be the way to go
[23:09] <sistpoty> hm... disk space on sparky is getting very rare... someone who'd like to nuke a few old uploads? (maybe nixternal?)
[23:14] <RainCT> sistpoty: already migrated?
[23:15] <sistpoty> RainCT: nope, not really urgent
[23:15] <sistpoty> RainCT: my current plan is to get a bigger disk for myself, and then sort out a 200Gb disk for spooky. (sata ctrl'er already in spooky, check dmesg)
[23:16] <sistpoty> RainCT: and after that eventually migrate ;)
[23:16] <RainCT> sounds like a good plan :)
[23:17] <sistpoty> yeah... reason to buy new hardware -> good plan for me :)
[23:19] <Fujitsu> sistpoty: We can free up a couple of GB by hardlinking or removing some urbanterror-data uploads.
[23:19] <sistpoty> Fujitsu: either is fine, I guess
[23:20] <sistpoty> Fujitsu: since there is a RFS in debian for urbanterror, I guess I'll nuke those
[23:21] <Fujitsu> 3.9GB in the various urbanterror-data uploads.
[23:21] <Fujitsu> Ouch.
[23:21] <sistpoty> meh... I should have fixed nuking on sparky as well *g*
[23:24] <RainCT> sistpoty: what's wrong there? it worked for me somewhat like 2 weeks ago..
[23:25] <sistpoty> RainCT: gives a backtrace... imho the problem was that a Config object was somewhere created from the web interface w.o. parameteres (which doesn't work, since it needs the request to find out the base path)... s.th. like that
[23:26] <sistpoty> RainCT: however I already fixed this in trunk, so it's just a matter of merging (which I'm doing now)
[23:26] <RainCT> ah
[23:26] <nixternal> sistpoty: which ones need to get nuked?
[23:26] <sistpoty> nixternal: that's actually the question, that I hoped you could answer :P
[23:27] <nixternal> and nuking, aren't the server admins the only ones allowed?
[23:27] <Fujitsu> Nuking all of urbanterror-data should fix the problem for quite a while.
[23:27] <sistpoty> nixternal: nuking from the web interface is allowed for anyone with the virtual right "Administrator"
[23:28] <sistpoty> nixternal: it just won't get deleted from disk, until s.o. with root rights executes the generated script from nuking actions
[23:28] <nixternal> there are some very old pkgs on revu
[23:28] <nixternal> very old == >6 months
[23:32] <nixternal> sistpoty: when some uploads a revision pkg to revu, does the server hold on to the old pkg after creating the debdiffs for the site?
[23:32] <nixternal> s/some/someone
[23:32] <nixternal> or does it just overwrite the old?
[23:33] <sistpoty> nixternal: yes, it does (the orig.tar.gz isn't guaranteed to match, and you can always switch back to an old upload on the details page)
[23:33] <sistpoty> nixternal: actually the debdiffs are created "on the fly", not the otherway round (which I guess is a bug on its own)
[23:33] <nixternal> how about when items are archived/uploaded, do those packages still stay on the server or do they get blasted?
[23:34] <sistpoty> nixternal: stay on the server.. archived is only an entry in the db actually
[23:35] <sistpoty> nixternal: and uploaded packages are currently not caught at all by revu (iirc packages are only marked as not new on the first upload to revu)
[23:35] <nixternal> ahh, ya forgot about that
[23:35] <nixternal> would it be possible to add an 'uploaded' option or something to review that would act like 'archive'?
[23:36] <sistpoty> (which of course is bad, but it involves ugly shell script hacking, which deal with incoming)
[23:36] <sistpoty> nixternal: well, I'm usually out of time... maybe RainCT would like to comment on this?
[23:37] <nixternal> I am guessing the only real purpose for keeping archived items is so people can go back and review them or something?
[23:37] <sistpoty> (side note: nuking works now on sparky as well :)
[23:37] <nixternal> seems sensable that when a MOTU uploads a package, the pkg files get nixed on the revu server, except keep the comments maybe and link to the LP page for the project?
[23:37] <sistpoty> nixternal: not too sure... ajmitch once wrote a script to review uploads done by a person (probably for MC)
[23:38] <RainCT> siretart: ping
[23:38] <sistpoty> nixternal: actually, the only worthwhile thing then imho are the comments
[23:38] <sistpoty> (thought one never knows, and I must admit that I've never looked at revu during my mc time)
[23:39] <sistpoty> RainCT: did you mean me? (see context)
[23:39] <sistpoty> RainCT: as siretart is probably fast asleep by now
[23:45] <RainCT> sistpoty: no, I just finished reading the backlog
[23:45] <RainCT> the ping to siretart is about gxine (he's the last uploader :P)
[23:46] <sistpoty> RainCT: ah, heh
[23:46] <sistpoty> nixternal: ok, this looks better now: /dev/hda2             38005512  31187964   4886940  87% /
[23:47] <sistpoty> (instead of 98%)
[23:47] <RainCT> sistpoty: well.. I already told you that we could export comments (as text, XML or whatever) and keep them when uploads are being removed..
[23:47] <RainCT> :)
[23:47] <nixternal> true, but 87% still looks scary to me
[23:47] <sistpoty> nixternal: bah... we're in FeatureFreeze :P
[23:47] <sistpoty> RainCT: heh, yes
[23:47] <nixternal> that doesn't stop people though :)
[23:48] <sistpoty> nixternal: if you prefer, I can make the disk full again :P
[23:48] <nixternal> no thank you
[23:50] <RainCT> good night
[23:50] <sistpoty> gn8 RainCT
[23:50] <sebner> gn8 RainCT
[23:55] <nixternal> I am nukin' my old packages that have been there for a while...no need to keep them around
[23:56] <sistpoty> thanks nixternal!
[23:56] <nixternal> note to self: CLICK NUKE NOT UNARCHIVE
[23:57] <sistpoty> note to slef: completely nuking a package sucks in revu *g*
[23:57] <sistpoty> to self even
[23:59] <nixternal> heh, I nuke kblogger-kde4, all it does is unarchive it