[01:26] <xnox> infinity: but they do look like they got generated correctly earlier in the build. *sigh* will poke it more on my panda tomorrow.
[09:17] <ogra_> could someone let initramfs-tools-ubuntu-touch in from the NEW queue ?
[09:45] <seb128> ogra_, you could have done an effort and use the current format for the copyright :p
[09:46] <seb128> ogra_, NEWed
[09:46] <ogra_> lintian didnt complain
[09:46] <ogra_> thanks !
[09:47] <seb128> ogra_, I'm not lintian, and I'm complaining :p
[09:47] <seb128> ogra_, yw ;-)
[09:47] <ogra_> :)
[09:48] <xnox> ogra_: seb128 is better than lintian, because he is french =)
[09:49] <ogra_> ++
[09:49] <seb128> ;-)
[09:49]  * xnox now wonders if lintian is mostly written by french or not as well
[11:18] <Laney> queuebot silent again?
=== smartboyhw_ is now known as smartboyhw
=== greyback is now known as greyback|lunch
=== greyback|lunch is now known as greyback
[13:43] <plars> no images today yet?
[13:47] <plars> infinity, cjwatson: ^
[13:49] <cjwatson> Hm, I didn't get any failure logs
[13:49] <stgraber> there are a lot of cron jobs running on nusakan
[13:50] <stgraber> I wonder if they got stuck somehow
[13:50] <cjwatson> Yeah, looks like stuck builders
[13:51] <cjwatson> But across lots of arches, which is weird
[13:51] <cjwatson> Usually it's just one machine that does its nut
[13:53] <cjwatson> Earliest build there is XUbuntu
[13:53] <cjwatson> Er, Xubuntu
[13:55] <cjwatson> But http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/xubuntu/20130521/livecd-20130521-i386.out looks OK
[13:55] <cjwatson> I'll ask ops
[13:55] <stgraber> can't see anything in the logs (looked at kapok) that'd explain why it's stuck...
[13:56] <cjwatson> The next build to start after xubuntu/saucy was mythbuntu/saucy, and that has no logs
[13:56] <cjwatson> So probably stuck on a lock
[13:57] <plars> thanks cjwatson
[13:57] <cjwatson> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/saucy/lubuntu/20130521/livecd-20130521-powerpc.out is the last powerpc build to get anywhere
[14:00] <cjwatson> https://pastebin.canonical.com/91437/ for those who can see that
[14:00] <cjwatson> root     24285  0.0  0.0   2360   752 ?        S    May21   0:00  |                   \_ /bin/sh ./auto/build
[14:00] <cjwatson> root     24316  0.0  0.0   2140   492 ?        S    May21   0:00  |                       \_ tee binary.log
[14:00] <cjwatson> Guess we need to try to reproduce locally
[14:00] <cjwatson> I'll do a full upgrade and see what I can unearth
[14:01] <cjwatson> plars: This may take a while.  Hope it's not urgent. :-/
[14:02] <plars> cjwatson: just wanted to make sure you all were aware since we saw the images didn't get tested today
[14:02] <plars> (because they didn't exist yet)
[14:02] <cjwatson> Yeah, thanks for reporting, I hadn't noticed
[14:16] <rtg_> is that why linux-maguro has no binaries ? https://launchpad.net/ubuntu/+source/linux-maguro/3.0.0-0.1
[14:16] <rtg_> nm, just too stupis yet this AM
[14:16] <Laney> that's just NEW: https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=
=== mmrazik is now known as mmrazik|afk
=== medberry is now known as med_
[16:20]  * Laney gets 66 build failure emails(!)
[16:20] <cjwatson> plars: OK, to keep you updated, this is bug 1182540.  I have fixes in progress, but they won't all be available until tomorrow.
[16:21] <ubot2> Launchpad bug 1182540 in ubiquity (Ubuntu) "Daemon-suppression code in installer breaks new invoke-rc.d logic" [Critical,Fix committed] https://launchpad.net/bugs/1182540
[16:21] <cjwatson> Laney: Yeah, I just killed a bunch
[16:21] <cjwatson> I've disabled the saucy part of the crontab
[16:22] <cjwatson> Given that LP package index imports are currently broken, I think I'd better upload debootstrap directly rather than waiting for a sync
[16:23] <Laney> I thought they worked for <gdb
[16:24] <cjwatson> Oh good point
[16:24] <cjwatson> Alphabet convenience
[16:35] <tumbleweed> erm, if someone wasts to kill that pypy armhf build, I know it can't succeed
[16:46] <stgraber> cjwatson: let me know once we can build raring images again, I'll want to do a couple of test builds to test a cdimage change I just landed (post_qa support for multiple trackers)
[16:46] <cjwatson> stgraber: YM saucy?
[16:47] <stgraber> cjwatson: hmm, yeah :) Have been spending too much time in the cdimage testsuite it looks like (lots of raring in there ;))
[16:47] <cjwatson> stgraber: It'll probably be tomorrow, but you could always test with the post-qa command
[16:48] <cjwatson> Shouldn't need a full build
[16:49] <stgraber> cjwatson: ah yeah, good point. I'm currently running a couple of precise test builds to test publishing of those but will do the rest directly with post-qa (and then go manually revert the changes in the tracker DB)
[16:57] <stgraber> (in case someone notices and wonders, yes I'm building a zh_CN precise image, yes those are deprecated but it's my only production use case for the multiple tracker instance support)
[17:06] <slangasek> stgraber: if that's the only use case, maybe it's fine to let that code wither and die?
[17:08] <stgraber> slangasek: well, that specific code is just a small extra tweak on top of the code to support building multiple series so it doesn't really hurt us to keep it around especially as it's not entirely impossible that we may move some products to a separate tracker at some point
[17:09] <slangasek> stgraber: well, ok; it just seems to me that if you're building a deprecated thing just to test the code that's only used for the deprecated thing, it would save effort to not do that :)
[17:09] <stgraber> the change I'm testing essentially makes the code generic and drops the hardcoded "china-" that we had in the past and simply checks what tracker a product is published to (last column from the new qa-product file)
[17:14] <stgraber> alright, code all tested, now to see if I can get that ported to the upstream qatracker python module instead of our local isotracker module (really need to get python(3)-qatracker packaged...)
[17:25] <stgraber> oh, it actually uses the new isotracker.py from ubuntu-archive-tools which is a wrapper around qatracker.py (upstream python-qatracker), so it's already using the new code indirectly, good enough. I just want to avoid having the RPC implementation done twice but that's not the case.
[18:16] <infinity> stgraber: queuebot's unhappy again.
[19:56] <stgraber> stgraber@castiana:~/data/code/cdimage/cdimage$ CDIMAGE_ROOT=. bin/rebuild-requests saucy iso
[19:56] <stgraber>  - Edubuntu DVD amd64 for Saucy => ('edubuntu', 'dvd', 'dvd', 'amd64')
[19:56] <stgraber>  - Edubuntu DVD i386 for Saucy => ('edubuntu', 'dvd', 'dvd', 'i386')
[19:57] <stgraber> cjwatson: ^ so that's what I'm getting from the tracker now, any recommendation on how to get from that to a running build? can I do that in pure python or should I use for-project instead?
[20:39] <bdmurray> is queuediff often used with ppas?
=== mbarnett` is now known as mbarnett