=== bjf is now known as bjf[afk] === bjf[afk] is now known as bjf === bjf is now known as bjf[afk] === jjohansen is now known as jj-afk === doko__ is now known as doko === davmor2_ is now known as davmor2 [14:51] robbiew, hmm, your release team agenda looks weird for the arm team, the only bug thats listed under ARM is a bug i never heard about [14:52] (and one that surely was never listed by the arm team either) [14:58] ogra: ack...sorry, it was a Linaro bug...I will remove from the agenda [14:59] thanks [14:59] just looked strange :) === bjf[afk] is now known as bjf === mvo is now known as mvo|undercover === lamont` is now known as lamont === jj-afk is now known as jjohansen [16:45] slangasek: so apparently jcastro wants a full explanation of why DVD ISO creation is a PITA...maybe we can school him up for the release team :P [16:45] excellent! a volunteer! [17:00] * robbiew crafts a reply to his email...to basically say we'd love to show him how it's all done...but there's a PRICE for such knowledge :D [17:30] I noticed I forgot to enable the new nmcli command-line tool for NetworkManager. Would I need a FF exception for this, or is it fine to do the change since it does not imply a new upstream version, just a new revision? [17:35] cyphermox_: hmmm [17:36] it's a new feature, even if the same version...so I would think so [17:37] cyphermox_: ^ [17:37] just to have a record of it [17:37] cyphermox_: if it's a new feature, go for a FFe to be sure, shouldn't be a big deal then to get it through [17:37] sistpoty|work: were you going to take care of pitti's FFes? [17:38] I suppose I "could" but as I'm not an official member of the release team...I try not to stir up controversy :) [17:38] sistpoty|work, robbiew, thanks [17:38] robbiew: yes, but only once I'm home, I have a gut feeling wrt. to udev so just want to take a detailed look at the diff [17:39] ack [17:39] sistpoty|work: thank you sir [17:39] yw [17:40] * cjwatson is attempting to sort out a rebase of udev's ubuntu branch so that we don't lose history in the process [17:40] cjwatson: of course I also wouldn't mind at all, if you want to take over udev ;) [17:40] oh hell no [17:41] heh [17:41] just parachuting in with bzr assistance [17:41] ah :) [17:41] * sistpoty|work heads home now, l8er [21:16] hmpf, just why did I volunteer to look at udev... *g* (about 1/3 through the diff) [21:21] heh [22:14] ok, udev's FFe approved. and JTFR, if ScottK is going to make me fix regressions since I approved it, I'll kindly point to robbiew :P [22:15] heh [22:15] sistpoty: thanks...and thaaaanks :/ [22:15] robbiew: yw and heh :P [22:16] sistpoty: You're at least in the right country to go provide encouragement to pitti to deal with regressions. [22:17] ScottK: still some way to drive, but yes, that's an option *g* [22:17] hopefully pitti will see the message I sent him about unfeasibly clever revision control magic [22:17] er, with added modesty [22:18] haha [22:20] FYI (from the release meeting): I asked barry to have a look at python-numpy. We'll either need to have a bit of a transition or live with pain of divergence from Squeeze. [22:20] skat: ^^^ [22:25] ScottK: define "a bit" [22:26] That's part of what barry's looking at. [22:26] * barry nods [22:26] ah, only thing I recall of -numpy is pain, but not the details [22:26] The rdepends list is not small, but Debian has done the transition, so we can see what needs doing based on what they had to do. [22:27] They introduced a dh_numpy to ease the pain a bit and I'd like to get it into Maverick if it's reasonable to do it. [22:27] At present it's blocking updating shogun to fix an FTBFS (and help with NBS). [22:28] Much easier if I can just sync numpy and shogun rather than have to revert the dh_numpy changes out of shogun and then do the equivalent. [22:28] I suspect we'll hit more cases of that. [22:29] plus it would fix py27 support [22:48] Yes. That too. === bjf is now known as bjf[afk] [23:36] buildds all on manual pending a brief disturbance in the force [23:37] Is this the one that comes from sparc and ia64 going away on Maverick? [23:45] Or from me breaking amd64 builds again? [23:52] FWIW, the best way to keep buildd backlog low is to fail all builds as fast as possible. [23:52] Heh. [23:52] It may, however, have undesirable side effects. [23:53] * cjwatson gets closer to understanding bug 544139 [23:53] Launchpad bug 544139 in consolekit (Ubuntu Maverick) (and 3 other projects) "Active VT tracking can fail at startup (affects: 41) (dups: 6) (heat: 193)" [High,Triaged] https://launchpad.net/bugs/544139 [23:53] perhaps I should do something else at nearly midnight on a Friday, rather than trying to find my way around gdm patches [23:53] wgrant: could this somehow have the side effect of changing a once published build log? (http://launchpadlibrarian.net/54040909/buildlog_ubuntu-maverick-i386.folks_0.1.14.1-0ubuntu1_FAILEDTOBUILD.txt.gz) [23:54] wgrant: I could swear that was different once I last looked at it, but I might be wrong (and have looked a paste instead) [23:54] *at a* [23:54] sistpoty: It only affected amd64 builds. [23:54] Failed logs can change, though, if somebody retries the build... [23:55] wgrant: ah, and even have the same link on librarian? [23:55] sistpoty: No. A librarian file can never change. [23:56] wgrant: ah, ok, thanks. then I guess I looked at a paste (only viable option left to explain it... of course my brain might also be permanently hurt by the udev FFe *g*) [23:57] Or a LOSA is editing files on mizuho just to confuse you ;) [23:57] haha