[00:59] <infinity> cjwatson: Oh, sorry, I've done enough d-i uploads in the past and never got chastised for not committing, didn't realise there was a process there.
[01:00] <infinity> cjwatson: (checking out and fixing now)
[01:04] <infinity> cjwatson: You didn't delete your tag.
[01:04]  * infinity sorts out if that can be done.
[01:05] <stgraber> infinity: "bzr tag blah --delete" works fine, unless someone else does a bzr push of the old tag later on...
[01:05] <infinity> stgraber: Yeah, I found --delete.
[01:05] <infinity> cjwatson: All fixed.  Sorry for the noise.
[01:05] <stgraber> we have that problem in the LTSP upstream branch where we've been trying to get rid of a tag for 2 weeks now and someone with bzr access pushes it again every few days ;)
[01:06] <infinity> Oh, --force would have worked too, didn't have to delete and re-tag.
[08:11] <gema> stgraber: we haven't tried in recent dailies. In fact, we stumbled upon bug 934614 because I convinced my boyfriend to install Precise on his machine because it is very stable and blah blah. And he installs trusting my word and he cannot boot his PC after installing. I gave him the alternate installer because it is more stable than ubiquity imo and I wanted the installation to go smoothly
[08:11] <ubot2`> Launchpad bug 934614 in grub2 "reinstall of precise breaks grub with invalid arch independent ELF magic" [High,Confirmed] https://launchpad.net/bugs/934614
[08:14] <gema> stgraber: but as it happens, he couldn't reboot after the install because grub2 had installed some EFI related files and broken compatibility.
[08:17] <gema> cjwatson: do you want me to split the bug in two and put the alternate problems on another one? we don't have more logs than the ones we already attached. The problem (given the solution) is grub2 broken efi-amd64 binaries (imo), because when uninstalled grub could boot properly. It is not my machine where it happened, but if you guys can point bwalex to a commit that has a fix, he will probably review it and try the new code on his 
[10:06] <cjwatson> gema: ah, didn't realise you knew bwalex.  Still, I can't investigate without /var/log/installer/syslog (commenteD)
[10:06] <cjwatson> s/D/d/
[10:07] <cjwatson> gema: also bwalex commented "except the partman log" - why?  I don't like it when people think I don't need logs :-)  In this case I'd like to see what kind of boot partition(s) are present
[10:52] <gema> cjwatson: I guess he thought there would be some confidential info there
[10:53] <gema> cjwatson: I will try to get those logs out of his machine when he comes home later today
[10:54] <cjwatson> thanks.  there shouldn't be, though it's worth double-checking that syslog doesn't accidentally have a password in it (that's why it's root:root 0600, just as a paranoia guard)
[10:54] <gema> cjwatson: ack, will do
[10:54] <cjwatson> partman shouldn't have anything at all confidential
[11:05] <gema> cjwatson: it'd be a good idea to have ubuntu-bug create a collection of files somewhere (without requiring any X to launch the browser) so that people can collect logs easily, even when only the basics are working
[11:05] <gema> cjwatson: not sure who to talk to about that, though
[11:07] <cjwatson> I thought you could use apport-cli for that
[11:07] <cjwatson> but as for who to talk to: that'd be pitti
[11:08] <gema> ok, will talk to him, we didn't manage to run any of those on saturday to collect logs, so I asked him for installer logs and hw profile only
[11:08] <cjwatson> (you could tell it to use w3m as the browser, I thought)
[11:08] <cjwatson> /var/log/installer/{syslog,partman} is probably all I actually need anyway
[11:10] <gema> cjwatson: the syslog is there already, inside the installer_log.tar.bz2
[11:10] <gema> cjwatson: the only file he left out was partman, for some reason I didn't thought of questioning, I will ask later
[12:01] <cjwatson> gema: huh, I swear it wasn't there first time I looked
[12:01]  * cjwatson looks askance at file-roller
[12:32] <gema> :D
[12:34] <gema> cjwatson: doing grub-install /dev/sda does the same thing, so not sure what partman output would be useful for
[12:36] <cjwatson> gema: I'd prefer to have it anyway
[12:36] <cjwatson> please
[12:37] <cjwatson> GRUB makes use of the partitioning layout to some extent depending on the exact firmware mode it's in
[12:47] <gema> cjwatson: ack, it is with you, in your ubuntu.com account, if you lose it for any reason by the time someone gets to fix it, just ask me and I will forward again
[13:00] <infinity> *yawn*
[13:01]  * barry waves
[13:02] <ogra_> *fnop*
[13:06] <cjwatson> hi folks
[13:06] <bdmurray> hi
[13:06]  * cjwatson quickly hoovers up some CD build bugs left over from the end of last week
[13:09] <jodh> hi
[13:09]  * ogra_ is here
[13:21] <ev> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/775124
[13:21] <ubot2`> Launchpad bug 775124 in ubiquity "Ubiquity should have a command line option to override the free space check" [Medium,Triaged]
[13:24] <stgraber> moving g+ to another machine
[13:26] <cjwatson> Page.min_size
[13:27]  * infinity wonders if he's the only one who keeps getting Firefox whining about Javascript execution times on hangouts.
[13:28] <bdmurray> infinity: I saw that too
[13:29] <infinity> Maybe I'll grab chromium.
[13:33] <barry> infinity: working okay for me in ff
[13:34] <stgraber> seems to work fine now in ff too after I moved from a 1.6Ghz atom CPU to a quad-core i7...
[13:34] <infinity> Yeah, that's not an option for me. :P
[13:35] <infinity> My webcam happens to be physically built in to an Atom system.
[13:39] <cjwatson> https://launchpadlibrarian.net/89083597/Traceback.txt
[13:39] <cjwatson>   File "/usr/lib/ubiquity/plugins/ubi-language.py", line 136, in on_try_hostname_clicked
[13:40] <cjwatson> bzr branch -rtag:2.9.10 ubiquity ubiquity-2.9.10
[13:45] <cjwatson> debug-ubiquity
[13:48] <cjwatson> partitioner: 779828
[13:52] <stgraber> VM where I reproduced it: vncviewer found-sprint.stgraber.org::10000
[13:52] <cjwatson> self.controller.dbfilter.done
[13:54] <cjwatson> wah, damn G+
[13:58] <cjwatson> barry: ubiquity --greeter --debug
[13:59] <cjwatson> /var/log/installer/debug
[14:00] <bdmurray> http://paste.ubuntu.com/890640/ has the different plugins where this occurs
[14:00] <bdmurray> er, has the language ones
[14:01] <bdmurray> http://paste.ubuntu.com/890644/ has all the different ones
[14:02] <cjwatson> so on_try_hostname_clicked is some kind of bizarre anomaly
[14:02] <bdmurray> it looks to me like there are also some in ubi-partman
[14:02] <infinity> cjwatson: It was a product of log cleansing, I assume/
[14:02] <infinity> cjwatson: s/$hostname/hostname/ (and the hostname is ubuntu)
[14:03] <cjwatson> it must have been, but I can't find where that would have been done
[14:04] <bdmurray> then that is probably a bug in apport
[14:04] <cjwatson> anyway, side issue
[14:04] <ev> I appear to have lost the ability to speak
[14:04] <infinity> Potentially a bug already fixed, if we're not seeing the pattern in other reports?
[14:04] <bdmurray> bug-911907/Traceback.txt:  File "/usr/lib/ubiquity/plugins/ubi-language.py", line 136, in on_try_hostname_clicked
[14:04] <cjwatson> so fundamentally we have ubi-language.py:on_try_ubuntu_clicked, ubi-console-setup.py:cleanup, ubi-partman.py:exit_ui_loops
[14:05] <ev> jodh: can you please file a bug for KVM not supporting UUIDs by default in http://launchpad.net/ubuntu/+source/whoopsie/+filebug
[14:05] <bdmurray> it looks like it just happens in the traceback
[14:05] <jodh> ev: will do.
[14:05] <ev> cheers
[14:08] <jodh> ev: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/959308
[14:08] <ubot2`> Launchpad bug 959308 in qemu-kvm "kvm does not generate a system uuid by default" [Undecided,New]
[14:08] <ev> jodh: thanks!
[14:08] <cjwatson> so grep for allow_change_step, allow_go_forward, allow_go_backward
[14:09] <cjwatson> those inhibit changing page and grey out the various associated buttons
[14:10] <cjwatson> perhaps add plugin_allow_blah methods to PageGtk/PageKde
[14:10] <ev> jodh: updated
[14:11] <cjwatson> self.controller.allowed_change_step()
[14:14] <ev> I've submitted merge 98203 for bug 956531. I'd appreciate if someone looked it over.
[14:14] <ubot2`> Launchpad bug 956531 in ubiquity "ubi-partman failed with exit code 141 ubi-partman.py line 2064, in run os.rmdir(mount_path) - OSError: [Errno 16] Device or resource busy" [High,Triaged] https://launchpad.net/bugs/956531
[14:14] <ev> argh, does ubotu not give us nice merge links?
[14:15] <cjwatson> I'll have a look
[14:15] <ev> cheers
[14:15] <ev> I've also created https://wiki.ubuntu.com/Installer/Development/Workflow which I'm hoping to build out as people potentially run into difficulty submitting branches to merge into trunk today
[14:15] <cjwatson> can you link the MP to the bug?
[14:15] <slangasek> right, so I think I can use G+ reliably, or run a VM, but not both :P
[14:15] <ev> will do
[14:15] <cjwatson> if you use debcommit and have LP: #blah in the changelog then it should get linked automatically
[14:15] <ev> probably should've used fixes there
[14:15] <ev> indeeb
[14:15] <ev> indeed even
[14:16] <infinity> slangasek: Hey, at least you can do one!
[14:16] <ev> I'll add a changelog entry
[14:16] <slangasek> cjwatson: you said on_try_hostname was an anomaly, what did you mean by that?  I still see that in my traceback on a daily ISO
[14:16] <cjwatson> there's no on_try_hostname_clicked in the codebase :-)
[14:16] <infinity> slangasek: You do?  You don't see on_try_ubuntu?
[14:16] <slangasek> heh, that's what I was seeing
[14:16] <slangasek> cjwatson: so if it doesn't exist in the codebase, where does it come from?! :)
[14:16] <infinity> slangasek: on_try_hostname would be an apport-log-cleansing s/$hostname/hostname/
[14:16] <cjwatson> barry: dpkg -L ubiquity
[14:17] <cjwatson> /usr/lib/ubiquity/
[14:17] <slangasek> infinity, cjwatson: ahhh
[14:17] <infinity> slangasek: At least, I think.
[14:17] <slangasek> right, now I understand
[14:17] <slangasek> you (or someone) said that earlier and I didn't parse
[14:17] <infinity> It was me, yes. :P
[14:17] <cjwatson> ./apport/report.py:1294:            replacements[hostname] = 'hostname'
[14:17] <infinity> Parse harder.
[14:17]  * cjwatson happily blames apport
[14:17] <slangasek> my parser was lagged, it's preemptively multitasking with G+
[14:18] <cjwatson> DEBCHANGE_RELEASE_HEURISTIC=changelog
[14:18] <cjwatson> DEBCHANGE_MULTIMAINT_MERGE=yes
[14:18] <cjwatson> (~/.devscripts)
[14:18] <CIA-32> ubiquity: stgraber * r5266 ubiquity/ubiquity/misc.py: Drop remaining debug code from ubiquity/misc.py
[14:20] <cjwatson> ev: commented
[14:20] <ev> thanks
[14:20] <slangasek> bdmurray: did you have enough info to split out these dupes now?
[14:22] <bdmurray> its not clear to me if the exit_ui_loops crash in ubi-partman is different or not
[14:22] <cjwatson> it is
[14:23] <cjwatson> it's sort of generally similar, but will need to be fixed separately
[14:23] <bdmurray> okay got it
[14:24] <stgraber> if someone wants to review: http://paste.ubuntu.com/890682/
[14:27] <cjwatson> stgraber: changelog?
[14:27] <stgraber> cjwatson: oops, would be easier with a changelog indeed ;)
[14:29] <stgraber> http://paste.ubuntu.com/890689/
[14:29] <stgraber> there you go
[14:29] <bdmurray> so I'll make 897044 the ubi-partman - exit_ui_loops master
[14:31] <slangasek> bdmurray: thanks
[14:31] <slangasek> bdmurray: the ubi-console-setup.py:cleanup seems to also be different, per cjwatson ?
[14:32] <cjwatson> yes
[14:32] <cjwatson> although I think stgraber indicated he'd fixed that part
[14:33] <slangasek> and did this duping happen automatically via the retracer or something?
[14:33] <slangasek> ok
[14:33] <cjwatson> barry: dch -U
[14:33] <bdmurray> stgraber: do you know when you fixed it? so we can see if it happend in a later version
[14:33] <slangasek> barry: DEBCHANGE_RELEASE_HEURISTIC=changelog >> ~/.devscripts should be sufficient to DTRT
[14:33] <stgraber> bdmurray: beta1 was the first image with the fix
[14:37]  * cjwatson glares at bug 944191
[14:37] <ubot2`> Launchpad bug 944191 in ubiquity "Installation program crashed while typing username" [Undecided,New] https://launchpad.net/bugs/944191
[14:37] <cjwatson> I thought I'd fixed that in ubiquity 2.9.19, but that bug was filed with 2.9.23
[14:38] <cjwatson> install_misc.remove_target even has tests
[14:38] <bdmurray> oh actually the first bug we looked at had the crash in ubi-partman
[14:39] <bdmurray> so the ubi-language ones should be broken out
[14:40] <cjwatson> yeah
[14:40] <barry> cjwatson: https://code.launchpad.net/~barry/ubiquity/bug-792652/+merge/98209
[14:40] <bdmurray> and barry's branch fixes a different bug
[14:41] <cjwatson> right, what's the correct master bug number for barry's bug?
[14:41] <cjwatson> the branch is fine otherwise
[14:42] <bdmurray> lets use the newest one - 911907 - it still needs to be unmarked as a dupe
[14:42] <cjwatson> ok, barry, can you substitute that?
[14:42] <barry> bdmurray, cjwatson yep
[14:43]  * cjwatson goes to refuel
[14:44] <ev> https://code.launchpad.net/~ev/ubiquity/956531/+merge/98203 - updated
[14:45] <barry> cjwatson: branch update pushed; i'm not going to push to a different branch name ;)
[14:45]  * infinity goes to find a beverage and nicotine.
[14:48] <cjwatson> barry: this is going to come across as a bit "oh, and another thing" - but I think it should be possible to unit-test this, and it'd be a good exercise
[14:48]  * jodh needs tea...
[14:49] <cjwatson> you would do that by instantiating the UI widget in a test, firing the try-ubuntu-clicked event twice, and only then processing events
[14:49] <barry> cjwatson: sure, it would be a good exercise for me to figure out how to do that.  so, let me look into that.
[14:49] <cjwatson> the wiki has details on running the test suite
[14:49] <barry> cool.  first, more tea, then i'll look at that
[14:49] <cjwatson> in this case I guess the test case ought to go in tests/test_language.pyp
[14:49] <cjwatson> -p
[14:50] <cjwatson> (and I think it'd be good for other folks to see how that's done, too, UI tests being their own special black art)
[14:50] <cjwatson> I don't especially care about separate tests for the KDE frontend - there's no framework for that as yet - but at least the GTK frontend
[14:50] <barry> right.  i've never done that before, so it's good to learn it.
[14:50] <barry> brb
[14:51] <cjwatson> there's a "gtkwidgets.refresh()" helper that processes any events that are pending
[14:51] <cjwatson> you'll see it used in other tests
[14:51] <cjwatson> the trick here may be in arranging for the backend filter to be in place
[14:57] <cjwatson> slangasek: r4693 is what moved this into exit_ui_loops
[14:57] <cjwatson> in response to bug 756920
[14:57] <ubot2`> Launchpad bug 756920 in ubiquity "Natty manual-partitioner is dangerously forgetful" [High,Fix released] https://launchpad.net/bugs/756920
[15:02] <bdmurray> so jibel has a testcase in bug 942111 which is also regarding exit_ui_loops
[15:02] <ubot2`> Launchpad bug 942111 in ubiquity "ubiquity crashed in ubi-partman.py : ValueError: I/O operation on closed file" [High,New] https://launchpad.net/bugs/942111
[15:02] <cjwatson> slangasek: I've recorded my thoughts on this in bug 792652
[15:02] <ubot2`> Launchpad bug 792652 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file" [High,Triaged] https://launchpad.net/bugs/792652
[15:03] <cjwatson> bdmurray: right, that makes sense, the danger is in interactions between different things that talk to the UI in parallel
[15:03] <cjwatson> so quitting while a wifi operation was in progress would be a good candidate
[15:04] <infinity> Does anyone know what "corner image" is being referred to in bug 942543?
[15:04] <ubot2`> Launchpad bug 942543 in ubiquity "[KDE] UI needs graphics to match wallpaper" [Medium,New] https://launchpad.net/bugs/942543
[15:04] <bdmurray> his last comment seems different than the original description
[15:04] <infinity> The swirly watermark looking thing in the bottom left?
[15:05] <ogra_> ask for a screenshot or photo ?
[15:07]  * bdmurray getting coffee
[15:12] <ev> Just a reminder to be making merge proposals for anything beyond a simple change. Feel free to ping me when you've made one, otherwise I'll be occasionally hitting refresh on this: https://code.launchpad.net/ubiquity/+activereviews
[15:15] <ev> I'm looking over this https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/658865
[15:15] <ubot2`> Launchpad bug 658865 in baltix "Install from USB fails: "An attempt to configure apt to install additional packages from the CD failed"" [Undecided,New]
[15:15]  * ogra_ is looking at the oem-config arm bugs 
[15:15] <infinity> I'm muted, it's not me. :P
[15:15] <cjwatson> I'm trying to track down bug 944191
[15:15] <ubot2`> Launchpad bug 944191 in ubiquity "Installation program crashed while typing username" [Undecided,New] https://launchpad.net/bugs/944191
[15:15]  * ogra_ is muted too 
[15:15] <infinity> I'm going to bounce myself offline for a bit while I test a kernel for apw on my router.
[15:16] <barry> i'm currently working on writing tests for bug 792652 / bug 911907
[15:16] <ubot2`> Launchpad bug 792652 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file" [High,Triaged] https://launchpad.net/bugs/792652
[15:16] <ubot2`> Launchpad bug 911907 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file" [Medium,Triaged] https://launchpad.net/bugs/911907
[15:16]  * jodh is looking at remove_target() issue /  bug 891711.
[15:16] <ubot2`> Launchpad bug 891711 in ubiquity "Fails to copy directory over symlink (e.g. /var/lock when downgrading from 11.10 to 11.04)" [High,Confirmed] https://launchpad.net/bugs/891711
[15:17] <cjwatson> jodh: that bug is closed ...
[15:17]  * jodh (aka bug 944191 :)
[15:17] <ubot2`> Launchpad bug 944191 in ubiquity "Installation program crashed while typing username" [Undecided,New] https://launchpad.net/bugs/944191
[15:17] <cjwatson> ah, we're duping
[15:17] <cjwatson> feel free to take that - FWIW my hypothesis is that this happens when /var in the target is a mountpoint
[15:18] <cjwatson> in that case we ought not to remove the target directory, and should just cope with it existing
[15:18] <jodh> cjwatson: I'm easy. Happy to look at something else.
[15:18] <cjwatson> I don't want to steal bugs from people, I work on this code all the time :)
[15:19] <bdmurray> cjwatson: looking at the syslog in bug 933143 there are 2 tracebacks
[15:19] <ubot2`> Launchpad bug 933143 in ubiquity "just one of many problems booting a linux raid or fake raid partition" [Undecided,New] https://launchpad.net/bugs/933143
[15:19] <jodh> bug 946663 looks interesting, but I don't seem to have a checkout of that right part of the installer containing that msg.
[15:19] <cjwatson> jodh: so go ahead, just wanted to brain-dump where I'd got to so far, and I'm guessing that should be enough to reproduce the bug
[15:19] <ubot2`> Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663
[15:19] <bdmurray> one regarding exit_ui_loops and then grub-installer fails much later
[15:20] <cjwatson> right
[15:20] <stgraber> if someone has a minute: http://paste.ubuntu.com/890785/
[15:20] <cjwatson> it just managed to muddle on past the first failure
[15:20] <cjwatson> so let's not consider it as related to 792652 et al
[15:20] <stgraber> cjwatson: I ended up using the table from gfxboot-theme-ubuntu, adapting for python and tweaking some entries to work for country => layout instead of locale => layout
[15:21] <stgraber> all the weird ones I know are covered by that table, so we should be mostly good
[15:22] <cjwatson> stgraber: it'd be nice to see a test for the case where the default_keymap entry contains '_'
[15:22] <cjwatson> e.g. fr
[15:23] <cjwatson> otherwise I think that seems ok
[15:23] <stgraber> cjwatson: oh, indeed, I'll add that quickly
[15:27] <cjwatson> I think I'll try to tackle bug 658865, then, since nobody else has mentioned that and it's on rls-p-tracking
[15:27] <ubot2`> Launchpad bug 658865 in baltix "Install from USB fails: "An attempt to configure apt to install additional packages from the CD failed"" [Undecided,New] https://launchpad.net/bugs/658865
[15:27]  * cjwatson assigns to himself
[15:27] <cjwatson> (please assign to yourself when you're working on an installer bug, actually - there are enough of us in parallel that that's worthwhile)
[15:27] <cjwatson> you can always unassign / team-assign if you need to give up
[15:28] <bdmurray> I thought ev said he was looking at that one
[15:28] <cjwatson> oh, doh
[15:28] <cjwatson> ASSIGN :-)
[15:28] <ev> oh yes, apols
[15:28]  * cjwatson assigns to ev
[15:28] <ev> cheers
[15:28] <cjwatson> so I guess I'll go back to bug 855871, which I was working on at the tail-end of last week
[15:28] <ubot2`> Launchpad bug 855871 in ubiquity "Grub install fails after manual xfs partitioning" [Medium,Confirmed] https://launchpad.net/bugs/855871
[15:36] <stgraber> cjwatson: adding that check actually made me notice a small problem with my implementation :)
[15:36] <stgraber> cjwatson: http://paste.ubuntu.com/890810/ is the fixed one
[15:37] <cjwatson> stgraber: I wondered if it might, that's why I asked ;-)
[15:38] <barry> cjwatson: sorry, i've looked around a bit, but i'm kind of lost on how to test this change.  i would think i need to simulate multiple clicks on Try Ubuntu and then call gtkwidgets.refresh() and then ensure that the mocked controller only got one click.  does that sound like the right general approach, and if so, is there an example of "simulate multiple clicks" that i might look at?
[15:38] <cjwatson> stgraber: looks fine, just style points, space after comma in those .replace calls, maybe assign default_keymap[lang].replace('_', '\t') to a temporary so it's less repetitive, and fix the version in changelog
[15:38] <cjwatson> barry: yes, you can just call the .clicked method on any widget
[15:39] <cjwatson> er, I think, let me check
[15:39] <cjwatson> yes, on any button widget anyway
[15:40] <barry> cjwatson: one problem is that i created a new test_() method in test_language.py, then i set a breakpoint.  i would have expected self.gtk.try_ubuntu to be the widget, but it's value is None, so i probably haven't set something up correctly
[15:40] <cjwatson> pastebin your test diff so far?
[15:41] <barry> yep, sec.
[15:42] <cjwatson> oh, I think you need to arrange for controller.oem_user_config to be False in this test
[15:42] <barry> cjwatson: http://pastebin.ubuntu.com/890816/
[15:42] <cjwatson> before PageGtk is constructed
[15:42] <barry> ah
[15:42] <cjwatson> otherwise the gtkbuilder file that gets loaded is gui/gtk/stepLanguageOnly.ui which doesn't have the try_ubuntu widget
[15:43] <barry> cool, let me try that
[15:43] <cjwatson> probably a bit fiddly to make that per-test
[15:43] <barry> yeah, i can create a new TestCase
[15:43] <cjwatson> that works, or move the bottom half of setUp into individual tests, whatever seems cleanest
[15:45] <barry> that might be better since there is only one test in the class atm
[15:47] <stgraber> ev: do you have CIA configured on your machine?
[15:48] <ev> stgraber: oops, no
[15:48] <stgraber> ev: I don't remember seeing r5267 on IRC
[15:48] <ev> stgraber: do you have the branch bound? :)
[15:48]  * ev just discovered that alt-f10 changed
[15:48] <ev> rage
[15:49] <cjwatson> I just gave up and rebound my local stuff to F11/F12 since unity is intent on stealing keybindings I've had since 1999
[15:49] <stgraber> ev: yep, I do, but in this case I'd have avoided a debian/changelog conflict ;)
[15:49] <CIA-32> ubiquity: stgraber * r5268 ubiquity/ (debian/changelog tests/test_misc.py ubiquity/misc.py):
[15:49] <CIA-32> ubiquity: Change set_indicator_keymaps to only expect a language name. Drop any code
[15:49] <CIA-32> ubiquity: dealing with the country (as we don't get it anyway) and instead add a
[15:49] <CIA-32> ubiquity: dictionary doing some language => default layout mapping. Update the tests and
[15:49] <CIA-32> ubiquity: add a new one to test the dictionary.
[15:50] <ev> apols
[15:51] <bdmurray> I'm looking at bug 955265 and wondering if continue should be disabled if the detect keyboard layout dialog is present
[15:51] <ubot2`> Launchpad bug 955265 in ubiquity "keyboard detection dialog doesn't close on exit of Keyboard layout screen" [High,New] https://launchpad.net/bugs/955265
[15:51] <infinity> stgraber: Thanks for reminding me that I haven't reinstalled CIA since rebuilding my laptop.
[15:51] <ev> yes, that's a grand idea
[15:51] <ev> bdmurray: ^
[15:52] <ev> the window is supposed to be modal
[15:52] <ev> so I think a slightly better fix would be to ensure that it is, as it also doesn't make sense if the user can click around the languages while the detection window is u
[15:52] <ev> up
[15:52] <ev> not that it would crash the installer
[15:53] <stgraber> bdmurray: are you fixing it or just looking at the bug? I remember seeing it last week and putting it on my todo list (though not assigning yet) so I'm happy to take it
[15:55] <bdmurray> stgraber: I was going to take a stab at fixing it
[15:56] <stgraber> bdmurray: cool, let me know if you need help
[16:02]  * slangasek calmly stabs firefox in the face
[16:05]  * cjwatson eyes the various things he needs to fix in grub2 and would like it to keep building please
[16:06] <gema> cjwatson: regarding the bug we were discussing this morning, there seems to be an EFI problem with the kernel, that may explain why grub was failing, see bug 959286
[16:06] <ubot2`> Launchpad bug 959286 in linux "EFI related kernel panic on reboot from alternate installer " [Medium,Confirmed] https://launchpad.net/bugs/959286
[16:06] <cjwatson> gema: the error message you quoted is before the kernel is loaded
[16:07] <gema> yes, but the kernel panicked before rebooting from the install as well
[16:08] <gema> cjwatson: and given that uninstalling the EFI related grub stuff made the machine reboot and EFI fall back to bios behaviour, everything worked nicely after that
[16:08] <gema> cjwatson: I think they are related, but may be wrong
[16:08] <gema> cjwatson: I didn't know how EFI/bios worked until I had a chat with the kernel guys before
[16:09] <cjwatson> well, I'll ignore it if you like :)
[16:09] <cjwatson> it doesn't seem obviously related, unless the kernel is corrupting EFI state in the process of panicking
[16:09] <cjwatson> which ought to be impossible but who knows with EFI
[16:10] <gema> cjwatson: I will leave it in your capable hands, you know more about grub  and how it loads the kernel and they all dance together...
[16:10] <stgraber> any thought on https://code.launchpad.net/~quadrispro/ubiquity/fix-690912/+merge/44052 should we merge that for 12.04 or defer to 12.10 (as it's technically a new "feature")
[16:10] <cjwatson> gema: probably won't be able to look until Thursday, since grub isn't really the installer
[16:11] <gema> cjwatson: by then we should have figured out the kernel side, will keep you posted
[16:11] <cjwatson> ok
[16:13] <barry> cjwatson: so, this pastebin: http://pastebin.ubuntu.com/890865/ with breakpoints set in (both) on_try_ubuntu_clicked(), i never hit the breakpoints
[16:16] <infinity> cjwatson: Have you read mjg59's latest blog rant?  Corruption of EFI bits seems like a feature. :P
[16:17] <infinity> stgraber: It's technically a feature, but it's pretty tiny and seemingly harmless (famous last words).
[16:18] <stgraber> infinity: yeah, I guess I'll merge it and fix some bits of the implementation, it's been around for long enough that I don't want to forget it again for 12.10 ;)
[16:18] <infinity> stgraber: Yeah.  I do so hate the constant "defer ; i forgot ; defer" loop.
[16:19] <infinity> stgraber: Plus, with other people often basing their own custom images off LTSes for the next few years, this seems like a nice-to-have.
[16:23] <cjwatson> infinity: possibly not the most recent one ...
[16:23] <infinity> cjwatson: http://mjg59.dreamwidth.org/11235.html
[16:23] <cjwatson> barry: can I have the actual diff, so I can quickly apply it and try it locally?
[16:24] <infinity> cjwatson: Basically about EFI drivers DMAing into la-la land after the OS has booted.
[16:24] <stgraber> infinity: http://paste.ubuntu.com/890874/ does that look sane to you?
[16:24] <barry> cjwatson: against my previous branch push: http://paste.ubuntu.com/890875/
[16:25] <cjwatson> infinity: oh, yeah, I've seen that myself
[16:25] <infinity> stgraber: I'd probably ditch the "internal use" thing.  Who are we to tell people when they can and can't use a preseed?  (reading the code now).
[16:25] <cjwatson> "internal use" is supposed to be a sort of keyword
[16:26] <cjwatson> it suppresses some lintian complaints
[16:26] <cjwatson> (iirc)
[16:26] <infinity> cjwatson: Ahh, alright.  I hadn't noticed it elsewhere before.
[16:26] <slangasek> about non-translatable questions, IIRC
[16:26] <cjwatson> yeah
[16:27] <stgraber> infinity: changed to: Description: for internal use; can be preseeded
[16:27] <stgraber> so still using the keyword but using it consistent with the rest of .templates
[16:28] <infinity> stgraber: Man, it breaks my brain that the two os.path conditionals are inverted.
[16:28] <infinity> stgraber: But looks right to me.
[16:30] <barry> cjwatson: UBIQUITY_GREETER=1 tests/run seems to fix it
[16:30] <stgraber> infinity: yeah, took me a few times to convince myself the diff was right too ;)
[16:30] <cjwatson> ah - so need to set that in that test
[16:30] <cjwatson> (sorry, was still building)
[16:30] <barry> cjwatson: apparently so ;)
[16:31] <cjwatson> best to use test_support.EnvironmentVarGuard or whatever it is to avoid leakage
[16:31] <barry> cjwatson: yep
[16:31] <CIA-32> ubiquity: stgraber * r5269 ubiquity/ (5 files in 2 dirs): Make the slideshow optional based on the value of ubiquity/hide_slideshow, defaults to False.
[16:32] <cjwatson> not seeing a failure right now with that test, though, and without the fix applied
[16:32] <cjwatson> (but maybe your time is not best spent in helping me to reproduce it :-) )
[16:32] <jibel> stgraber, another problem with the kb indicator bug 956912
[16:32] <ubot2`> Launchpad bug 956912 in casper "wrong layout switcher in live session - default english layout is "Cameroon"" [High,Confirmed] https://launchpad.net/bugs/956912
[16:33] <stgraber> jibel: already fixed ;)
[16:33] <stgraber> jibel: r5268 in ubiquity trunk, I'll assign it to me and add the bug number to the changelog
[16:34] <jibel> stgraber, ok, thanks.
[16:36] <stgraber> jibel: hmm, actually, part of the problem has been fixed but I'm not sure all of what they're describing in the bug has
[16:36] <stgraber> I guess I'll have to do some more persistent testing then :)
[16:37] <CIA-32> ubiquity: stgraber * r5270 ubiquity/debian/changelog: Add a reference to bug 956912 in the previous indicator fix.
[16:37] <ubot2`> Launchpad bug 956912 in ubiquity "wrong layout switcher in live session - default english layout is "Cameroon"" [High,Confirmed] https://launchpad.net/bugs/956912
[16:39]  * cjwatson wanders off for a short while until grub builds so he has some CPU again
[16:40]  * cjwatson reviews pitti's branch first
[16:43] <slangasek> hah, cute - bug #876298 has a task on the 'diod' package
[16:43] <ubot2`> Launchpad bug 876298 in diod "[MASTER] We need to better handle external payloads (Flash, msttcorefonts) not being available." [Undecided,Confirmed] https://launchpad.net/bugs/876298
[16:43] <slangasek> because someone whose username is 'diod' marked the bug as affecting himself
[16:43] <infinity> Special.
[16:46] <bdmurray> j:q
[16:54] <CIA-32> ubiquity: cjwatson * r5271 trunk/ (debian/changelog tests/test_migrationassistant.py): merge lp:~pitti/ubiquity/indicator-soname, with a tweak to tolerate pygobject < 3.1.92 for now
[16:57]  * infinity is having web development flashback nightmares with this QT CSS implementation.
[16:59] <barry> ev, cjwatson update pushed to https://code.launchpad.net/~barry/ubiquity/bug-792652/+merge/98209
[17:01]  * cjwatson gives up on G+ for a while in order to get his browser back
[17:02]  * slangasek gives up on G+ and eats lunch
[17:03] <cjwatson> barry: reviewing
[17:03] <stgraber> lunch sounds like a good idea, see you in a bit
[17:04] <barry> cjwatson: cool, i'll hang out until that's done then get some lunch
[17:04] <CIA-32> ubiquity: adconrad * r5272 trunk/ (4 files in 3 dirs): Drop gui/qt/images/squares.png and add a single pixel transparent placeholder
[17:05] <cjwatson> barry: go for lunch, it's fine :)
[17:05] <cjwatson> merging
[17:05] <barry> cjwatson: yay!  thanks
[17:05]  * infinity goes to find a snack.
[17:06]  * jodh goes to "lunch"
[17:06] <CIA-32> ubiquity: cjwatson * r5273 trunk/ (3 files in 3 dirs): merge lp:~barry/ubiquity/bug-792652
[17:11] <barry> okay, really lunch now
[17:15]  * jodh decides it's actually too early for "lunch".
[17:16] <infinity> Crazy talk.
[17:16] <infinity> It's been lunch time since I woke up, which was altogether too early, given that it was 3 hours after I fell asleep.
[17:17] <cjwatson> please let me know if you do installer-relevant stuff that doesn't show up in the ubiquity changelog, so that I can make sure it's in the change list presented to testers this week
[17:18]  * stgraber is starting his now usual "let's blame gnome-settings-daemon"
[17:19] <infinity> stgraber: Could bug 930741 be another manifestation of your console-setup race?
[17:19] <ubot2`> Launchpad bug 930741 in ubiquity "installing kubuntu, change keyboard layout in braile" [Undecided,New] https://launchpad.net/bugs/930741
[17:19] <stgraber> I ran diffs on both the output of "xprop -root" and "gsettings list-recursively" between a test run with the wrong and the bad layout, both of which gave 100% identical results but completely different behaviour
[17:20] <stgraber> infinity: that's probably been fixed by the console-setup I did last week
[17:20] <stgraber> infinity: basically console-setup's builtin list of X keyboard layout was out of date and didn't match ubiquity's
[17:20] <infinity> stgraber: Care to follow up to it, then, since you seem to know what's going on there? :)
[17:20] <stgraber> infinity: so selecting one of the layouts that got dropped would cause the IndexError
[17:21]  * infinity finds snacks with more vigor.
[17:21] <stgraber> infinity: I'd just mark it fix released, saying that console-setup 1.70ubuntu3 fixed it
[17:22] <infinity> stgraber: That works too.
[17:22] <stgraber> infinity: done
[17:22] <stgraber> infinity: (copy/pasted the IRC log and marked fix released)
[17:23] <cjwatson> http://pad.ubuntu.com/ubuntu-installer-sprint
[17:23]  * jodh wonders why the installer think I've got a Cameroon keyboard layout.
[17:23] <cjwatson> feel free to add other note-taking sections there if it's useful
[17:23] <cjwatson> jodh: bug 956912
[17:23] <ubot2`> Launchpad bug 956912 in ubiquity "wrong layout switcher in live session - default english layout is "Cameroon"" [High,Confirmed] https://launchpad.net/bugs/956912
[17:23]  * cjwatson -> dinner
[17:33] <ogra_> wow, dd'ing installer images to SD cards seriously kills my multimedia all over the place on this machine
[17:38]  * ogra_ grumbles ... seems todays arm server preinstalled doesnt have a partition table 
[17:43] <ogra_> infinity, are the md5sums of the arm images supposed to be right ?
[18:00]  * ogra_ re-downloads the arm server image seems all my downloaded ones are corrupt
[18:08]  * bdmurray is on a call
[18:15] <barry> any bug in particular you'd like me to look at next?
[18:18] <cjwatson> grumble, need another grub2 backport
[18:19] <slangasek> ogra_: yeah, I've seen issues with SD support on my ThinkPad causing dismal performance too
[18:20] <ogra_> with the broken md5sums its really hard to verify if the dd broke it or the imageas corrupt :/
[18:20] <ogra_> err
[18:20] <ogra_> *the image was
[18:20] <ogra_> oh, i suppose i could just dirctly md5sum them on nusakan
[18:21]  * ogra_ does that
[18:21] <slangasek> yeah, and nudge infinity if it's still broken
[18:21] <barry> slangasek: got another bug you'd particularly like me to work on?
[18:21] <slangasek> hmm, let's see
[18:22] <slangasek> barry: well, 792652 is still out there if you want to give that one a try :)
[18:22] <barry> slangasek: sure :)
[18:23]  * ogra_ tries to try bug 924018 once again ... but first i need working images at all ....
[18:23] <ubot2`> Launchpad bug 924018 in ubiquity "Preseeding doesn't work with oem-config" [Medium,Confirmed] https://launchpad.net/bugs/924018
[18:23] <ogra_> hmm, and the md5 matches
[18:29] <ogra_> sudo sync
[18:29] <ogra_> oops
[18:30] <GrueMaster> ogra_: Which ubuntu-server image is broken?  omap4 looks ok here.
[18:30] <GrueMaster> (although md5sums are hosed).
[18:31] <ogra_> GrueMaster, works now, i think my machine is just to overloaded
[18:31] <GrueMaster> Are you flashing on the AC100 or laptop?
[18:31] <ogra_> G+ plus playing BG music, plus a million open bugpages etc
[18:31] <ogra_> the lappie
[18:31] <GrueMaster> Heh, that would do it.
[18:32] <GrueMaster> Newer laptops have the SD reader as a usb device.  Creates more contention for what we do.
[18:33] <GrueMaster> I find it impossible to flash an SD from an external USB drive on my netbook.
[18:33] <slangasek> my SD reader causes contention with things that *aren't* usb based; not sure why that would be
[18:33] <ogra_> mine is native
[18:33] <ogra_> (i actually get mmcblk* devices here)
[18:35] <GrueMaster> So, I see there is an installer sprint happening this week.  Any chance of getting bug 747229 and bug 924018 looked at?
[18:35] <ubot2`> Launchpad bug 747229 in ubiquity "weird color change during oem-config debconf package removal step in serial installs" [Medium,Confirmed] https://launchpad.net/bugs/747229
[18:35] <ubot2`> Launchpad bug 924018 in ubiquity "Preseeding doesn't work with oem-config" [Medium,Confirmed] https://launchpad.net/bugs/924018
[18:35] <ogra_> GrueMaster, i'm on the latter
[18:35] <ogra_> and hope to have it nailed down latest by wed.
[18:36] <GrueMaster> Excellent.  That is really the only thing holding up preinstalled image test automation.
[18:36] <GrueMaster> (not that it is a priority for me anymore).
[18:36] <ogra_> i looked into the color stuff on friday but didnt get anywhere with playing with the different debconf frontend settings
[18:37] <ogra_> (suspecting that it changes somewhere, but that was a red herring)
[18:37] <GrueMaster> The color issue may be debconf leaving the console in a weird state when it exits.
[18:37] <GrueMaster> I noted some more test info on the bug.
[18:38] <ogra_> GrueMaster, did you ever test the preseed you attached to the preseeding bug ?
[18:38] <GrueMaster> One thing I was going to try was to hack the scripts before running on a new image to dump the environment out.
[18:38] <GrueMaster> Yes I did.
[18:38]  * ogra_ isnt sure even the username comes from there
[18:38] <ogra_> it doesnt seem to be applied at all
[18:42] <GrueMaster> I'll give it another go for good measure and see what (if anything) gets applied.
[18:52] <GrueMaster> ogra_: It seems to be getting the username, that is it.
[18:52] <GrueMaster> If I don't use the preseed, the default is blank.  With the preseed, it is using "Ubuntu ".
[18:52] <ogra_> and thats weird, since the "applying" actually happens before the first boot
[18:53] <ogra_> so there should actually all values be preseeded
[18:53] <ogra_> or none
[18:55] <GrueMaster> Do I need to change the boot.scr or will just putting the preseed.cfg in / suffice?
[18:55] <ogra_> hmm, this dd actually killed my webcam *and* the indicator weather plugin
[18:55] <ogra_> GrueMaster, jasper defaults to read from /
[18:56] <ogra_> i dont think i even implemented anything beyond that since it would involve having networking support in the inird
[18:56]  * cjwatson tests a fix for bug 955617
[18:56] <ubot2`> Launchpad bug 955617 in casper "ubiquity hangs (no activity forever) at configuring target system" [High,In progress] https://launchpad.net/bugs/955617
[18:58] <GrueMaster> ogra_: Ok, just wasn't sure if I needed a file= directive or something.
[18:59] <ogra_> GrueMaster, hmmm
[18:59] <ogra_> looking at the preseed.cfg i actually suspect we need to use ubiquity values in many of the d-i ones you use there
[18:59] <ogra_> and bump ubiquity/oem-config into automatic mode too
[19:00] <cjwatson> the owner field won't matter much
[19:00] <cjwatson> wouldn't worry about it
[19:02] <ogra_> cjwatson, well, seems the ones prefixed with oem-config are actually applied,  i dont see the ones prefixed with d-i being used though
[19:04] <ogra_> hmm, even though ... i just notice things like:
[19:04] <ogra_> oem-config passwd/user-fullname string Ubuntu
[19:04] <ogra_> as well as
[19:05] <ogra_> d-i passwd/user-fullname string Ubuntu
[19:05] <ogra_> heh
[19:05] <ogra_> so i cant really say which one is applied
[19:05] <ogra_> :P
[19:05]  * ogra_ cleans that up
[19:07] <ogra_> lets see
[19:07] <cjwatson> wow, megaflickery lights.  if I drop off you know why
[19:07] <ogra_> i dropped all redundant oem-config lines
[19:07]  * ogra_ sighs that it is so time consuming to debug that ... every test install means i need to completely start from scratch 
[19:07] <cjwatson> this is actually quite headache-inducing
[19:08] <GrueMaster> ogra_: A log of that was shear guesswork from dumping debconf-get-selections.
[19:08] <GrueMaster> *lot
[19:08] <ogra_> GrueMaster, well, i think we see two issues here
[19:08] <cjwatson> for oem-config it's really worth trying to get it working in an emulator, even if you have to hack it up to fake the architecture or whatever
[19:08]  * slangasek scratches "rave" off the list of ideas for team outing
[19:08] <cjwatson> 'qemu-img snapshot' speeds things up quite a lot
[19:08] <ogra_> cjwatson, i fear using a panda is still faster but i could try
[19:09] <ogra_> especially since our image wont boot in qemu as is
[19:09] <GrueMaster> Will the omap image boot in qemu?
[19:09] <ogra_> not as is ...
[19:09] <GrueMaster> bummer.
[19:10] <ogra_> and i suspect jasper wouldnt be very happy to not find an actual SD interface to do the resizing
[19:10] <kyleN> ev. Hi. regarding ubiquity-frontend-gtk. We would like to use this but provide our own sources.list file(s). Is there a straightforward way to do this?
[19:10] <ogra_> (and the initrd modifications)
[19:11] <GrueMaster> Any way to generate an x86 preinstalled image that could be run in a vm?
[19:11] <ogra_> so back to my two issues above ...
[19:11] <ogra_> a) the preseed file is incomplete
[19:11] <ogra_> b) i think we need to tell oem-config/ubiquity to run in automatic mode to not prompt at all
[19:12] <GrueMaster> I tried b.  oem-config ignores everything but debug as a parameter iirc.
[19:13] <ogra_> wasnt there a preseed value that enabled automatic ?
[19:13] <ogra_> or a cmdline option
[19:13] <ogra_> ha !
[19:13] <ogra_> hmm, no
[19:14] <ogra_> i thought if i kill the board before oem-config finishes i could speed up the process ... but indeed preseed.cfg only gets applied during/right after resizing
[19:18] <GrueMaster> If you need me to try different preseeds, let me know.  Might be quicker here as I have multiple systems.
[19:18] <ogra_> well, i should be able to apply the preseed file manually
[19:19] <ogra_> though i have other issues atm, seems my last dd killed the BT stack as well as the camera and G+ at the same time
[19:19] <ogra_> at least IRC survived
[19:19] <GrueMaster> applying it is one thing.  Getting oem-config to recognize it is another.
[19:20] <cjwatson> my study light went out, but the rest of the house seems fine aside from a router blip - wonder if the bulb just went and tripped a breaker briefly
[19:25] <ogra_> phew, BT back up
[19:29]  * infinity glares at his Internets.
[19:30] <infinity> ogra_: It's not technically an "installer" bug, but maybe fixing your md5sums today would be a good thing.  I'll go poke that with a larger stick.
[19:30] <ogra_> infinity, well, the issue was on my side, seems the dd did weird things on my machine
[19:31] <ogra_> and i just md5 summed on nusakan manually
[19:31] <infinity> Yes, not a luxury everyone had. ;)
[19:31] <infinity> s/had/has/
[19:40] <barry> jodh: http://pastebin.ubuntu.com/891159/
[19:44] <cjwatson> ok, so the reason I don't have G+ on now is that I'm working in the dark :-/
[19:44] <cjwatson> unexpected lightbulb supply depletion - I'll have to sort that out tomorrow
[19:45] <jodh> cjwatson: I'm surprised your keyboard doesn't glow given the speed you type! ;)
[19:46] <bdmurray> it seems to me that /var/log/installer/debug is created even if you aren't running ubiquity in debug
[19:47] <bdmurray> so then we have these bug reports with ubiquitydebug attachments that aren't really from installs run with with --debug
[19:47] <cjwatson> we do actually have a light-up keyboard somewhere in the house :)
[19:47] <cjwatson> bdmurray: yep, it gets the stderr or some such
[19:49] <bdmurray> cjwatson: is there some way to distinguish between the two going forward?
[19:51] <ogra_> grmpf, so automatic-ubiquity is definitely not working in oem-config mode
[19:52] <slangasek> cjwatson: surely you can just remove the ir filter from the webcam
[19:53] <cjwatson> bdmurray: what for?
[19:53] <ogra_> (or i'm doing something wrong)
[19:53] <cjwatson> if we're asking for --debug, it should be because a developer has looked at the bug and determined that they don't have enough information as it stands and that --debug will help
[19:54] <cjwatson> I can't think of a reason to scan for it automatically ...
[19:55] <cjwatson> slangasek: more that it'll look like I'm in a morgue
[19:56] <ogra_> sigh, and there my bluetooth died again
[19:56]  * ogra_ really wishes he hadnt switched to the x86 machine for the sprint, i never have such issues on my arm machines despite them being slow they are at least stable 
[19:57] <stgraber> can anyone sanity check http://paste.ubuntu.com/891183/ ?
[19:57] <stgraber> it seems to work for me but I've been working on it for way too long to be convinced it's good ;)
[19:58] <stgraber> (well, it's a workaround for xklavier/gnome-settings-daemon not really doing their job...)
[19:58] <bdmurray> cjwatson: so we can stop attaching it to bug reports as UbiquityDebug if ubiquity wasn't run in debug mode
[19:59] <cjwatson> we should attach it as something
[19:59] <cjwatson> it occasionally contains helpful debug spew even outside debug mode
[19:59] <cjwatson> I don't quite understand why it needs to change though :)
[20:00] <bdmurray> Well I for one didn't understand why there were all these debug attachments and some were more informative than others
[20:00] <cjwatson> ok, but changing it will complicate greps in future ...
[20:00] <bdmurray> yeah
[20:03] <stgraber> cjwatson: do you have a minute to see if that one more change to the indicator code looks sane? ^
[20:05] <bdmurray> where should I be looking for bug 959486
[20:05] <ubot2`> Launchpad bug 959486 in ubiquity "install alongside doesn't show which partition is which" [Medium,Triaged] https://launchpad.net/bugs/959486
[20:05] <stgraber> cjwatson: hmm, actually, that shouldn't work ...
[20:08] <cjwatson> stgraber: are you trying to tell whether setxkbmap worked?  you don't check its exit status
[20:08] <cjwatson> hm, maybe not, from the changelog
[20:08] <cjwatson> I don't really feel competent to judge this, but I don't see anything obviously wrong ...
[20:20] <barry> cjwatson: so i can't seem to reproduce bug 792652.  i've tried various scenarios w/ the advanced partitioning, quitting, going back, etc.  i see your comment #9 in the bug, but i don't know how to trigger it.  do you have any other suggestions?
[20:20] <ubot2`> Launchpad bug 792652 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file" [High,In progress] https://launchpad.net/bugs/792652
[20:21] <stgraber> cjwatson: I don't really care about its exit status as if it fails there's nothing I can do anyway :(
[20:24] <cjwatson> 15:02 <bdmurray> so jibel has a testcase in bug 942111 which is also regarding exit_ui_loops
[20:24] <ubot2`> Launchpad bug 942111 in ubiquity "ubiquity crashed in ubi-partman.py : ValueError: I/O operation on closed file" [High,New] https://launchpad.net/bugs/942111
[20:24] <cjwatson> stgraber: *nod*
[20:24] <CIA-32> ubiquity: stgraber * r5274 ubiquity/ (debian/changelog tests/test_misc.py ubiquity/misc.py): Some more changes to set_indicator_keymaps(), directly calling setxkmap to ensure the keyboard layout change always happen. Also call lock_group from Xkl to reset the layout group back to 0.
[20:24] <cjwatson> comment #5 in that bug
[20:24] <cjwatson> "I can reproduce it reliabliy on bare-metal with Wifi, if I quit while wifi is setting up"
[20:26] <ogra_> hrm, so even hardcoding the oem-config execution with the --automatic option doesnt get me an automated install
[20:28] <infinity> http://pad.ubuntu.com/ubuntu-installer-sprint
[20:29] <cjwatson> gah
[20:29] <cjwatson> double gah
[20:30] <cjwatson> maybe we could just link that workflow url from /Development
[20:31] <ogra_> GRRR !
[20:32]  * ogra_ doesnt see any code that would actually supress automatic execution, why the heck is it not using the --automatic if i even enforcer it in oem-config-wrapper
[20:33] <CIA-32> ubiquity: Evan Dandrea <evan.dandrea@canonical.com> * revan.dandrea@canonical.com-20120319203346-xnh3qdowojgcaarf ubiquity/src/webcam/ (demo.py webcam.c):
[20:33] <CIA-32> ubiquity: Add a small program for testing the Gstreamer webcam code.
[20:33] <CIA-32> ubiquity: Fix broken test video output in the GI webcam module.
[20:34] <cjwatson> cia_send_revno = True
[20:34] <ev> indeed, oops
[20:34] <cjwatson> silly default
[20:34] <stgraber> ev: changelog entry?
[20:35] <ev> stgraber: cheers, adding
[20:36] <slangasek> bdmurray: 959486> the 'Install Ubuntu alongside' option comes from gui/gtk/stepPartAsk.ui; the code to use it is in ./ubiquity/plugins/ubi-partman.py, initialize_resize_mode (I think)
[20:37] <cjwatson> that's probably the single twistiest bit of ubiquity ...
[20:37] <bdmurray> slangasek: thanks I made i that far
[20:37] <slangasek> ok
[20:37] <CIA-32> ubiquity: Evan Dandrea <evan.dandrea@canonical.com> * r5276 ubiquity/debian/changelog: Changelog entry for previous commit.
[20:38] <bdmurray> slangasek: how did you get to initialize_resize_mode so quick?
[20:39]  * ogra_ gets dinner
[20:40] <slangasek> bdmurray: grabbed the widget name from the .ui file (resize_use_free_*), walked through ubiquity/plugins/ubi-partman.py looking for 'resize_use_free', ignored the ones that were just setting titles etc, got to line 451 where it handles the case where this checkbox is enabled ('get_active()')
[20:40] <cjwatson> jodh: any luck reproducing that crash on copying /var?
[20:42]  * cjwatson wishes this test were a little quicker than "install ubuntustudio"
[20:42] <slangasek> heh
[20:44] <jodh> cjwatson: no - I thought it might be something odd like target having a broken sym link whereas source expected a directory, but so far unable to make it crash as shown on the bug.
[20:44] <jodh> I've forced the installer to stop just after mounting the target and futzed with /target but it seems remarkably resilient to futzing!
[20:45] <cjwatson> jodh: did you try my suggestion of /var being a mountpoint?
[20:46] <cjwatson> I think that's a likely possibility
[20:46] <jodh> will try that now.
[20:47] <bdmurray> so regarding bug 959486 I've discovered that pressing alt redraws the screen ad I can see the labels now
[20:47] <ubot2`> Launchpad bug 959486 in ubiquity "install alongside doesn't show which partition is which" [Medium,Triaged] https://launchpad.net/bugs/959486
[20:47] <bdmurray> s/ad/and/
[20:47] <cjwatson> hm, that said, a mountpoint ought to return true for os.path.isdir
[20:49] <cjwatson> I can see how a symlink might cause trouble
[20:49] <cjwatson> remove_target only helps there when the symlink target has already been copied
[20:50] <cjwatson> perhaps if copy_all finds a broken symlink where it wants to put a directory, it should simply create the symlink target as a directory; but it's a bit perplexing that /var would exist as a symlink at all at that point
[20:51] <cjwatson> I can't see how there'd be any race involved, since ubiquity shouldn't let anything else futz with /target until copy_all is finished
[20:53] <jodh> agreed. I thought maybe a subdir of /var might be a broken symlink but nope.
[20:53] <jodh> we don't appear to detect broken symlinks as we're using lstat atm.
[20:53] <bdmurray> heh I just got an exit_ui_loops crash
[20:55] <jodh> anyone else seen this error in syslog? http://paste.ubuntu.com/891281/
[20:55] <bdmurray> is bug 959846 likely to be a desktop issue?
[20:56] <bdmurray> er 959486
[20:58] <bdmurray> might it be worth testing on hardware?
[20:58] <slangasek> bdmurray: I think it's probably a bug in ubiquity's use of gtk
[20:58]  * infinity upsets nusakan by running hash verifications across, well, everything.
[20:59] <slangasek> bdmurray: sounds like something is filling in the labels without forcing a redraw of the window, so it's only visible if you do something else that triggers a window redraw
[20:59] <bdmurray> okay, I'll look more
[20:59] <infinity> cjwatson: I honestly can't make your checksum-directory code (as it currently is) fail in any sort of weird testing I put it through.  So, either it's correct, or I'm not yet reproducing the exact issue.
[21:00] <infinity> cjwatson: The only thing I can think is that it used to be broken, and through the magic of passing OLD_DIRS to checksum-directory, we've been carrying forward bad sums for weeks, so I'm re-summing everything that appears broken.
[21:01] <cjwatson> that's possible, although it should have re-summed anything with a newer timestamp than the checksums file itself
[21:01] <infinity> cjwatson: Yeah, there's that.  And, like I said, that code appears correct, both visually, and when I test it to do what I think it should do.
[21:02] <infinity> cjwatson: Frankly, I'm puzzled.
[21:02] <barry> i thought i'd look at bug 957829 which is unassigned atm
[21:02] <ubot2`> Launchpad bug 957829 in ubiquity "install.py crashed with ValueError in command(): invalid literal for int() with base 10: ''" [Undecided,New] https://launchpad.net/bugs/957829
[21:02] <infinity> cjwatson: I have half a mind to just kill the optimisation and rm -f *SUMS* at the top of the script. :P
[21:03] <infinity> cjwatson: It's not like summing is a particularly lengthy part of the whole process.
[21:03] <slangasek> actually, it rather is
[21:03] <cjwatson> it used to be really f'ing slow on antimony
[21:03] <slangasek> oh
[21:03] <cjwatson> I don't know how well nusakan does at it
[21:03] <infinity> Used to be.
[21:03] <infinity> Isn't really that bad now.
[21:03] <slangasek> ok
[21:03] <infinity> I mean, it's not instant.
[21:03] <infinity> But.
[21:03] <cjwatson> I think it matters to try to avoid re-summing during publish-release
[21:03] <cjwatson> that's often run in a rush
[21:03]  * infinity nods.
[21:04] <cjwatson> I'm not quite so bothered about publish-daily, if it's reasonably fast now
[21:04] <infinity> Well, I'll keep seeing if I can think up clever ways to reproduce the fail.
[21:04] <infinity> But first, getting everything to a known-good state is a nice idea.
[21:04] <cjwatson> although people keep hammering on daily build perf so I'm kind of not massively wild about deliberately adding to it
[21:04] <bdmurray> barry: that error can happen for a lot of different reasons
[21:04] <bdmurray> barry: sometimes it is hardware related
[21:05] <barry> bdmurray: are the dups of that bug you can point to?
[21:05] <infinity> cjwatson: Oh, the optimisation is a good thing.  Though, for daily builds that don't have any failures, the optimisation is a no-op anyway.
[21:05] <cjwatson> barry: the literal cause of that ValueError is that we got some junk (possibly EOF) back from the other end of a debconf protocol connection rather than a command return code
[21:05] <infinity> cjwatson: (Except in the weird split-run case of ARM)
[21:05] <cjwatson> infinity: true
[21:06] <cjwatson> so not that big a deal then
[21:06] <barry> cjwatson: yeah, it's a bare int() coercion that's failing
[21:06] <cjwatson> nusakan is so not the limiting factor on arm builds
[21:06] <cjwatson> barry: right - but it's a programming error *somewhere* if that coercion ever fails
[21:07] <barry> cjwatson: seems a little suspect that debconf wouldn't be validating its input
[21:07] <cjwatson> the debconf protocol is not a security boundary
[21:07] <ogra_> cjwatson, ev, so is there any reason why oem-config --automatic would still prompt me even though all the debconf bits are already preseeded ? i cant seem to find a valid reason in the code
[21:07] <cjwatson> that error is either "backend fell over" or "protocol got out of sync", either of which is fatal in itself anyway
[21:07] <ogra_> (probably i'm doing something really wrong here and just dont recognize it)
[21:08] <barry> cjwatson: it's too bad we don't capture the state of debconf in those cases
[21:08] <cjwatson> you can go back and get it with --debug, but yeah
[21:08] <barry> cjwatson: right, if you can reproduce it ;)
[21:08] <cjwatson> unfortunately debconf protocol debugging is like strace and is content-agnostic, which means that it can include confidential information
[21:08] <cjwatson> so I don't want to turn it on by default
[21:09] <barry> ah
[21:09] <cjwatson> plus it can be fairly slow
[21:09] <cjwatson> ogra_: sorry, not sure, do you have a debug trace?
[21:09] <ogra_> nope, i was just hacking up the startup scripts and try over and over, will do a debug run next
[21:10] <ogra_> (and reading ubiquity code)
[21:10] <barry> cjwatson: in that case, i'll see if this can be reproduced.  i suppose that if bdmurray comes up with similar crashes, they may or may not be related at all (other than a symptom of the general problem for which there probably is no overall fix)
[21:11] <infinity> ogra_: If this is a sprint, why aren't we outside smoking?
[21:11] <cjwatson> that's certainly an example of an exception that needs more context for any kind of autoduplication
[21:11] <ogra_> infinity, no idea, but we can meet at the bar later for a smoke ... oh wait ...
[21:11] <cjwatson> it's like autodupping all your SIGSEGVs :)
[21:12]  * infinity is beginning to think that validating the sums of www/full/* might have been a mistake.
[21:12] <barry> cjwatson: at the very least, i can try the usb install mentioned in the bug report
[21:13] <cjwatson> barry: I'd suggest finding an example of that traceback that isn't hideously incomplete :)
[21:13] <cjwatson> barry: it's a lot easier when you have, e.g., the syslog
[21:13] <barry> cjwatson: okie dokie :)
[21:14] <cjwatson> though, wow, that's a fairly basic place for that install to fail
[21:14] <cjwatson> it's not unusual in such cases for the syslog to have junk like SIGILL from python that indicates the media's just hosed
[21:15] <cjwatson> (the crash tracker should be great for us - a lot of installer bugs really are just utter junk, that's why I didn't want this sprint to be purely about reducing bug count)
[21:16] <barry> cjwatson: ack.  of course, if you can suggest a more interesting bug to look at, i'm happy to bail on this one. :)
[21:17] <cjwatson> might be worth starting with at least triaged ones (not that that's an exclusive list)
[21:17] <cjwatson> or any from the links in the wiki, or the ones in etherpad (though those two are a little tricky, I think)
[21:18] <cjwatson> ubiquity/New is a swamp so not the best source of things that are actually fixable until you're a bit more used to finding thm
[21:18] <cjwatson> *them
[21:19] <CIA-32> ubiquity: cjwatson * r5277 trunk/tests/ (test_timezone.py test_usersetup.py): Barry says Emacs likes "coding: utf-8" better than "coding: utf8"
[21:20] <barry> cjwatson: bug 933433 is a triaged bug of similar failage
[21:20] <ubot2`> Launchpad bug 933433 in ubiquity "Kubuntu manual install crashed during bootloader configuration on an XFS partition" [Medium,Triaged] https://launchpad.net/bugs/933433
[21:21] <jodh> having a look at bug 946663 and came across this which looks wrong:
[21:21] <ubot2`> Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663
[21:21] <jodh> # /home could be a symlink.
[21:21] <jodh> [ -f "$tmp/home" ] && (rm "$tmp/home" || failed)
[21:21] <jodh>  
[21:21] <cjwatson> barry: OK, so two problems there, IMO
[21:22] <cjwatson> barry: firstly, the user was allowed to select an XFS partition as a target for boot loader installation (impossible since XFS doesn't reserve space)
[21:22] <jodh> however, I can't see file d-i/source/partman-target/finish.d/clear_partitions in lp:partman-target.
[21:22] <cjwatson> jodh: lp:~ubuntu-core-dev/partman-target/ubuntu
[21:22] <jodh> cjwatson: thx!
[21:23] <cjwatson> barry: secondly, when they tried and grub-installer fell over, that apparently triggered a knock-on failure
[21:23] <cjwatson> barry: I think it's worth attempting to fix both of those independently, even though fixing either would technically fix the bug
[21:23] <barry> cjwatson: agreed.  i'll split them into separate bugs
[21:25] <cjwatson> barry: those are probably both tractable as sprint material, although I would estimate at a day's work for somebody unfamiliar with the codebase - but it'd be an interesting slice of work
[21:25] <cjwatson> and definitely worthwhile IMO since that might easily account for a lot of post-release bugs
[21:25] <barry> cjwatson: do you think bug 855871 is related?
[21:25] <ubot2`> Launchpad bug 855871 in ubiquity "Grub install fails after manual xfs partitioning" [Medium,Confirmed] https://launchpad.net/bugs/855871
[21:26] <barry> cjwatson: cool, i'm up for them
[21:26] <cjwatson> barry: no, that's EFI insanity
[21:27] <cjwatson> plan for that one is to add a check script to partman-efi to enforce the presence of either an EFI System Partition or a BIOS Boot Partition on EFI - I think
[21:27] <cjwatson> if you look closely at the log there, grub-install is being told to install to /dev/sda rather than /dev/sda5 (etc.), so it's a different class of bug
[21:27] <barry> cjwatson: so we need a new bug along the lines of "should not be allowed to select xfs partition as target for boot loader installation"
[21:27] <cjwatson> correct
[21:27]  * barry nods
[21:28] <cjwatson> actually should not be allowed to select anything that doesn't reserve embedding space
[21:28] <cjwatson> that can be data-mined from the grub2 source
[21:28] <jodh> Look reasonable? http://paste.ubuntu.com/891343/
[21:28] <barry> cjwatson: okay, let me file a bug and i'll let you sanity check it
[21:28] <cjwatson> 'grep reserved_first_sector grub-core/fs/*'
[21:29] <cjwatson> if there's a filesystem in the target partition, it must be one of those with = 1 there
[21:30] <cjwatson> jodh: does that close any particular bug?
[21:31] <GrueMaster> ogra_: I think I found why oem-config ignores --automatic.  Check bin/ubiquity from the bzr tree.
[21:32] <barry> cjwatson: bug 959724
[21:32] <ubot2`> Launchpad bug 959724 in ubiquity "Limit boot loader installation target" [Undecided,New] https://launchpad.net/bugs/959724
[21:32] <jodh> Possibly not - just noticed it as a problem.
[21:32] <cjwatson> barry: *nod*
[21:33] <barry> thx
[21:33] <cjwatson> jodh: I wondered if it fixed bug 946663, which you menetioned
[21:33] <ubot2`> Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663
[21:33] <cjwatson> -e
[21:33] <cjwatson> jodh: looks right to me, but would be nice if ev could double-check it since he wrote that code
[21:33] <cjwatson> if that's a bug it goes back to the first version of that file
[21:33] <cjwatson> (r801)
[21:34] <cjwatson> ev: ^-
[21:34] <infinity> cjwatson: Oh, may be barking up a wrong tree here.  Looks like scratch/blah/armhf+subarch/MD5SUMS doesn't actually match reality, there's the problem, since we pass the scratch dir as the previous dir.
[21:34] <infinity> cjwatson: Now to sort out why THAT is...
[21:34] <cjwatson> infinity: yeah, this sounds familiar from my half-arsed investigations
[21:35] <jodh> it might contribute to it, but if /home is not a symlink, the code should call failed which exits(1), so I'd be surprised if that made the installer hang. Having said that, I checked the behaviour...
[21:35] <cjwatson> the debian-cd code for this was complex
[21:35] <infinity> cjwatson: Well, the part where it seems to only affect preinstalled is a start anyway.  Clearly, we're doing something wrong there.
[21:35]  * infinity dives deeper.
[21:35] <cjwatson> jodh: ... unless it wasn't a symlink and rm succeeded (which it normally would)
[21:36] <cjwatson> jodh: more likely, though, wouldn't this mean that a symlink in /home wouldn't be removed where it ought to be removed?
[21:36] <cjwatson> I mean, the existing coe
[21:36] <cjwatson> *code
[21:37] <ev> on it
[21:38] <jodh> cjwatson: yes I think so.
[21:41] <barry> slangasek: http://pastebin.ubuntu.com/891364/
[21:42] <ogra_> GrueMaster, yes, thats what i spent the last hours staring at
[21:43] <slangasek> barry: doesn't update the datestamp if the file already exists
[21:43] <slangasek> which is one of the use cases here :)
[21:43] <ogra_> GrueMaster, and there is no reason why it shouldnt work
[21:45] <infinity> slangasek: os.utime
[21:45] <infinity> slangasek: os.utime(path, times), times is a tuple of (atime, mtime)
[21:45] <slangasek> infinity: just got there, thanks :)
[21:45] <barry> slangasek: ah
[21:45] <infinity> slangasek: lmgtfy!
[21:46] <slangasek> barry: so I just need to throw an os.utime() in there
[21:48] <cjwatson> os.utime doesn't work on nonexistent files, does it?
[21:48] <barry> slangasek: too bad the nanosecond resolution pep got turned down. :)
[21:48] <GrueMaster> ogra_: bin/ubiquity:439 is why the option doesn't work.  When the script runs, it checks argv(0) to see how it was called and sets oem-config accordingly (see the bottom of the file for the check).
[21:48] <cjwatson> https://code.launchpad.net/~cjwatson/ubuntu/precise/casper/jackd-debconf-hang/+merge/98292 - please review
[21:49] <barry> cjwatson: ENOENT
[21:49] <cjwatson> barry: oh, I thought you wanted to create the file if it didn't exist, based on the O_CREAT there
[21:50] <ogra_> GrueMaster, in my 439 it only disables the migration assistan
[21:50] <ogra_> t
[21:50] <barry> cjwatson: oh, i thought you were saying the utime didn't need the creat()
[21:50] <stgraber> bdmurray: took me surprisingly long to figure this one out: http://paste.ubuntu.com/891379/
[21:50] <cjwatson> no, I meant if you care about that O_CREAT then utime isn't an adequate substitute
[21:50]  * GrueMaster updates bzr
[21:51] <ogra_> GrueMaster, note the indendation ... --automatic isnt in the "if"
[21:51] <ogra_> its just the next parser.option()
[21:51] <GrueMaster> Oh, you are right.
[21:52]  * GrueMaster is still working on this whole pythong...thing.
[21:52] <slangasek> cjwatson: right, so I'll do both open and utime
[21:52] <ogra_> i will call it a day now, tomorrow i'll produce some more debig logs and scatter some prints around in the code
[21:52] <infinity> cjwatson: Derp.  We're md5summing the raw images before we gzip them.  A little rearraging here (or make dependencies, if it's laid out sanely), and we're good.
[21:52] <ogra_> *debug
[21:52] <cjwatson> infinity: ah, good catch
[21:52] <infinity> cjwatson: Which is why it only fails for preinstalled, since everything else is already the "final image" by that point.
[21:52] <cjwatson> aye
[21:52] <slangasek> cjwatson: G+ down again for you?
[21:53] <slangasek> was gonna try to do a brief wrap-up today
[21:53] <cjwatson> I was just rejoining, by chance
[21:53] <cjwatson> it was killing my laptop
[21:53] <slangasek> bdmurray: can you join too?
[21:53] <slangasek> ogra_: and can you stick around for just a couple more mins?
[21:53] <ogra_> sure
[21:56] <infinity> Filthy Atoms.
[21:56] <CIA-32> ubiquity: stgraber * r5278 ubiquity/ (debian/changelog ubiquity/plugins/ubi-console-setup.py): Properly set set_transient_for for KeyboardQuery
[21:57] <infinity> I'd respond via audio, but...
[21:57] <infinity> Yeah, I'd rather hang on mumble.
[21:58] <infinity> If those are my only two options. ;)
[21:58]  * ogra_ would prefer mumble too 
[21:58] <ogra_> since it works on my arm machines ... this x86 crap is really not marture enough
[21:58] <infinity> Does mumble do PTT in the background properly?
[21:59] <ogra_> no idea, i always use the volume threshold option that works quite well there
[21:59] <stgraber> infinity: I usually have it bound to alt-gr with mumble minimized and it works fine here
[22:00] <infinity> Yeah, I could bind it to something useless like menu.
[22:00] <infinity> I used to pretty much live on Ventrilo back when I had an online gaming addiction, so mumble in the background with PTT would be a faimiliar sort of thing.
[22:03] <infinity> cjwatson: I assume there's no point at which one would every run casper-reconfigure interactively?
[22:03] <cjwatson> it sets -fnoninteractive anyway
[22:03] <infinity> cjwatson: If so, the patch looks obviously correct to me.
[22:03] <CIA-32> ubiquity: stgraber * r5279 ubiquity/debian/changelog: releasing version 2.9.30
[22:03] <cjwatson> but not afaik - it's used in casper-bottom hooks and in ubiquity target-config hooks
[22:03] <infinity> Yeah, I see that on the next line.  I mean casper-reconfigure itself would never care later?
[22:03] <cjwatson> though it is in /usr/bin in the live session so who knows, but I think the -fnoninteractive bit governs
[22:03] <cjwatson> it exits 0 right after that
[22:03] <infinity> Oh.
[22:03] <infinity> Then yeah.
[22:04] <infinity> It's great. :P
[22:04] <cjwatson> coolio
[22:04] <infinity> Seems like a debconf bug to me that -fnoninteractive doesn't trump all, but whatever.
[22:04] <cjwatson> (and I have tested - the first three attempts failed so just as well :-P )
[22:04] <cjwatson> the interaction is messy to say the least, yes
[22:04] <cjwatson> but not keen on fixing it at that layer without a complete analysis of all installer code :)
[22:05] <infinity> ;)
[22:05] <infinity> Or all debconf-using code everywhere. :P
[22:05] <infinity> Messy begets messy.
[22:05] <infinity> Anyhow, I clicked the magic approve button, for all that doesn't matter.
[22:05] <cjwatson> all the hairy bits are in the installer :)
[22:05] <cjwatson> ta - pulled into trunk
[22:05] <cjwatson> it gets you karma :P
[22:06] <infinity> *rolls eyes*
[22:06] <infinity> If I want karma, I can do a library transition.
[22:06] <infinity> Like a real man.
[22:06] <slangasek> heh
[22:09] <jodh> fyi - raised kernel bug 959620.
[22:09] <ubot2`> Launchpad bug 959620 in linux "ext4 backtrace observed with desktop install CD" [Medium,Confirmed] https://launchpad.net/bugs/959620
[22:09] <infinity> So, now that I have a handle on the *sums business, I'll fix that later tonight.  But first, I need to convince my body that I don't actually hate it, and waking up at 6:30 was perfectly reasonable.
[22:09] <jodh> ttfn.
[22:10] <cjwatson> jodh: score, those are always fun
[22:17] <infinity> cjwatson: Hrm.  While I'm on the checksum warpath, can you think of any valid reason why www/full/releases/lucid/release/*SUMS have sums for both 10.04.3 and 10.04.4, despite the former not actually being there?
[22:17] <infinity> cjwatson: Or is that another oops?
[22:17] <cjwatson> that'd be an oops
[22:17] <cjwatson> guess .3 got old-releases-ified without cleaning up
[22:17] <cjwatson> (not surprising given that old-releases-ifying isn't actually scripted)
[22:18] <cjwatson> 'checksum-directory .' should clean that up, shouldn't it?
[22:18] <infinity> cjwatson: It does indeed, yes.
[22:18] <infinity> cjwatson: Was more wondering how or why that came about, cause it would almost seem to have to be intentional (or, I guess, just publishing and old-releasing in the wrong order)
[22:19] <infinity> cjwatson: Anyhow, all better.
[22:20] <cjwatson> most likely the latter
[22:22] <infinity> cjwatson: And now that I realise that debian-cd does checksumming, the dir/old_dir optimisation makes a lot more sense.  Was easier, I guess, to just reuse debian-cd's sums than to comment out that block? :P
[22:22] <cjwatson> well, s/easier/faster/
[22:22] <cjwatson> it *did* use to make a pretty noticeable difference :)
[22:23] <infinity> cjwatson: No, no.  I mean, one could have just commented out the summing bit from debian-cd/Makefile and let cdimage do the heavy lifting instead.
[22:23] <infinity> cjwatson: But yes, doing it twice would be awful.
[22:23] <cjwatson> oh, right, true
[22:23] <cjwatson> don't really remember why, I suppose it was minimal change
[22:24] <cjwatson> I did that in 2005; memory has faded somewhat ;)
[22:24] <infinity> Minimal change, yes.  I look forward to playing hot potato on the task of trying to "merge" (for some off value of that word) our changes into debian-cd 2.0, should we ever feel that's a good idea.
[22:24] <infinity> s/off/odd/
[22:25] <cjwatson> if I can ever manage to get the bzr history rebased, yes ...
[22:25] <stgraber> I think I added everything we fixed and uploaded today to the pad (ubiquity, casper and grub2), if I forgot something feel free to add to the list
[22:25] <cjwatson> vcs transitions ftl
[22:25] <infinity> Or 3.0, rather.
[22:25] <cjwatson> stgraber: right, I thought I already had :)
[22:25] <cjwatson> but I suppose it's good to have those explicitly tied to uploas
[22:26] <cjwatson> *uploads
[22:26] <infinity> cjwatson: Well, 3.0 is a rewrite, isn't it?  Not sure how much rebasing will really matter.
[22:26] <stgraber> cjwatson: I added a line for each package that got uploaded with their full bug list. There was an extra two bugs closed in your grub2 upload that weren't on the list IIRC
[22:26] <infinity> cjwatson: It's more a question of "figure out our delta from wherever we last forked, and try to represent those changes in the 3.0 codebase".
[22:26] <cjwatson> infinity: I thought it was fairly gradual, although certainly the Makefile was chucked
[22:26] <infinity> cjwatson: Which sounds just awful enough to never get done. ;)
[22:27] <cjwatson> stgraber: there was one bug that wasn't really installer-relevant so I didn't mention it
[22:27] <cjwatson> I mentioned the two that bit wubi
[22:27] <infinity> cjwatson: Sledge keeps referring to it as a rewrite.  Maybe he's overselling it.
[22:27] <infinity> cjwatson: I'll admit that I haven't had the testicular fortitude to look at the merge yet.
[22:28] <cjwatson> infinity: it still has tools/boot/*/boot-* scripts which look not entirely dissimilar
[22:28] <infinity> Well, that's something.
[22:28] <cjwatson> albeit with some improvements
[22:28] <infinity> We certainly have a lot of hackery in there.
[22:29] <cjwatson> I figured that if I ever managed to get the rebase-foreign working then I'd try walking up the merge a few revisions at a time
[22:29] <cjwatson> but, yeah, not top of my list )
[22:29] <cjwatson> :)
[22:29] <cjwatson> nor, apparently, is typing
[22:29] <infinity> Typing's overrated.
[22:31]  * cjwatson -> !work