=== tsimpson_ is now known as tsimpson
[14:56]  * stgraber agrees with the comment in ubiquity/keyboard_names.py...
[14:57] <stgraber> or rather d-i/make-keyboard-names :)
[14:59] <cjwatson> heh, yeah
[14:59] <cjwatson> not particularly great for memory use
[15:00] <cjwatson> maybe at some point it should be written to some kind of more easily parseable form and then we can just read the bits we need
[15:00] <stgraber> I'm trying to figure out how "German - German (qwerty)" exists in the .pl and not in the .py and why generating the .py on my machine makes the file about 35k lines shorter than it's on the CD (though mine contains German - German (qwerty)) :)
[15:01] <stgraber> I initially thought that bug 953328 was specific to the KDE frontend but it's definitely not, it's just that the GTK frontend doesn't crash
[15:01] <ubot2`> Launchpad bug 953328 in ubiquity "Kubuntu 12.04 Beta 1: ubiquity crash at keyboard selection" [Undecided,Triaged] https://launchpad.net/bugs/953328
[15:03] <stgraber> ok, with a clean environment I now get the same .py as the buildd but it misses the qwerty variant for German ...
[15:11] <CIA-32> os-prober: cjwatson * r334 ubuntu/ (11 files in 6 dirs): merge from Debian 1.50
[15:12] <stgraber> and calling d-i/make-keyboard-names by hand afterwards gives me a different output which contains the german qwerty keyboard... /me diggs some more to figure out the difference
[15:13] <CIA-32> os-prober: cjwatson * r335 ubuntu/ (2 files in 2 dirs): btrfs will no longer show up as fuse, thanks to the grub-mount improvements in 1.50
[15:17] <CIA-32> os-prober: cjwatson * r336 ubuntu/debian/changelog: releasing version 1.50ubuntu1
[15:22] <stgraber> wondering if the problem is that the list we show comes from debconf and so uses d-i/source/console-setup/Keyboard/KeyboardNames.pl but the list we ship as .py is d-i/source/console-setup/Keyboard/MyKeyboardNames.pl
[15:23] <stgraber> if so, we probably should have the UI filtered to only show things that are in the .py
[15:23] <stgraber> because currently we're showing keyboard layouts/variants that X won't support so even without the crash it just wouldn't work ...
[15:24] <stgraber> cjwatson: does that make sense? ^ (before I start hacking the code to filter what we show)
[15:24] <cjwatson> I think so, but if they're out of sync then it sounds like console-setup needs to be updated too
[15:24] <cjwatson> I mean, it should also only be asking things that X will support
[15:25] <cjwatson> fixing it in ubiquity might be at the wrong level
[15:25] <cjwatson> though I don't object to defence in depth as such
[15:25] <cjwatson> but a fix in console-setup would fix the "just wouldn't work" part for the alternate installer too
[15:25] <stgraber> well, the we probably should probably stop generating d-i/source/console-setup/Keyboard/MyKeyboardNames.pl from ubiquity and instead do no change-uploads of console-setup + ubiquity rebuild
[15:26] <stgraber> *then
[15:27] <cjwatson> I thought console-setup also generated MyKeyboardNames during its own build
[15:27] <cjwatson> maybe it hasn't just been updated for a while?
[15:28] <stgraber> 16 weeks ago according to LP
[15:29] <stgraber> I'll try a rebuild, see if that solves the problem in my VM
[15:31] <cjwatson> it's a little awkward that ubiquity both uses console-setup as part of its own build and also depends on it
[15:32] <ev> cjwatson: regarding https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/645818 do you recall why we didn't just upload an old syslinux as syslinux-$verson and have usb-creator use that in the case of 10.04?
[15:32] <ubot2`> Launchpad bug 645818 in usb-creator "Unknown keyword in configuration file: gfxboot" [Critical,Confirmed]
[15:32] <cjwatson> wasn't that one of the options I suggested? :-)
[15:32] <ev> I remember us having a conversation about it, but I can't for the life of me remember what the decision was. If we were blocked on release freeze or what.
[15:37] <cjwatson> it's possible we talked about shipping a copy of syslinux in the usb-creator source itself, or something
[15:37] <cjwatson> but either option is basically equivalently gross as far as I'm concerned :)
[15:38] <cjwatson> I can't remember what we were blocked on last time, if anything; might just have been time ...
[16:09] <ev> heh, okay
[16:09] <ev> I've added it to my todo list. I'll endeavor to get to it tomorrow
[16:15] <stgraber> ev: did you have a chance to rebuild wubi?
[16:15] <ev> stgraber: apols, it fell out of my brain
[16:15] <ev> doing it now
[16:17] <CIA-32> ubiquity: stgraber * r5259 ubiquity/ (debian/changelog ubiquity/plugins/ubi-partman.py): Rework previous change to simply ignore None values in callback
[16:18] <stgraber> ok, so we should have a working manual partitioner now...
[16:21] <stgraber> cjwatson: the console-setup rebuild did the trick here, uploading it now
[16:21] <cjwatson> cool, thanks
[16:22] <CIA-32> console-setup: stgraber * r430 ubuntu/debian/changelog: releasing version 1.70ubuntu3
[16:38] <stgraber> bdmurray: is there an easy way to tell LP that I want all the bugs with "ubiquity crashed with" in there title? the search seems to be pretty useless at that
[16:39] <stgraber> google is better at it but can't give me a list of open bugs :)
[16:41] <bdmurray> stgraber: I might have something like that which uses the api
[16:43] <stgraber> bdmurray: that'd be nice because these are the kind of bugs that are usually trivial to look at and fix (as they contain a clear reference to the code)
[16:44] <bdmurray> well then wouldn't tagging them something better as one could then use the launchpad search?
[16:44] <cjwatson> you could search for the apport-crash tag or whatever it is
[16:45] <bdmurray> well not all crashes got tagged apport-crash as ubuntu-bug was being called for a while
[16:47] <ev> clearing a ton of old bugs off my assigned list
[16:48] <ev> no sense blocking other people from working on things I'm not currently looking at
[16:48] <ev> installer bugs, that is
[16:48] <stgraber> yeah, I had a quick look at the current tags applied to these bugs and didn't find one that matches them all
[16:48] <stgraber> apport-crash would work if it was used for all of them (and as bdmurray said, it's not :( )
[16:49] <bdmurray> but we could go through and add the tags where appropriate and have the bug bot do this as it reviews new ones
[16:51] <ev> stgraber: wubi-r263.exe up
[16:52] <stgraber> ev: thanks
[16:52] <ev> sure thing
[16:52] <stgraber> bdmurray: having the bug bot spot python tracebacks and tag the bug would be nice indeed
[16:53] <stgraber> bdmurray: that'd probably make a list of easy bugs for next week too I guess
[16:54] <bdmurray> stgraber: I was also thinking it could tag them with the location of the traceback if possible e.g. ubi-webcam
[16:55] <stgraber> bdmurray: yep, that'd be nice indeed
[17:00] <jibel> stgraber, no segfault with build 20120315. looks like it's fixed.
[17:01] <jibel> stgraber, but I got bug 955844 today.
[17:01] <ubot2`> Launchpad bug 955844 in casper "French selected in Ubiquity greeter but US keyboard layout in the live session" [Undecided,New] https://launchpad.net/bugs/955844
[17:07] <stgraber> jibel: is that also happening without the persistence?
[17:07] <stgraber> I "think" I fixed the issue with the persistence when the layout is selected in gfxboot
[17:08] <stgraber> but I didn't look at what the greeter exactly does, I'm guess changing the language should trigger the keyboard indicator and change the layout there, but I'm not too familiar with that part yet
[17:08] <jibel> stgraber, no, but  let me try again without persistence
[17:15] <stgraber> jibel: I'm kind of hoping you'll get the same bug without persistence, otherwise I'm really not sure what's going on ;)
[17:19] <jibel> stgraber, ok, same problem without persistence
[17:19] <stgraber> good :)
[17:20] <stgraber> there isn't really any keyboard logic in that ubiquity step
[17:21] <stgraber> so if something happened magically in the past, it must have been done automatically by gnome or the indicator (or I just didn't see the keyboard part of the ubi-language)
[17:33] <stgraber> jibel: I'll take a look this afternoon, I'm not sure how much we really should do here as we have the usual problem that there isn't a good language => keyboard mapping
[17:33]  * stgraber definitely prefers getting a us keyboard when selecting french than the azerty layout ;)
[17:34] <stgraber> but at the same time, I install in english anyway...
[17:35] <jibel> stgraber, ok, just wanted to make sure it was not a regression of what you fixed for B1.
[17:42] <stgraber> jibel: shouldn't be. I'll try with 11.04 and see what happens (11.10 had the indicator disabled) and make sure we don't regress at least
[17:43] <jibel> stgraber, don't bother with that, I'll do the verification.
[17:48] <stgraber> jibel: it indeed regressed from 11.04 to 12.04...
[17:48] <stgraber> jibel: now I'm wondering if it's not turning the indicator on that broke it somehow...
[18:41] <bdmurray> stgraber: installer-crash might be a good tag to search for
[18:41] <CIA-32> debian-installer: cjwatson * r1649 ubuntu/ (3 files in 3 dirs):
[18:41] <CIA-32> debian-installer: Add a new cdrom/isolinux/non-pae build for i386 that uses the -generic
[18:41] <CIA-32> debian-installer: kernel flavour (LP: #955009).
[18:44] <CIA-32> debian-installer: cjwatson * r1650 ubuntu/debian/changelog: releasing version 20101020ubuntu119
[19:16] <stgraber> jibel: ok, I "think" I've tracked down your keymap bug, it's indeed the indicator that seems a bit broken
[19:17] <stgraber> jibel: when a language is selected "misc.set_indicator_keymaps(lang)" is called to have the indicator updated with a few keymaps relevant to the locale (not all because there are X limitations...) but AFAICT that's not happening
[19:17] <stgraber> will go check if our code is the problem or if I can blame desktop for this one ;)
[19:36] <stgraber> jibel: right, it's my fault, I "broke" it when fixing the indicator, it's to do with gsettings syntax, fixing now
[19:41] <stgraber> hmm, well, it works now, just not for french and a few others languages... digging deeper
[20:32] <CIA-32> ubiquity: stgraber * r5260 ubiquity/ (debian/changelog ubiquity/misc.py): Fix set_indicator_keymaps to always send an array of strings to gsettings and make sure it always matches the country
[20:32] <stgraber> ok, so that fixes the bug but it's still a bit broken
[20:33] <stgraber> as the indicator will show 50 layouts just fine but only the 4 first ones will work because of the X limitation
[20:33] <stgraber> so only a subset of countries work properly with this
[20:33] <stgraber> I'll now try to rewrite this an be a bit more clever, adding the first layout for each country only (if I can figure out how to have xklavier do that for me)
[21:20] <stgraber> cjwatson, infinity: http://paste.ubuntu.com/885523/
[21:20] <stgraber> that's my attempt at getting a reasonable list of 4 layouts
[21:21] <stgraber> I tried with french, german and english and got reasonable lists (obviously missing a few main ones, but well, we have that limit of 4 to live with)
[21:42] <stgraber> hmm, I guess we should restrict the indicator code to greeter mode only, otherwise we end up overriding the keyboard selection made in gfxboot
[21:52] <CIA-32> ubiquity: stgraber * r5261 ubiquity/ (debian/changelog ubiquity/misc.py): Add code to restrict the indicator keyboard layouts list to 4 entries
[21:56] <CIA-32> ubiquity: stgraber * r5262 ubiquity/ (debian/changelog ubiquity/plugins/ubi-language.py): Restrict keyboard indicator to greeter mode only (to avoid conflicting with the user session or gfxboot)
[22:11] <CIA-32> ubiquity: stgraber * r5263 ubiquity/ (d-i/manifest debian/changelog): Automatic update of included source packages
[22:12] <CIA-32> ubiquity: stgraber * r5264 ubiquity/ (debian/changelog tests/test_misc.py): Update keymap indicator tests
[22:13] <CIA-32> ubiquity: stgraber * r5265 ubiquity/debian/changelog: releasing version 2.9.29