[06:23] <elmo> anyone with cdimage access around?
=== doko_ is now known as doko
[07:19] <seb128> that sync ^ has no lp reference but the ffe is bug #1379344
[07:19] <ubot2> bug 1379344 in glibmm2.4 (Ubuntu) "[FFe] Update glibmm to 2.42" [Medium,Triaged] https://launchpad.net/bugs/1379344
[07:19] <seb128> it makes the binding be on the same serie as the lib and fix the current ftbfs
[10:07] <cjwatson> stgraber: please can you make sure to run the test suite before committing to cdimage?
[10:07] <cjwatson> fixing it up now ...
[10:55] <stgraber> cjwatson: oops, sorry, I always forget that config changes also break the testsuite...
[10:57] <stgraber> slangasek: so cjwatson reported bug 1379274 as a regression from the switch to python3 and switched import-images back to python2 which hit the bug again and filled up nusakan's disk. I've now added a test and pushed a fix for unicode handling in the removal list for python2.
[10:57] <ubot2> bug 1379274 in Ubuntu system image "import-images fails under Python 3 when there are multiple images and at least one lacks a base" [Undecided,New] https://launchpad.net/bugs/1379274
[10:58] <stgraber> slangasek: so for hte time being, we'll keep things running under python2 and I'll look into cjwatson's bug later, then do proper testing of python3 before we consider switching produciton to python3
[11:07] <stgraber> system-image is back to normal, crontab entry re-enabled
[11:11] <cjwatson> stgraber: thanks
[11:12] <cjwatson> stgraber: would appreciate review of https://code.launchpad.net/~cjwatson/ubuntu-system-image/cdimage-custom/+merge/237942 if you get a chance - fairly urgent
[11:13] <cjwatson> rationale's near the end of the linked (unfortunately private) bug
[11:17] <stgraber> cjwatson: merged and deployed
[11:19] <cjwatson> yay thanks
[11:19] <cjwatson> glad I understood the model properly
[11:20] <cjwatson> so we'll just need to add an extra cdimage-custom line to etc/config after deploying livecd-rootfs
[11:21] <stgraber> more like changing the existing custom line to use the cdimage-custom generator instead of the http one, but yeah
[11:22] <stgraber> reminds me I really need to split the generators out as separate files, generators.py is starting to be pretty messy :)
[11:23] <cjwatson> right yeah
[11:24] <cjwatson> I guess thinking about it we can safely land livecd-rootfs without that
[11:24] <cjwatson> because nothing happens to the actual build until etc/config is changed
[11:24] <cjwatson> oh no, that would drop those click packages from rootfs into a black hole
[11:25] <stgraber> yeah, I think we'll need to be pretty careful, stop the system-image cron, land cdimage, build a new image, update system-image's config, run import-images by hand to confirm all is well, then turn cron back on
[11:26] <cjwatson> land livecd-rootfs, but yeah
[11:26] <cjwatson> I deployed the cdimage code already, since it should be a no-op if livecd-rootfs hasn't generated custom.tar.gz
[11:27] <stgraber> ah right
[11:27] <stgraber> an alternative would be to change livecd-rootfs to first both install the clicks in the rootfs and generate custom.tar.gz with the same clicks. Then we can land that, switch system-image, test everything and then land a second livecd-rootfs which stops including the clicks in the rootfs
[11:28] <stgraber> that's all based on the assumption that click doesn't freak out if something is both in the system path and in /custom
[11:28] <cjwatson> shouldn't any more following the click-apparmor changes
[11:28] <cjwatson> ok, I'll follow up on https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/split-custom-tarball/+merge/237905
[12:49] <stgraber> cjwatson: are you the one holding the vim lock on etc/config ?
[13:00] <cjwatson> stgraber: oh sorry, dropped
[13:01] <stgraber> thanks
[14:42] <jamespage> the neutron upload I did a few minutes ago resolves a blocking issue in our RC testing; however it does pull a new package into main (ipset) - MIR raised and apologies - missed that delta on the rc1
[14:43] <stgraber> cjwatson, ogra_, slangasek: so who just switched system-image back to python3 again? :)
[14:43] <stgraber> I'm getting tracebacks in my e-mails
[14:44] <ogra_> stgraber, i didnt touch the code at all
[14:44] <ogra_> (i ran import-images with python and python3 prefix manually this morning thouh ... to get the images out ... are you sure these mails are recent ?)
[14:45] <stgraber> ogra_: yeah, they're pretty recent and I see that someone re-applied slangasek's change manually in /srv/system-image.ubuntu.com
[14:45] <stgraber> so system-image is currently broken
[14:45] <ogra_> ouch
[14:46] <ogra_> i know lool just built an image, but i think he only touched crontab
[14:46] <cjwatson> I didn't touch it
[14:46] <lool> I've only touched crontab
[14:46] <cjwatson> you sure it wasn't a merge conflict thing
[14:46] <cjwatson> ?
[14:46] <lool> and ran an rtm image build
[14:46] <lool> I didn't bzr anything
[14:48] <stgraber> I'm having doubts now :) I'm pretty sure I did uncommit+revert before pulling the updated code but maybe I forgot the revert and we've somehow been lucky not to hit the broken python3 codepath until now (because the past 20 or so runs were successful, it just started failing again about 20min ago)
[14:49] <stgraber> anyway, just dropped all the local delta so the next run should succeed again
[23:02] <cjwatson> (that's a binary sync; I took care because perl can easily make the archive grumpy if you end up with build skew)
[23:02] <cjwatson> slangasek,infinity: would you have a minute to review debian-installer so that the new kernel can get in?  there's one ppc64el-specific change in there too
[23:03] <slangasek> yes, looking
[23:06] <infinity> cjwatson: oh, thanks for that, I got distracted.
[23:07] <infinity> cjwatson: Are minicmd/reboot consistent with other arches?
[23:08] <infinity> cjwatson: Oh, I guess we cargo-culted this from kfreebsd, which has an entirely different module selection.
[23:09] <infinity> But minicmd is there, at least.
[23:09] <infinity> slangasek: You still reviewing that, or okay for me to let it in?
[23:09] <slangasek> infinity: no, and no!
[23:09] <infinity> That answers that.
[23:10] <infinity> ;)
[23:13] <slangasek> yes, it's always nice to see the queuebot accepting a botch sync
[23:24] <cjwatson> yeah there isn't really a perfect analogue elsewhere but I guess kfreebsd is closest right now