[00:08] <CIA-2> ubiquity: cjwatson * r5160 trunk/ (debian/changelog finish-install.d/01oem-config-udeb):
[00:08] <CIA-2> ubiquity: Restore finish-install's title after installing the oem-config frontend
[00:08] <CIA-2> ubiquity: (LP: #925155).
[00:20] <CIA-2> ubiquity: cjwatson * r5161 trunk/ (debian/changelog ubiquity/install_misc.py): Avoid duplicate call to osextras.find_on_path('check-language-support').
[00:21] <antarus> sometimes I wonder if cjwatson sleeps
[00:21] <cjwatson> sometimes so do I
[00:22] <cjwatson> oh yes, your netcfg patch.  coffee first then I'll review it
[00:28] <cjwatson> oh, hmm, stgraber already assigned it to himself
[00:28] <cjwatson> stgraber: antarus' patch in bug 917905 LGTM - feel free to go ahead if it passed your tests
[00:28] <ubot2`> Launchpad bug 917905 in netcfg "netcfg hang bug in autoconfig.c" [Undecided,Confirmed] https://launchpad.net/bugs/917905
[00:32] <GrueMaster> stgraber: I'm seeing an oddity today that I haven't seen before in netboot.  When it gets to the kernel, I get:   in-target:   Temporary failure resolving 'mirror.gruenet'
[00:32] <antarus> oh excellent ;)
[00:33] <GrueMaster> Only when installing the kernel & headers packages.  If I go to a shell and chroot into the target, it works fine.
[00:44] <stgraber> cjwatson, antarus: yep looks good to me too, I just need to fix the automated IPv6 tester to actually work properly with precise, hopefully that'll be all tested and uploaded next week
[00:45] <stgraber> GrueMaster: I noticed something similar on a machine today, assumed it was my DNS server being buggy as it was for the past two weeks but maybe it wasn't ...
[00:46] <GrueMaster> I show no weirdness on my firewall system, so that isn't it.  And like I said, I can jump into a shell and run the apt commands manually fine.
[00:47] <GrueMaster> I wonder if the pools are corrupted again.
[00:47] <antarus> GrueMaster: hey
[00:47] <antarus> GrueMaster: we hit a similar issue today
[00:47] <antarus> GrueMaster: we think it is a bug in a recent resolvconf update
[00:47] <GrueMaster> Ah.  Possible.
[00:49] <antarus> basically resolvconf replaces /etc/resolv.conf with a symlink
[00:49] <antarus> I think there is a preseed to work around it
[00:49]  * antarus doens't think we haev a bug for it yet
[00:50] <stgraber> I'll try to have a look this weekend then ... if it's indeed resolvconf, the bug will get assigned to me anyway ;)
[00:51] <GrueMaster> Hrm.  Looking at the link, it just points to /run/resolvconf/resolv.conf.  So unless the target fs is wonky, it should be ok (nless the file is regenerated constantly).
[00:52] <stgraber> though the last upload was supposed to make resolvconf do the right thing for chroots (including the d-i install target). d-i writes /etc/resolv.conf but IIRC netcfg was updated to write deal with the symlink properly AND since the latest resolvconf, the symlink is relative so should work even with something that doesn't understand the symlink
[00:52] <stgraber> anyway, the fact that /target is fine when you chroot to it is a bit annoying when debugging ;)
[00:53] <antarus> stgraber: I think the main problem was that it was broken for some small time period that caused apt to fail, and then manual checking it would look fine, etc...
[00:53] <GrueMaster> yep.  very.
[00:54] <GrueMaster> antarus: That doesn't explain why I can get through an entire install, only to fail at the kernel package (which is very consistent here).
[00:55] <stgraber> antarus: yeah, I'll have to look at an install log to see exactly what's going on. I know exactly what resolvconf does but resolvconf alone should be fine in that case, it's probably some conflict/race with what netcfg is doing
[00:55] <stgraber> GrueMaster: it failed at the exact same place for me, so there's indeed something odd going on right before d-i tries to install the kernel
[00:58] <cjwatson> base-installer might need to be extended to bind-mount /run or similar
[00:59] <antarus> my co-worker filed https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/926447
[00:59] <ubot2`> Launchpad bug 926447 in resolvconf "New resolvconf interacts badly with something in installs" [Undecided,New]
[01:00] <antarus> hopefully he will attach more information ;)
[01:11] <stgraber> assigned the bug to me and bumped to critical (we are quite a few who've hit that exact issue, so I think it's fair to assume it's not caused by our local environment)
[01:48] <cjwatson> bdmurray,stgraber: I'm dealing with that Xubuntu boot image bug now.  GIMP python-fu is my new best friend.
[01:49] <cjwatson> (Hi, I'd like to programmatically transform the colour palette of this indexed image ...)
[01:49] <stgraber> sounds fun ;)
[01:52] <cjwatson> If I take the aubergine-based Ubuntu image, set saturation to 0, and then scale the value linearly from 0 to 1, it seems to come out looking OK
[01:53] <cjwatson> I hadn't previously known that there are RGB<->HSV conversion functions in the Python standard library!
[02:43] <CIA-2> ubiquity: cjwatson * r5162 trunk/ (debian/changelog scripts/install.py scripts/plugininstall.py): Stop filtering warnings from the apt module which are no longer emitted.
[02:54] <CIA-2> ubiquity: cjwatson * r5163 trunk/ (28 files in 8 dirs): PEP-8 import ordering.