=== 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 | ||
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:51 |
---|---|---|
ogra | (and one that surely was never listed by the arm team either) | 14:52 |
robbiew | ogra: ack...sorry, it was a Linaro bug...I will remove from the agenda | 14:58 |
ogra | thanks | 14:59 |
ogra | just looked strange :) | 14:59 |
=== 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 | ||
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! | 16:45 |
* 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:00 | |
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:30 |
robbiew | cyphermox_: hmmm | 17:35 |
robbiew | it's a new feature, even if the same version...so I would think so | 17:36 |
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:37 |
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:38 |
robbiew | ack | 17:39 |
robbiew | sistpoty|work: thank you sir | 17:39 |
sistpoty|work | yw | 17:39 |
* 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:40 |
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 | 17:41 | |
sistpoty | hmpf, just why did I volunteer to look at udev... *g* (about 1/3 through the diff) | 21:16 |
nigelb | heh | 21:21 |
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:14 |
robbiew | heh | 22:15 |
robbiew | sistpoty: thanks...and thaaaanks :/ | 22:15 |
sistpoty | robbiew: yw and heh :P | 22:15 |
ScottK | sistpoty: You're at least in the right country to go provide encouragement to pitti to deal with regressions. | 22:16 |
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:17 |
sistpoty | haha | 22:18 |
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:20 |
sistpoty | ScottK: define "a bit" | 22:25 |
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:26 |
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:27 |
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:28 |
barry | plus it would fix py27 support <wink> | 22:29 |
ScottK | Yes. That too. | 22:48 |
=== bjf is now known as bjf[afk] | ||
lamont | buildds all on manual pending a brief disturbance in the force | 23:36 |
ScottK | Is this the one that comes from sparc and ia64 going away on Maverick? | 23:37 |
wgrant | Or from me breaking amd64 builds again? | 23:45 |
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:52 |
* 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:53 |
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:54 |
sistpoty | wgrant: ah, and even have the same link on librarian? | 23:55 |
wgrant | sistpoty: No. A librarian file can never change. | 23:55 |
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:56 |
wgrant | Or a LOSA is editing files on mizuho just to confuse you ;) | 23:57 |
sistpoty | haha | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!