[08:24] <NCommander> cjwatson: ping, I need some feedback on how best to build a d-i installer image in universe (needed for armadaxp, which will not have a kernel suitable for main)
[09:16] <cjwatson> NCommander: right, I was going over this with ogra last week.  Basically there's no point in uploading a d-i fork to universe because LP would publish the resulting custom upload to main anyway
[09:17] <cjwatson> NCommander: I think we might as well just have the standard d-i package build it, but designate it separately as unsupported-kernel or something
[09:17] <cjwatson> NCommander: it would just be a matter of setting 'UDEB_COMPONENTS = main/debian-installer universe/debian-installer' in the relevant configs, I thin
[09:18] <cjwatson> k
[11:18] <NCommander> cjwatson: isn't that a violation of policy though? d-i would have to depend on a universe udeb, and the resulting installer dists end up in main
[11:19] <cjwatson> NCommander: yes, but an acceptable one I think
[11:19] <NCommander> I would think that would need a tech board approval since it does a whole lot of ugly voodoo. From a supported/unsupported stance, it might just be easier to get LP to allow publishing installer stuff into dists/precise/universe
[11:20] <cjwatson> I doubt it, custom uploads are ghastly
[11:20] <NCommander> Well, BYHAND always has been. I still remember AUTOBYHAND >.<;
[11:20] <cjwatson> if it were easy I'd have done it - but it will require database changes to make suitable overrides exist at all
[11:21] <NCommander> cjwatson: universe/debian-installer already exists
[11:21] <cjwatson> that isn't relevant to debian-installer image tarballs.
[11:21] <NCommander> We have a special override for that?
[11:21]  * NCommander whimpers
[11:21] <cjwatson> no.  that's kind of the point!
[11:21] <NCommander> yeah
[11:21] <cjwatson> they just get shoved into main.
[11:21] <NCommander> cjwatson: well, there is option two
[11:22] <NCommander> Having an unsupported kernel in main. We have historical predencant for that
[11:22]  * NCommander glances at linux-ports 
[11:22] <NCommander> and I prefer option two rather than breaking the main/universe divide IMH
[11:22] <NCommander> *IMHO
[11:22] <cjwatson> I don't mind that personally; but I also don't see any particular real difference between having the whole kernel in main, and just building those installer images from the kernel in universe and having free text somewhere to mark them unsupported
[11:23] <cjwatson> it's the same "unsupported stuff in main" policy violation either way, really
[11:23] <NCommander> cjwatson: less hackery to base-installer to let it install a kernel from universe for one (and probably other breakage)
[11:23] <NCommander> unless that got fixed without me noticing it
[11:24] <cjwatson> if we're talking netboot rather than CD (I assume we are), then that would take a few lines of extra code, yes
[11:24] <cjwatson> I'd be surprised if there were much else - most things have universe on by default now
[11:24] <NCommander> We need both
[11:24] <cjwatson> but sure, if you want to shove the kernel in main I don't object
[11:25] <cjwatson> though it's probably not me you need to get to agree to it :)
[11:25] <NCommander> I'll chew it out with davidm and then make a call.
[11:25]  * cjwatson nods
[11:25] <NCommander> cjwatson: well, if I want to crack d-i to build a package with universe udebs, I need the cjwatson seal of approval ;-)
[11:26] <cjwatson> you have my seal of approval to set UDEB_COMPONENTS in a flavour-specific d-i config file
[11:26] <NCommander> great
[11:27] <cjwatson> assuming it needs no actual build-dependencies from universe (not counting udebs)
[11:27] <cjwatson> if it does we'd need to think about that a bit
[11:27] <NCommander> cjwatson: everything else it needs should be in main already
[11:27] <NCommander> or at least promotable. the kernel is only living in universe because we can't realistically do 5 year support on a 3.0 kernel
[11:47] <CIA-2> ubiquity: cjwatson * r5164 trunk/.bzrignore: ignore src/wallpaper/.deps
[12:31] <CIA-2> ubiquity: cjwatson * r5165 trunk/ (80 files in 6 dirs): Make the "Choose a picture" page translatable (LP: #892384).
[12:34] <cjwatson> ev: damnit, you've (extremely belatedly) got me addicted to figuring out how to write test cases for ubiquity changes
[12:34] <ev> hahahaha
[12:34] <ev> excellent
[12:34] <cjwatson> I think actually hacking on Launchpad may have converted me, really; whodathunkit
[12:35] <ev> Michael Foord is never far if Mock is missing functionality or not working as expected
[12:37] <CIA-2> ubiquity: cjwatson * r5166 trunk/src/panel/panel.c: typo
[12:37] <cjwatson> not generally been running into that so far, thank goodness
[12:37] <cjwatson> (and I suspect I'd rearrange the code to make it more testable if I did)
[12:41] <CIA-2> ubiquity: cjwatson * r5167 trunk/ubiquity/frontend/gtk_ui.py: untabify
[13:01] <CIA-2> ubiquity: cjwatson * r5168 trunk/ (6 files in 4 dirs):
[13:01] <CIA-2> ubiquity: Make the "run all pending GTK events" function accessible from
[13:01] <CIA-2> ubiquity: ubiquity.gtkwidgets, and use it in the test suite. This makes the test
[13:01] <CIA-2> ubiquity: suite about four seconds faster.
[13:06] <CIA-2> ubiquity: cjwatson * r5169 trunk/ (4 files in 2 dirs): Fix sys.path mishandling in test suite.
[13:18] <CIA-2> ubiquity: cjwatson * r5170 trunk/tests/pyflakes.exclude: Remove a couple of obsolete pyflakes exclusions.
[13:45] <CIA-2> ubiquity: cjwatson * r5171 trunk/ (debian/changelog ubiquity/nm.py): Mark WPA2-only access points as secure.
[14:02] <ev> great stuff
[14:02] <ev> cheers
[15:17] <stgraber> cjwatson: looks like I'll have to revert that resolvconf netcfg change, with the new resolvconf from last week, we actually want d-i to cp /etc/resolv.conf to it or it causes bug 926447
[15:17] <ubot2`> Launchpad bug 926447 in resolvconf "New resolvconf interacts badly with something in installs" [Critical,New] https://launchpad.net/bugs/926447
[15:17] <stgraber> I'm doing a test install to make sure that's indeed the problem
[15:19] <cjwatson> stgraber: OK, do as you need
[15:56] <stgraber> hmm, it's apparently not a netcfg issue but some script in base-installer (or a base-installer hook) messing with resolv.conf somehow ...
[15:57] <cjwatson> netcfg provides a base-installer hook ...
[16:02] <stgraber> indeed, but it seems to break in the post-base-installer ones
[16:02] <stgraber> right before the kernel installation
[16:02] <cjwatson> not sure what would be fiddling with resolv.conf there
[16:02] <stgraber> (apt_update succeeds but install_kernel doesn't): http://paste.ubuntu.com/831503/
[16:02] <cjwatson> maybe something being run in the chroot without /run bind-mounted?
[16:03] <cjwatson> hm, that shouldn't be the case for install_kernel though
[16:03] <stgraber> yeah, I'm not sure either, I now added a post-base-installer hook that basically sleeps for 2 minutes so I can look at what's going on in the target
[16:04] <cjwatson> you might also try set -x in /lib/chroot-setup.sh
[16:07] <stgraber> though what you said is interesting, debootstrap runs without /run bind-mounted which is fine and is perfectly supported, but if later on /run is indeed bind mounted, this will indeed break resolvconf as /run/resolvconf/resolv.conf won't exist outside the target, making /etc/resolv.conf dangling symlink in the target
[16:12] <stgraber> right, that indeed seems to be the issue, I'll simply change netcfg to also create /run/resolvconf and copy /etc/resolv.conf to /run/resolvconf/resolv.conf, then hopefully everything will just work
[16:35] <stgraber> cjwatson: http://paste.ubuntu.com/831562/ looks reasonable?
[16:38] <cjwatson> stgraber: yeah, I guess so
[16:39] <stgraber> we end up doing quite a bit of copying /etc/resolv.conf around, but it seems to work fine with that change
[16:39] <stgraber> I'll do a quick test of the ipv6 patch to make sure it doesn't regress anything and then upload a new netcfg
[17:25] <antarus> woo ;_
[17:32] <stgraber> so far it looks good, there are just 2 tests remaining (dual stack) and then it's good for upload
[17:37] <stgraber> confirmed to work without any detected regressions
[17:59] <GrueMaster> stgraber: Thought I might add an update in what I found with resolvconf over the weekend.  During netinstall, it fails at the point of pulling and installing a kernel (and everything from then on will fail with resolving the mirror).  dropping to a chroot shell and running "dpkg --force-all --revome resolvconf ; apt-get install resolvconf" and continuing with the netboot install works (dpkg & apt-get complain during that step, just
[17:59] <GrueMaster> ignore).
[18:00] <stgraber> GrueMaster: it's fixed
[18:00] <GrueMaster> s/--revome/--remove
[18:00] <stgraber> GrueMaster: I uploaded a new netcfg a few minutes ago :)
[18:00] <GrueMaster> Oh, cool.  Well then...nevermind.  :P
[18:00] <stgraber> GrueMaster: will need a d-i upload though to build new netboot images
[18:01] <stgraber> GrueMaster: the issue was /run from outside the target being mounted on top of /run in the target, hiding /run/resolvconf in the process
[18:01] <GrueMaster> ok.  After they post, it takes up to two hours for me to mirror before I can test.
[18:01] <GrueMaster> Oops.
[18:01]  * cjwatson fails to reproduce 924993 in the test suite, hmm
[18:07] <CIA-2> ubiquity: cjwatson * r5172 trunk/ (tests/test_wireless.py debian/changelog): Add initial tests for wireless page.
[19:54] <stgraber> cjwatson: do you see any reason why http://paste.ubuntu.com/831802/ would fix a bug in netcfg where dhcpv6 stateful (no v4 at all) in a container wasn't working (never could reproduce in a VM), knowing that dhcpv6_exit_status is only compared to 0 or not 0 in the code?
[19:55] <stgraber> I'm running all the tests with that change now to confirm netcfg does the right thing, if it does, then that's the end of the bug that was breaking one of my testcases ever since I moved from VM to LXC
[19:56] <stgraber> adding some debug, I saw that netcfg used to consider dhclient's return code to be 1 but with this change, it now says it's 0 (as expected)...
[19:56] <stgraber> running dhclient manually, I never could get it to exit 1 and even in debug mode, wouldn't see anything wrong in the log (and ipv6 was working fine)
[20:30] <stgraber> hmm, ok, looks like this is actually more part of the problem than the problem itself (which is good as I couldn't quite understand why that'd fix it). dhcpv6 stateful only works fine now but dual-stack dhcpv6 stateful + dhcpv4 now only gives me ipv4
[20:30]  * stgraber continues digging
[21:03] <stgraber> cjwatson: ok, so http://paste.ubuntu.com/831890/ did the trick and now I got all the tests to succeed, will talk to you about it tomorrow, I'm sure you had a good reason for that WIFSIGNALED
[22:32] <bicchi> I noticed something new in the netboot image of Precise Pangolin; It supports IPv6. Anyone knows if this can be disabled? There usually is a "d-i" parameter to turns some features off.
[22:35] <cjwatson> stgraber: instead, should probably only do either of those checks if waitpid succeeded
[22:36] <cjwatson> bicchi: one moment
[22:36] <cjwatson> bicchi: is it actually causing you a problem?  it should only have any effect if there are IPv6 autoconfiguration servers on the network
[22:36] <cjwatson> (aside from a delay)
[22:37] <cjwatson> bicchi: it doesn't appear to be configurable right now; that wouldn't be difficult to add if we were given a good reason
[22:38] <bicchi> cjwatson: I feel it is the root of the problem. The Ubuntu 10 netboot image is on the same network and doesn't have this problem. The first time I pxe boot, it fails to get a dhcp lease.
[22:38] <cjwatson> no such thing as "Ubuntu 10"
[22:38] <stgraber> bicchi: 11.10 also had ipv6 support
[22:38] <cjwatson> 10.04 or 10.10, I assume
[22:38] <bicchi> cjwatson: lucid
[22:38] <cjwatson> ok, 10.04.  (The 10 is a year, not a major version number)
[22:39] <cjwatson> there were lots of changes in netcfg between 10.04 and now, so you can't finger ipv6 support as the culprit just from that
[22:39] <cjwatson> let's see logs :)
[22:39] <cjwatson> (preferably from both the client and server, if possible)
[22:40] <bicchi> I can provide you part of the client:
[22:40] <bicchi> Dec  7 07:19:48 main-menu[349]: INFO: Menu item 'network-preseed' selected
[22:40] <bicchi> Dec  7 07:23:32 main-menu[349]: (process:1251): wget: bad address 'blah_blah'
[22:40] <bicchi> Dec  7 07:23:32 main-menu[349]: WARNING **: Configuring 'network-preseed' failed with error code 1
[22:40] <bicchi> the hostname blah_blah is the actually server with the preseed file
[22:41] <bicchi> during pxe booting it fails to obtain a dhcp address.
[22:41] <bicchi> in this case, i cannot ping blah_blah. but if I obtain a new lease with udhcpc, then i can ping that host.
[22:46] <cjwatson> if there's anything useful in the client log (there may not be), it will be before network-preseed starts
[22:47] <cjwatson> should be from netcfg
[23:03] <stgraber> cjwatson: running another set of tests with what should be a better fix for the problem, should have the results in ~10min (I need to make that stuff run in parallel)
[23:13] <stgraber> cjwatson: all the tests passed with http://paste.ubuntu.com/832023/
[23:14] <antarus> stgraber: what are you using to run tests?
[23:14] <stgraber> cjwatson: my current guess (from a quick look at the code) is that a subprocess or sub-subprocess of dhclient fails and that's what we were catching somehow (it looks like dhclient calls "ip" at some point which fails because of duplicate record but it's being ignored and AFAICS is safe to ignore)
[23:16] <stgraber> antarus: some python scripts I wrote driving libvirt and LXC containers. It's setting up 16 different networks (all combinations of ipv4 and ipv6), starts a container that's a router with an interface in each and the right radvd/dhcpd4/dhcpd6 config and then one "client" which is d-i running in LXC iterating through all the setups
[23:16] <stgraber> antarus: I still need to automate some more part of it to better test static IPs in preseed and have the reports be more than just a dump of test results on my screen :)
[23:17] <stgraber> the nice thing with running d-i in LXC is that I can easily modify any file in it or retrieve anything I want even while running
[23:17] <stgraber> that's on LP in: lp:~stgraber/+junk/v6-testing but quite behind from what I have currently here, I need to update the branch for Precise ...
[23:21] <antarus> stgraber: I was honestly hoping for a 'well we use this beautiful open source testing framework that you can download here!'
[23:21] <antarus> since we use...ummm autotest
[23:21] <antarus> and it sucks ;p