[09:46] argh incomprehensible screen reader bugs [09:46] I set self.screen_reader to True and it reads nothing at all [12:05] debian-installer: cjwatson * r1664 ubuntu/ (6 files in 2 dirs): Move to 3.2.0-22 kernels. [12:07] debian-installer: cjwatson * r1665 ubuntu/ (build/config/armel/armadaxp.cfg debian/changelog): Move armhf/armadaxp to 3.2.0-1601 kernels. [12:09] debian-installer: cjwatson * r1666 ubuntu/debian/changelog: releasing version 20101020ubuntu128 [12:23] Hmm. Boot CD, press a key, add 'maybe-ubiquity' boot parameter, boot, press C-s Alt-Tab when ubiquity starts, screen reader works. Boot CD, press a key, add 'break=bottom maybe-ubiquity' boot parameters, boot, exit initramfs shell immediately, press C-s Alt-Tab when ubiquity starts, screen reader doesn't work. [12:23] BTW [12:23] er, WTF === ogra is now known as Guest67850 [12:38] * cjwatson tries running 'ubiquity --greeter' from the desktop instead === ogra_ is now known as ogry === ogry is now known as ogra_ [13:18] ... alt+backspace no longer working in irssi is getting really annoying ... /me tries to fix [14:09] * cjwatson decides to attack bug 792652 [14:09] Launchpad bug 792652 in ubiquity "ubiquity crashed with ValueError in command(): I/O operation on closed file" [High,Triaged] https://launchpad.net/bugs/792652 [14:10] I have a plan of attack [14:10] basically involving forcibly widening the race [14:29] well, I can't reproduce it either, but I think the fix may be as simple as http://paste.ubuntu.com/914594/ [14:29] seeing as cleanup is actually intended for this kind of thing and exit_ui_loops isn't [14:31] hm, maybe not entirely [14:37] yeah, that patch alone regresses bug 756920, so I need to be a bit more careful [14:37] Launchpad bug 756920 in ubiquity "Natty manual-partitioner is dangerously forgetful" [High,Fix released] https://launchpad.net/bugs/756920 [14:39] of course that's because maybe_update_grub gets grub-installer/bootdev directly and doesn't honour the UI [14:40] I wonder if that had something to do with automatic mode [15:53] ubiquity: cjwatson * r5353 trunk/ (3 files in 3 dirs): [15:53] ubiquity: Fix partman plugin to preseed grub-installer/bootdev in a cleanup method [15:53] ubiquity: rather than exit_ui_loops, since talking to debconf in the latter isn't [15:53] ubiquity: safe (LP: #792652). Adjust how maybe_update_grub gets the default boot [15:53] ubiquity: device to avoid regressing LP #756920. [15:53] Launchpad bug 756920 in ubiquity "Natty manual-partitioner is dangerously forgetful" [High,Fix released] https://launchpad.net/bugs/756920 [15:58] bdmurray, jibel: so who of the two of you has the most upload speed? (bug 772470) [15:58] Launchpad bug 772470 in ubiquity "os-prober doesn't detect Windows partition but the recovery partition instead" [High,Triaged] https://launchpad.net/bugs/772470 [16:01] stgraber, what do you need ? [16:01] oh, hold on a sec, apparently I have a Windows 8 system that actually has a recovery partition (created by the windows installer), so unless windows8 is much different from windows7, I might actually be able to reproduce it [16:01] jibel: disk image ;) [16:03] stgraber, 300GB, I'll use Fedex, that'll be faster. [16:04] jibel: right ;) ... let me try to reproduce that with windows8 first then :) [16:06] stgraber: couldn't you reproduce just by replacing the bcd with the failed one attached to the bug? [16:09] superm1: I might be able to trick ubiquity into believe they are windows partitions, yes. When I first tried to look into this bug, I didn't actually have any Windows machine or VM at all [16:09] ah === lool- is now known as lool [16:10] debian-installer: cjwatson * r1667 ubuntu/ (4 files in 4 dirs): [16:10] debian-installer: nic-firmware grew by nearly 4MB (!). Bump amd64, i386, and powerpc [16:10] debian-installer: netboot image sizes to match. [16:13] debian-installer: cjwatson * r1668 ubuntu/debian/changelog: releasing version 20101020ubuntu129 === infinity1 is now known as infinity [16:33] jibel: right, I think I spotted the part of the code that needs some hacking, I'll do some tests here and will ask you to confirm the fix when I have it [16:33] (as I'm not sure that testing with win8 counts ;)) [16:34] stgraber, sure, let me know if you need to test something. [16:35] stgraber, I've a machine in the lab with 7 if you need to verify something, but that's a fresh install and that bug was on a preinstalled system [16:43] jibel: can you get me the current os-prober output on your machine? I don't remember seeing it in the bug [16:54] stgraber, /dev/sda2:Windows 7 (loader):Windows:chain [16:54] report updated [16:54] jibel: thanks [16:55] jibel: so indeed very similar to what I have here, good. I have a "fix" I'm testing now for the wubi part, will look at m-a after that [17:00] I guess nobody will mind me adding support for Windows 8 in ubiquity ;) [17:00] just noticed "Startup" became "StartUp" in win8, so windows_startup_folder was failing [17:00] not at all ... [17:16] cjwatson: oh, looks like I'll need to update os-prober too so it detects windows8 in the bcd [17:28] cjwatson: http://paste.ubuntu.com/914834/ <- that's only for the wubi part of the bug [17:30] and I can confirm that I get wubi when Windows starts [17:33] cjwatson: oh, and is lp:~ubuntu-core-dev/os-prober/ubuntu/ abandonned? I'm going to push my change to the UDD branch this time [17:49] doh, migration-assistant is calling os-prober pretty much everywhere so will need substential hacking for it to do its own checks [17:57] hmm, trying to do that will end up badly I'm sure... that's quite a few use cases to take care of and I don't feel like re-implementing os-prober [18:00] going with an ugly but working and easy to review/understand change instead, having ubiquity add a "fake" entry to the os-prober cache just before calling m-a, the dropping it on exit. Should make for a minimal change [18:08] actually, looks like adding a --data option to os-prober and changing m-a to use it might be doable (m-a does the right checks) [18:36] ubiquity: stgraber * r5354 ubiquity/ (debian/changelog ubiquity/misc.py): Add windows 8 support [18:40] ubiquity: stgraber * r5355 ubiquity/ (debian/changelog ubiquity/plugins/ubi-partman.py): Make wubi work when Windows isn't installed on the boot partition [19:11] jibel: right, I have a bunch of fixes making ubiquity work in your setup [19:11] but I'll want cjwatson to review to check I didn't miss a much easier way of dealing with the problem [19:19] cjwatson: I posted a comment in bug 772470 with the debdiffs for ubiquity, os-prober and migration-assistant [19:19] Launchpad bug 772470 in ubiquity "os-prober doesn't detect Windows partition but the recovery partition instead" [High,Triaged] https://launchpad.net/bugs/772470 [19:19] my install is still running here but I got the migration-assistant prompt and selected everything available, I should have post-install results in a few minutes [21:10] cjwatson, ev: Hello! I was looking at bug 960096, which has morphed into looking into why some gsettings aren't getting set like we expect on the LiveCD. Do you have any insights or suggestions for places to look? [21:10] Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096 [21:23] mterry: gsettings => that's usually my "fault" ;) [21:24] stgraber, yeah? [21:24] mterry: suppress-logout-menuitem is a key we set in ubiquity but unset on exit, let me check [21:24] mterry: I'm wondering if it could be a case of dconf not flushing things to disk and us killing it when entering the live session? [21:25] mterry: the keyboard layouts listed in that pastebin are the defaults one for the default language (English), so it looks like clicking Italian didn't properly save the new ones in gsettings [21:25] yar [21:26] Looks like just a series of things not saved to gsettings. So your flush idea is good [21:26] mterry: ok, I confirmed that we indeed restore suppress-logout-menuitem on exit (in our code), so definitely looks like gsettings not saving things properly [21:27] stgraber, if I recall there isn't a way to force a flush with dconf? [21:27] mterry: ubiquity directly calls "gsettings set ...", do you know if there's any reason for that not being flushed to disk instantly and if so, how do we force the flush? [21:28] I would think that would do it... [21:28] Unless that just talks to the daemon and it caches things [21:29] Is there a reason you kill the daemon or is that just collatoral damage from killing a session? [21:29] just collatoral, we don't kill it explicitly [21:33] mterry: did you see a direct relationship between how quickly you click on "Prova" and how likely you are to get the bug? [21:34] right, reproduced here... [21:34] stgraber, not sure... honestly I was thinking there was an inverse releationship that the longer I waited the easier it was to trigger. But that may have been my craziness [21:36] stgraber, is it possible that the code path that sets these keys could not be running sometimes? [21:37] unlikely as it's called before the language switch [21:37] so if the UI switches, that code ran and didn't fail (or ubiquity would crash) [21:39] stgraber, so, one thing I know from the past when I run gsettings for a different user is that I need to run it under dbus-launch [21:39] stgraber, which I don't see happening here. But that's more of an always-works or not issue... [21:40] stgraber, like if you try sudo gsettings yourself in a console, I imagine it won't work for you either unless you dbus-launch? Unless that's some weird setup I have [21:41] mterry: sudo -u user -i gsettings ... usually worked for me [21:41] note that -i might be what makes it work, otherwise you inherit $HOME which might be doing the wrong thing [21:42] stgraber, no, -i doesn't help me (and ubiquity's not using that either) [21:45] ah right, though ubiquity runs dbus-launch (but not under dbus-launcher for some reason) [21:45] stgraber, I don't see the dbus-launch call in gsettings.py [21:46] mterry: bin/ubiquity-dm [21:46] (I usually do sudo -u ubuntu dbus-launch gsettings ...) [21:47] stgraber, ah, I meant on the specific sudo call. Like, if I try sudo gsettings in a normal terminal with a dbus session alive and well, I still need a nested dbus-launch for the sudo'd user [21:47] mterry: oh, that sounds weird but is easy to do anyway so can't hurt trying [21:49] well, not so easy to test without a new CD build... will need to do some hacks to test that one ;) [22:07] I doubt I'll be able to make sure that changes work as it's really racy [22:07] though I can check that it doesn't hurt and we can get more testing tomorrow [22:11] mterry: right, wrapping in dbus-launch at least doesn't break anything that I can see. I'll commit that change and release a new ubiquity so we can get more people to test it [22:12] stgraber, heh, OK [22:12] stgraber, testing liveCD stuff is a pain :-/ [22:12] thanks! [22:17] cjwatson: I'm not certain of the right place for bug 969568 [22:17] Launchpad bug 969568 in kickseed "Example kickseed file to add to install reference documents" [Low,New] https://launchpad.net/bugs/969568 [22:17] ubiquity: stgraber * r5356 ubiquity/ (debian/changelog debian/control ubiquity/gsettings.py): Call gsettings through dbus-launch to avoid loosing settings. [22:34] cjwatson: for bug 772470, slangasek was kind enough to do sanity check the diffs. I want it in tomorrow's image so jibel can run some tests and I can fix anything breaking/regressing as a result, so I'm uploading it now. [22:34] Launchpad bug 772470 in ubiquity "os-prober doesn't detect Windows partition but the recovery partition instead" [High,In progress] https://launchpad.net/bugs/772470 [22:37] ubiquity: stgraber * r5357 ubiquity/ (compat/os-prober debian/changelog): Create a separate os-prober cache when WINOSDATA is set in the environment