=== allee is now known as allee_ [00:50] ubiquity: stgraber * r5041 ubiquity/bin/ubiquity-dm: Make the clear call in ubiquity-dm clear the right tty [00:51] ubiquity: stgraber * r5042 ubiquity/bin/ubiquity-dm: Wait until clear in ubiquity-dm returned [01:01] ubiquity: stgraber * r5043 ubiquity/bin/ubiquity-dm: Don't fail if we can't open the tty [01:01] ubiquity: stgraber * r5044 ubiquity/debian/changelog: releasing version 2.8.3 [08:59] ubiquity: evand * r5045 trunk/ (debian/changelog ubiquity/plugins/ubi-console-setup.py): [08:59] ubiquity: Handle the keyboard query window closed callback being fired twice [08:59] ubiquity: (LP: #865493). [09:23] ugh, this is why I need the Ubuntu geonames server set up in a Vagrant configuration: https://bugs.launchpad.net/ubuntu-geonames/+bug/837054 [09:23] Launchpad bug 837054 in ubuntu-geonames "Time Zone selection shows about 20 different "New York"s and doesn't autoselect my location" [Medium,Confirmed] [11:34] ubiquity: evand * r5046 trunk/ (debian/changelog ubiquity/frontend/gtk_ui.py): [11:34] ubiquity: Allow focusing of labels when we're in the screen reader [11:34] ubiquity: acessibility profile, so that Orca can read them [11:34] ubiquity: (LP: #856782, LP: #856773). [11:35] tried to get the resize widget usable from the keyboard [11:35] but I can't seem to navigate it, even in a simple test application [11:35] using a keyboard that is [11:35] f6 and f8 do nothing [13:00] grr, why is localechooser-apply installed in two places [13:00] wasted an hour of testing time due to that :( [13:05] ubiquity: cjwatson * r5047 trunk/ (4 files in 2 dirs): [13:05] ubiquity: Don't install duplicate copies of console-setup-apply, [13:05] ubiquity: localechooser-apply, and netcfg-wrapper. [13:09] eep [13:09] I'm currently losing time to virtualbox yet again losing the location of my windows 7 disk [13:09] despite it being *right there* [13:20] I'm sure everything would be easier if Simplified and Traditional Chinese had two different language codes [13:20] sigh [13:49] ugh, this definitely appears to be trashed [14:16] argh, why am I getting I/O errors inside kvm [14:17] * cjwatson tries giving it a bit more memory [14:18] :) [14:18] I'm getting "Windows failed to start" using the Windows setup CD [14:18] I don't think today is turning out to be a stellar one for compuing [14:18] computing even [14:23] this is my third try; if this fails I'll have to resort to (shock) real hardware [14:25] hahaha [14:48] I am upgrading an install-server, re-using the preseed.cfg for a lucid LTS (previously karmic). As expected, I get a few questions popping up - how can I figure out which d-i entries correspond to the questins that pop up? [15:10] argh, just noticed I get "shutdown" and "log out" in the session indicator when installing using ubiquity-dm [15:10] I guess I'll have to fix that, seems like I missed it in my tests yesterday [15:11] btw, any reason why we even have indicator-session when in install-only mode? [15:14] is that the same indicator applet that shows you your name? [15:14] if so, i noticed that during an oem-config run it briefly pops up the "OEM" name too [15:16] stgraber: so they can reboot if they really didn't mean to boot the Ubuntu CD [15:16] ev: ah, ok [15:56] ubiquity: evand * r5048 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py): [15:56] ubiquity: Make sure we account for the size of the installation and swap [15:56] ubiquity: partition when calculating the bounds for the partition resizer [15:56] ubiquity: (LP: #769350). [16:03] fun, starting a live session, killing lightdm and starting ubiquity-dm makes gsettings work just fine, doesn't help to reproduce the bug though :) [16:08] ok, I "think" I found the bug. for some reason we don't have $USER set in the environment when using ubiquity-dm [16:08] so ubiquity tries to change the gsettings options for root instead of for the ubuntu user [16:18] ubiquity: stgraber * r5049 ubiquity/ (bin/ubiquity-dm debian/changelog): Update ubiquity-dm to export self.username as SUDO_USER. [16:19] ev: that one line should be all that's needed to fix my gsettings bug, release when you want :) [16:19] yay [16:20] just waiting for the publisher [16:21] and while I do, I'll fire up pbuilder [16:23] ubiquity: evand * r5050 trunk/.bzrignore: Update bzrignore. [17:04] just trying to get a working pbuilder build [17:04] the last one curiously segfaulted somewhere in the depths of gettext [19:05] ev: found out what made it segfault? [20:28] superm1: for bug 868668, is the firewall/router on your network rejecting the connections on tcp/80 or just ignoring them? [20:28] Launchpad bug 868668 in ubiquity "Installer hangs when progressing to timezone page for 45 sec" [Undecided,New] https://launchpad.net/bugs/868668 [20:29] superm1: I'd expect wget to give up quite quickly if it gets reject but the timeout value can be pretty high if it just doesn't get any response [20:29] stgraber, ignores them [20:30] it's annoying that DNS resolves though [20:30] ok, so would probably be worth tweaking the timeouts in the code a bit so it doesn't take that long [20:30] I'll have a quick look at that once I'm done testing Edubuntu [21:02] superm1: is it only tcp/80 that's being dropped or everything except 8080 to whatever your proxy server is? [21:02] dropping packets really is rubbish, you should get that fixed [21:02] I consider that hostile firewall design ... [21:03] cjwatson: it's unfortunately common :( I've seen that one quite a few company and university networks, though in some cases it's not so much dropping everything as just not having a route to the outside (with the same result) [21:03] stgraber, everything except local network servers and what the proxy server is [21:03] it's common, but I don't think it should be tolerated when it can be changed [21:04] and it's the latter where there is no route to the outside really [21:04] BTW I knew the timezone page was slow in this case but did not consider it RC, as most people can still easily complete the questions before ubiquity finishes copying files [21:05] I'm not sure why it's been escalated through oem-priority given that [21:05] it's more the oem-config scenario that it matters [21:05] ah, I guess that does have a similar problem, yes [21:05] because testers get to the page and it's hung and bugs get filed [21:07] the fix is probably pretty invasive though [21:07] for oneiric [21:08] if it's not fixed for oneiric, it might just need to be SOP for oneiric to unplug the cable before going through oem-config or something i guess then [21:09] I'm just trying to think of what a fix would look like [21:09] I'm surprised it takes 45s, the code indicates it should take 15s + loading time of the ubiquity page, so let's say 20s maximum [21:09] and testing here seems to match that [21:09] 30s for rdate maybe? [21:10] rdate is already wrapped in progresscancel; there's no progress bar on that page, but that means ubiquity at least has a way to cancel it [21:10] the wget is trickier [21:11] we have the connectivity check in the ubiquity frontend, so maybe we could stub out that wget [21:12] yeah, that was my plan too, except that I just noticed that the connectivity check is buggy :) [21:12] oh? [21:12] it uses --timeout=15 but it's been running for 6 minutes here :) [21:12] ! [21:12] it's not just repeatedly running? [21:12] same pid [21:12] stubbing out the wget would require either a change in ubiquity, or a compat script [21:13] er, a change in *tzseteup [21:13] can't type, YKWIM [21:13] ok, found the problem [21:13] we start wget with -T 15 but not with -t 1 for the connectivity check [21:13] so it waits 15s per try, with a possibly infinite number of retries [21:14] ah, yes [21:14] default is 20 [21:14] -t 1 -T 15 is what's being used by tzsetup and probably a good idea of the connectivity test too [21:14] well, allegedly, that would give five minutes though [21:14] agreed === allee_ is now known as allee [21:15] I think the easiest would be to give ubi-timezone a plugin_set_online_state method so that it gets told about state, and then before it starts the d-i callout it can preseed tzsetup/geoip_server to empty if it doesn't have connectivity [21:16] that will get rid of the wgwet [21:16] and probably simplest to preseed clock-setup/ntp to false as well, which will get rid of the rdate [21:17] slightly brutal but that seems like the least invasive fix [21:17] stgraber: are you OK with doing that? [21:18] ubiquity: stgraber * r5051 ubiquity/ubiquity/ (frontend/base.py plugins/ubi-language.py): Whenever we call wget with a timeout, also set the number of tries to 1 instead of default of 20 [21:19] cjwatson: yep [21:19] ubiquity: stgraber * r5052 ubiquity/debian/changelog: Update changelog [21:20] * cjwatson fails to understand why ubi-language has its own implementation of check_returncode *and* a plugin_set_online_state method [21:20] oh, it's talking to a different URL [21:21] try: [21:21] import lsb_release [21:21] _ver = lsb_release.get_distro_information()['RELEASE'] [21:21] except: [21:21] _ver = '10.10' [21:21] classy [21:21] :) [21:21] * cjwatson fixes [21:22] ubiquity: cjwatson * r5053 trunk/ (debian/changelog ubiquity/plugins/ubi-language.py): Bump fallback Ubuntu version number in ubi-language to 11.10. [21:54] cjwatson: http://paste.ubuntu.com/703017/ [21:56] stgraber: s/thing/think/ in the changelog :) [21:56] stgraber: what happens if we get to the timezone page before the 15 seconds for the initial check have elapsed? [21:56] stgraber: I wonder if maybe we'd be better off initialising self.online = False [21:57] with a TODO comment saying that we can flip this once we have the ability to abort the wget / rdate in progress [21:57] well, the way ubiquity seems to work is that it first runs plugin_set_online_state as True if Network Manager says we're online. Then starts the wget in background and sends a False if it timeouts or doesn't match the expected content. [21:58] so whatever default we set in ubi-timezone, it'll always be True until wget times out [21:58] hm [21:58] that's awkward then; many users won't take as long as 15 seconds to get past the first page [21:59] indeed [21:59] we could change the logic to be offline until we get the right content from wget [22:00] I personaly think it'd make sense though we need to make sure that server will scale on release day :) [22:00] actually, are you sure? the network_change stuff only calls set_online_state if False [22:01] I don't see code setting it to True unless it gets a response from wget [22:01] I only assumed it was as ubi-prepare always shows I'm connected until wget times out [22:01] but maybe it's just the default on ubi-prepare that's wrong too [22:02] yeah, that's just ubi-prepare [22:02] the actual underlying code looks OK [22:02] ok, setting self.online to False by default then [22:03] the rest looks fine [22:03] I wish my Chinese handling tests weren't taking forever and a day [22:04] ubiquity: stgraber * r5053 ubiquity/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Don't contact geoip or run rdate if we don't have internet connectivity [22:05] cjwatson: should I try to make ubi-prepare consistent with ubi-timezone (as in, not showing you're online when wget is still running)? [22:05] argh, forgot to pull again... time to bzr bind that branch :) [22:06] ubiquity: stgraber * r5054 ubiquity/ (debian/changelog ubiquity/plugins/ubi-timezone.py): Don't contact geoip or run rdate if we don't have internet connectivity [22:08] I think leave ubi-prepare alone at this point [22:08] and maybe file a bug [22:08] anyone want to comment on http://paste.ubuntu.com/703026/ and http://paste.ubuntu.com/703027/, for bug 590108? [22:08] Launchpad bug 590108 in ubiquity "User get wrong system language after executing oem-config, if he is a foreigner in the country he selected in timezone select stage" [Medium,In progress] https://launchpad.net/bugs/590108 [22:12] I've yet to test this all the way through, working on that [22:16] the comments make sense, it indeed won't affect anything that's not pt or zh, as for the rest, can't comment much without testing (and I already did my chinese install of the day ;)) [22:18] I'm on about my fifth :-/ [22:18] I probably could have made it more general but decided it was safest to constraint it [22:18] constrain* [22:18] gah. coffee. === allee is now known as allee_ [22:26] I'll go ahead with localechooser - I've tested that at least in d-i [22:27] localechooser: cjwatson * r165 ubuntu/ (debian/changelog post-base-installer.d/05localechooser): [22:27] localechooser: For cases where selecting a different location may imply a different [22:27] localechooser: dialect of the language, i.e. Portuguese and Chinese, take care to set [22:27] localechooser: LANG to something reflecting the location and [22:27] localechooser: LANGUAGE/LC_MESSAGES/LC_CTYPE/LC_COLLATE to something reflecting the [22:27] localechooser: language (LP: #590108). This roughly matches the behaviour of [22:27] localechooser: language-selector. [22:27] and that needs to go ASAP [22:28] localechooser: cjwatson * r166 ubuntu/debian/changelog: releasing version 2.37ubuntu2 [22:32] stgraber: so did pbuilder work OK for you or was it just ev? (or have you tried?) [22:33] cjwatson: didn't try. I usually push to a PPA for testing [22:33] I can try it locally now if that would be helpful [22:33] waiting for an install anyway [22:37] running it through now [22:53] currently building in a PPA: https://launchpad.net/~stgraber/+archive/experimental/+build/2825494 [22:55] * cjwatson requests a ubiquity translations export === kentb is now known as kentb-out [23:14] built cleanly here [23:16] ooh, and that looks suspiciously like a correct /etc/default/locale [23:16] now I just have to test oem-config [23:27] ubiquity also built fine for both i386 and amd64 on the PPA builders [23:32] ubiquity: cjwatson * r5055 trunk/ (9 files in 3 dirs): Update translations from Launchpad.