[14:51] <ogra> 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] <ogra> (and one that surely was never listed by the arm team either)
[14:58] <robbiew> ogra: ack...sorry, it was a Linaro bug...I will remove from the agenda
[14:59] <ogra> thanks
[14:59] <ogra> just looked strange :)
[16:45] <robbiew> 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] <slangasek> 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] <cyphermox_> 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] <robbiew> cyphermox_: hmmm
[17:36] <robbiew> it's a new feature, even if the same version...so I would think so
[17:37] <robbiew> cyphermox_: ^
[17:37] <robbiew> just to have a record of it
[17:37] <sistpoty|work> 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] <robbiew> sistpoty|work: were you going to take care of pitti's FFes?
[17:38] <robbiew> 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] <cyphermox_> sistpoty|work, robbiew, thanks
[17:38] <sistpoty|work> 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] <robbiew> ack
[17:39] <robbiew> sistpoty|work: thank you sir
[17:39] <sistpoty|work> 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] <sistpoty|work> cjwatson: of course I also wouldn't mind at all, if you want to take over udev ;)
[17:40] <cjwatson> oh hell no
[17:41] <sistpoty|work> heh
[17:41] <cjwatson> just parachuting in with bzr assistance
[17:41] <sistpoty|work> ah :)
[17:41]  * sistpoty|work heads home now, l8er
[21:16] <sistpoty> hmpf, just why did I volunteer to look at udev... *g* (about 1/3 through the diff)
[21:21] <nigelb> heh
[22:14] <sistpoty> 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] <robbiew> heh
[22:15] <robbiew> sistpoty: thanks...and thaaaanks :/
[22:15] <sistpoty> robbiew: yw and heh :P
[22:16] <ScottK> sistpoty: You're at least in the right country to go provide encouragement to pitti to deal with regressions.
[22:17] <sistpoty> ScottK: still some way to drive, but yes, that's an option *g*
[22:17] <cjwatson> hopefully pitti will see the message I sent him about unfeasibly clever revision control magic
[22:17] <cjwatson> er, with added modesty
[22:18] <sistpoty> haha
[22:20] <ScottK> 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] <ScottK> skat: ^^^
[22:25] <sistpoty> ScottK: define "a bit"
[22:26] <ScottK> That's part of what barry's looking at.
[22:26]  * barry nods
[22:26] <sistpoty> ah, only thing I recall of -numpy is pain, but not the details
[22:26] <ScottK> 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] <ScottK> 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] <ScottK> At present it's blocking updating shogun to fix an FTBFS (and help with NBS).
[22:28] <ScottK> 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] <ScottK> I suspect we'll hit more cases of that.
[22:29] <barry> plus it would fix py27 support <wink>
[22:48] <ScottK> Yes.  That too.
[23:36] <lamont> buildds all on manual pending a brief disturbance in the force
[23:37] <ScottK> Is this the one that comes from sparc and ia64 going away on Maverick?
[23:45] <wgrant> Or from me breaking amd64 builds again?
[23:52] <ScottK> FWIW, the best way to keep buildd backlog low is to fail all builds as fast as possible.
[23:52] <wgrant> Heh.
[23:52] <ScottK> It may, however, have undesirable side effects.
[23:53]  * cjwatson gets closer to understanding bug 544139
[23:53] <ubot4> 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] <cjwatson> perhaps I should do something else at nearly midnight on a Friday, rather than trying to find my way around gdm patches
[23:53] <sistpoty> 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] <sistpoty> 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] <sistpoty> *at a*
[23:54] <wgrant> sistpoty: It only affected amd64 builds.
[23:54] <wgrant> Failed logs can change, though, if somebody retries the build...
[23:55] <sistpoty> wgrant: ah, and even have the same link on librarian?
[23:55] <wgrant> sistpoty: No. A librarian file can never change.
[23:56] <sistpoty> 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] <wgrant> Or a LOSA is editing files on mizuho just to confuse you ;)
[23:57] <sistpoty> haha