[09:35] ubiquity-slideshow-ubuntu: cjwatson * r390 ubiquity-slideshow-ubuntu/debian/changelog: changelog for last commit [09:47] ubiquity-slideshow-ubuntu: evand * r391 ubiquity-slideshow-ubuntu/ (381 files in 7 dirs): [09:47] ubiquity-slideshow-ubuntu: Update translations from Launchpad at the request of the Lithuanian [09:47] ubiquity-slideshow-ubuntu: translation team. [09:54] ubiquity-slideshow-ubuntu: evand * r392 ubiquity-slideshow-ubuntu/debian/changelog: releasing version 49 [09:55] ubiquity: cjwatson * r5015 trunk/ (3 files in 2 dirs): [09:55] ubiquity: Preserve ordering of disks returned by partman-auto rather than [09:55] ubiquity: shuffling them based on dictionary ordering (LP: #770711). This uses [09:55] ubiquity: collections.OrderedDict, which requires Python >= 2.7. [10:14] cjwatson: Have I been smoking the good stuff all weekend, or didn't you commit a partman/OrderedDict change already? [10:14] Hrm. Maybe you were just discussing it. [10:17] just discussing - I hadn't tested it at that point [10:28] jibel: bug 743359 - have you seen this yourself with 2.8.1? do you have up-to-date logs? I couldn't see any logs from 2.8.1 in that bug or its dups [10:28] Launchpad bug 743359 in ubiquity "Installer: LockFailedException: Failed to lock /target/var/cache/apt/archives/lock" [High,Triaged] https://launchpad.net/bugs/743359 [10:30] jibel: there are reports from beta 2 but that's an earlier version [10:45] cjwatson, yes I reproduced it this morning. I'll upload the logs [10:48] thanks [11:19] * cjwatson reproduces bug 856418. How curious [11:19] Launchpad bug 856418 in ubiquity "KDE OEM Mode Hang On Shutdown" [High,Incomplete] https://launchpad.net/bugs/856418 [11:24] * ev is on bug 769350 - have a solution but looks like my code is interacting poorly with partman, investigating [11:24] Launchpad bug 769350 in partman-auto "resized partition size doesn't count swap space size." [High,Triaged] https://launchpad.net/bugs/769350 [11:31] ah no, it's just monday morning not using logger correctlyt [11:39] I had a wiki that had turned into an immutable page... any idea what I may have done wrong? [11:41] you probably got logged out [11:44] and there goes my Monday morning moment! thanks, cjwatson [13:17] ev: going to be poking at ubiquity this week, trying to fix as many milestoned bugs as possible before the sprint. Do you have some in particular you want me to look at or should I just go through the current list? [13:18] hmm [13:18] seeing where we stand with bug 800760 would be good [13:18] Launchpad bug 800760 in ubiquity "Needs gconf to gsettings updates" [Medium,Confirmed] https://launchpad.net/bugs/800760 [13:19] ok, I'll start with that then. [13:20] thanks [14:02] bug 830946 just appeared on our milestone list [14:02] Launchpad bug 830946 in ubiquity "Nothing displayed on embedded terminal." [Medium,Confirmed] https://launchpad.net/bugs/830946 [14:24] really? That's a bit silly. It's a UI nit at best. [14:24] but okay [14:27] jibel: would you like to explain your milestoning? [14:40] ubiquity: cjwatson * r5016 trunk/ (bin/oem-config-prepare debian/changelog): [14:40] ubiquity: Run only those parts of oem-config-prepare that require root access as [14:40] ubiquity: root; in particular displaying confirmation dialogs is now done as the [14:40] ubiquity: calling user, which avoids KDE confusion (LP: #856418). [14:56] ev: I'm happy to dig out APUE and have another crack at bug 743359 if you like [14:56] Launchpad bug 743359 in ubiquity "Installer: LockFailedException: Failed to lock /target/var/cache/apt/archives/lock" [High,Triaged] https://launchpad.net/bugs/743359 [14:58] please do [14:58] I'm at my wits end with that one [14:58] thanks [14:58] I think you were actually right with the process group idea now that I look at it more closely, but we need to take more care to ensure that update-apt-cache is actually a separate pgrp [14:59] and maybe repeated-retry-for-a-bit-until-dead would be a good idea [15:02] cjwatson, I milestoned bug 830946 because it is a regression over Natty, has duplicates, clear instructions how to reproduce it and it can not be fixed with a SRU. [15:02] Launchpad bug 830946 in ubiquity "Nothing displayed on embedded terminal." [Medium,Confirmed] https://launchpad.net/bugs/830946 [15:02] It is medium importance because it doesn't limit the functionality of a core application. [15:04] As long as you don't mind it being ignored [15:04] (we still have a large High list) [15:16] ev: do you have a copy of APUE, by the way? bit of a brick of a book, but very useful [15:16] I do! [15:16] I haven't leafed through it in ages though [15:16] should really get back on that [15:16] I really wish there was an ebook version though [15:17] always a pain to have that extra weight in the suitcase for UDS and the sprints [15:22] yeah, I don't carry it [15:23] I think the way I use it (lots of flicking about) would not be very e-book friendly, although searching would be useful [15:23] though OTOH it has excellent contents/indexing [15:41] ev: I guess the probability of encountering this bug goes up the older the image you're using has got [15:41] since 'apt-get upgrade' will take longer [15:41] indeed [15:41] or if, say, you're on fibre to the canonical datacenter [15:41] sadly I only have current images :-) I'll see if I can fake something up [15:42] for example "drop all outgoing packets" might slow apt-get down enough that copy_all beats it [15:42] heh, nice [15:43] ubiquity: stgraber * r5017 ubiquity/bin/ubiquity-dm: temp [15:43] doh, I need to make CIA clever when I do temporary commits ;) [15:55] hah! I'm an idiot [15:55] was wondering why int(value * 1024 * 1024) wasn't working [15:56] beacause that's a rather large string it's turning into an integer [15:56] because* [15:56] d'oh [15:56] I'm blaming that one on it being Monday [15:56] I blame many things on that [15:57] Although it has the disadvantage of being an excuse that only works for 20% of the working week. Blaming things on there being a 'y' in the day works better. [15:57] lol [15:58] boo, that doesn't work because apt-get update isn't pointed at /target/var/cache/apt [16:01] maybe if I stick the iptables between update and upgrade ... [16:24] Have you all seen bug 825238? [16:24] Launchpad bug 825238 in casper "screen reader does not start in a11y installation" [High,Confirmed] https://launchpad.net/bugs/825238 [16:31] translation bugs, bug 838141, don't require a ubiquity task correct? [16:31] Launchpad bug 838141 in ubiquity "English strings in Swedish translation" [Undecided,New] https://launchpad.net/bugs/838141 [16:31] I could definitely use some extra pairs of eyes on the following merges: [16:31] https://code.launchpad.net/~ev/partman-partitioning/save-swap-size/+merge/77970 [16:31] https://code.launchpad.net/~ev/ubiquity/factor-swap-in-resize/+merge/77973 [16:32] bdmurray: translation> there's only any point in making it ubiquity's problem if the string is untranslatable (i.e. doesn't appear in the pot files) [16:32] cjwatson: okay, thanks [16:37] ok, that seems to reliably reproduce this; nice wide race window [16:37] cjwatson: where does this dialog come from? https://launchpadlibrarian.net/78625495/translation1.png [16:41] bdmurray: console-setup [16:42] bdmurray: that part should be fixed as of 26 Sep though [16:43] yep, installation media from 20110831 [16:43] so you should just be able to mark that part as done [16:43] hm, I might have misunderstood which partition min_size and max_size refer to. Rubbish. [16:43] cjwatson: okay, thanks [16:44] min_size and max_size refer to the partition being resized [16:45] https://code.launchpad.net/~ev/partman-partitioning/save-swap-size/+merge/77970 is entirely full of conflicts, and in any case wanted to be proposed against lp:~ubuntu-core-dev/partman-partitioning/ubuntu not lp:partman-partitioning [16:46] yikes [16:46] will fix [16:46] and indeed [16:46] um, wow, um, complicated [16:47] it's not feasible to have something we call out to from ubiquity directly rather than doing it in the resizing library? [16:49] I can't actually find a bug in it as such, just worried about testing [16:49] 'decode_recipe $(get_recipedir)/[0-9][0-9]atomic linux-swap' is a scary lilne [16:49] *line [16:49] but I guess as long as we make sure it's tested both in d-i and ubiquity ... [16:50] perhaps it would be worth having an NIHed python recipe decoder in P [16:50] although there's some non-trivial logic there; perhaps a wrapper that hides the evil of shelling out [16:51] I just wanted to be sure we weren't hardcoding an assumed swap size [16:51] oh, agreed [16:51] but yes, I suppose something in ubiquity itself would work [16:51] ah [16:52] I guess I was thinking of shipping a tiny script that did . /lib/partman/lib/recipes.sh; decode_recipe blah; echo "$scheme" and then parse its output in a python library [16:52] but this is probably a smaller change for 11.10 [17:12] ubiquity: stgraber * r5017 ubiquity/ (bin/ubiquity-dm debian/changelog): Update ubiquity-dm to set gsettings keys instead of gconf [17:13] ev: ^ that bit is just for ubiquity-dm. The code seems to "work" here (when copy/pasted and ran separately) but I didn't try ubiquity-dm itself [17:14] does that need a bug closure in the changelog? [17:14] I didn't include the bug closure because the bug includes quite a bit more than just ubiquity-dm. I'll now be working on the others. [17:14] ok [17:15] bug 800760 [17:15] Launchpad bug 800760 in ubiquity "Needs gconf to gsettings updates" [Medium,Confirmed] https://launchpad.net/bugs/800760 [17:16] ubiquity: cjwatson * r5018 trunk/ (debian/changelog scripts/install.py scripts/update-apt-cache): [17:16] ubiquity: Go back to killing update-apt-cache's process group, but this time make [17:16] ubiquity: sure that it's in a separate process group and make more of an effort to [17:16] ubiquity: ensure that it terminates (LP: #743359). [17:17] ev: ^- a double-check of that wouldn't hurt, though it passes my torture test now and I watched it killing the process group [17:18] cjwatson: will do. About to head out to the cinema with some millbank folk, but I'll have a look first thing in the morning [17:18] as I also fix up these merge proposals [17:18] I think I may be mostly out of steam for today, but should I do an upload? [17:18] ev: in plugininstall.py the code won't work with current NM. Should I port it to the new NM or just drop it (no longer using gconf + gnome-keyring but instead ini files in /etc/NetworkManager/system-connections)? [17:18] max testing time and all that [17:19] ev: should be fairly trivial to change (copytree of /etc/NetworkManager/system-connections should do the trick) [17:20] cjwatson: I'll probably have a few more commits today. I can do an upload when I'm done. When is the deadline to get something in tomorrow's dailies? [17:20] cjwatson: by all means [17:20] stgraber: we definitely still need the functionality [17:20] stgraber: I wouldn't worry about exactness of that [17:20] as the installer now has that wireless page [17:20] but whatever is cheapest, really [17:21] sometime tonight your time should be OK [17:21] I'll do a translation refresh now [17:21] ev: ok, I'll replace that code by a simple copytree of all of NM's config then [17:21] brill [17:21] thanks [17:21] cjwatson: ok, will upload before leaving the office then [17:21] cool, thanks [17:31] ubiquity: stgraber * r5019 ubiquity/ (debian/changelog scripts/plugininstall.py): Update copy_network_config to work with Network Manager 0.9 storing the configuration system wide [17:32] ubiquity: cjwatson * r5019 trunk/debian/ (changelog real-po/hr.po real-po/sk.po): Update translations from Launchpad. [17:32] um, sorry, I beat you to that, you'll need to merge [17:32] (bound branches FTW) [17:33] ubiquity: stgraber * r5020 ubiquity/ (debian/changelog scripts/plugininstall.py): Update copy_network_config to work with Network Manager 0.9 storing the configuration system wide [17:33] or uncommit/recommit, fair enough :) [17:34] merging easily gets messy, uncommit/recommit is easy when it's only one commit, gets tricky when it's multiple including multiple changes to the same file [17:46] * cjwatson is out of steam. See you later [18:48] ubiquity: stgraber * r5021 ubiquity/ubiquity/gsettings.py: Add initial implementation of gsettings module [18:52] ubiquity: stgraber * r5022 ubiquity/bin/ubiquity-dm: Port ubiquity-dm to the new gsettings module [18:53] ok, now that I have that gsettings module, porting the rest of the code should be pretty easy [19:01] ubiquity: stgraber * r5023 ubiquity/ubiquity/components/apt_setup.py: Port apt_setup proxy configuration to gsettings [19:03] ouch, gtk_ui.py is going to be fun to switch to gsettings... [19:08] ubiquity: stgraber * r5024 ubiquity/ubiquity/gsettings.py: If SUDO_USER is set, use that for gsettings by default [19:32] ubiquity: stgraber * r5025 ubiquity/ubiquity/frontend/gtk_ui.py: Switch gtk_ui from gconf to gsettings [19:42] Ugh. This anacron thing is killing me. :/ [19:43] ubiquity: stgraber * r5026 ubiquity/ubiquity/misc.py: Add a note that we need to convert misc.py to gconf (currently not needed as the function is disabled) [19:43] And I realised that just touching stamp files probably won't help, since it's already running by the time the installer launches, and the delay is ticking. [19:43] I'm at the point where I'm considering just stopping anacron and cron before the install, and starting it/them at the end. [19:44] Or maybe changing the default cron.daily delay from 5 minutes to an hour or something... [19:45] Or make the apt update cronjob exit if [ -x /usr/bin/ubiquity ] ... How evil would that be? :P [19:46] ubiquity: stgraber * r5027 ubiquity/debian/changelog: Update changelog [19:47] ok, there we go for gsettings. Now the fun part, testing all of that... [19:48] going to run 2-3 test installs trying to stress test the changes, if that works I'll upload to the queue [19:48] Any brilliant thoughts on my cron.daily-during-install headaches? :) [19:51] checking for oem-config/ubiquity would definitely be the easiest way to fix your use case with minimal impact to other ways of installing Ubuntu [19:51] though I think it'd be good for everyone not to have these start on first boot [19:52] Hrm. [19:52] -u, --update [19:52] incremental update, reindexing only those packages whose version has changed since [19:52] the last run [19:52] ^-- Note that the call in cron.daily doesn't use -u [19:52] I wonder if this would make things significantly happier.. [19:53] oh, interesting, would probably be a good idea to poke mvo to confirm that -u does what it's supposed to and check that we can indeed use it in the cron [19:53] but that sounds like a good solution both for the first boot usecase and for the "this cron job takes hours to run" problem :) [19:54] Testing to see if it actually matters in practice. [19:54] It might just be I/O bound on writing the massive DB regardless. [19:55] Hrm, no, -u does seem to be significantly faster. [19:55] And you'd think it was introduced for just this use case. :P [19:55] If only mvo was around. [19:57] infinity, you have casper in your ubiquity setup no? how about nuking the job from casper? [19:58] No casper, no. [19:59] We have jasper, which doesn't do anything on second boot. (It resizes the root fs, massages some stuff on the filesystem, then reboots into oem-config) [20:00] Could add some code to run on second boot, though, we don't remove it until later. [20:00] Seems unpleasant, however. [20:00] And I don't want this to be ARM-specific. [20:00] That said, '-u' seems to make a HUGE difference here. [20:02] Next test is to alter an install image with -u and see if my timeouts go away. [20:03] (PS: dbus timeouts killing installer processes is a pretty awful failure mode) [20:03] i feel like there really shouldn't be any cron jobs allowed to really run during install or during oem-config [20:03] Yeah, I'm inclined to agree. [20:04] And stopping anacron/cron at the beginning of the install and starting them at the end does sound sane. [20:04] so maybe it's better to tell ubiquity to stop it / restart it [20:04] yeah [20:04] So, 42s for -u, 346s without. [20:04] I have a feeling this should be done anyway. :P [20:06] ubiquity: stgraber * r5028 ubiquity/ubiquity/ (frontend/gtk_ui.py gsettings.py): Fix obvious mistakes found by pyflakes [20:10] So, some sort of disable_cron() called from main, right after acquire_lock(), and an atext.register(enable_cron) [20:10] This might not be that ugly. [20:11] I'm assuming there are no python upstart bits, I probably just need to fork shells? [20:11] apt-cache search upstart python seems to agree. [20:12] well actually it looks like anacron is disabled for a standard ubiquity install already to me [20:12] there is some code in casper's 25configure_init to do it [20:12] you can control upstart over dbus, but subprocess.Popen is going to be a lot easier :) [20:12] superm1: Ahh, but that's in casper. It should be in the installer itself, methinks. [20:13] well, if you just use the live environment and don't start ubiquity, you still don't want xapian update running as it's going to eat your memory (aufs) for no good reason [20:13] but you also don't want cron being mean in oem-config, so maybe needs to be both then [20:13] It completey diverts anacron? [20:13] yeah [20:14] another way to solve it then is to divert during oem-config-prepare [20:14] What un-diverts them? [20:14] probably nothing [20:14] nothing needs to, it's only effective in the live environment [20:15] Oh, bleh. [20:15] Right. [20:15] Not the case for me. [20:15] My live == My installed system. [20:44] yeah, PPA build of ubiquity succeeded! [20:44] now to wait 2 hours to get the i386 one and be able to do some tests :) [20:45] oh actually, just having ubiquity and ubiquity-frontend-gtk may be enough for my tests [21:11] ubiquity: stgraber * r5029 ubiquity/ubiquity/gsettings.py: Convert booleans before giving them to subprocess [21:14] interesting, apparently we can't hide "suspend" from the session indicator... [21:15] so during install the user can still suspend the machine. I guess it's still better than shutdown or reboot though :) === NCommander is now known as Guest45434 [21:31] infinity: planning on pushing some changes to ubiquity in the next hour or can I upload it? [21:32] stgraber: No, go to town. [21:32] ubiquity: stgraber * r5030 ubiquity/debian/changelog: releasing version 2.8.2 [21:32] stgraber: I need to talk to mvo tonight when he gets in to work. [21:38] ubiquity: stgraber * r5031 ubiquity/scripts/plugininstall.py: Skip LTSP live when copying network to the target [23:02] cjwatson: ping, do you think its possible to get one last d-i upload to boost the size of the OMAP4 images? === Guest45434 is now known as NCommander === NCommander is now known as Guest61019 [23:14] Guest61019: Commit fix, upload, ask forgiveness? [23:14] Guest61019: It'll end up being me or Colin that reviews it anyway. :P [23:20] infinity: k [23:23] NCommand1r: go ahead [23:23] NCommand1r: actually [23:23] NCommand1r: could you just commit but not upload? if you're going to do that, I'd like to refresh translations in the same upload [23:24] NCommand1r: and I have the scripts for that [23:30] cjwatson: sure, I'll commit in about an hour or so (network here is going about the same speed as a tortise) [23:31] NCommand1r: I'll commit the translations before that, then, and you can upload [23:31] I'll be in bed in an hour [23:31] k [23:31] k [23:31] just awaiting the tarball now === NCommand1r is now known as NCommander === Guest16725 is now known as StevenK [23:53] debian-installer: cjwatson * r1546 ubuntu/ (3 files in 2 dirs): Update help text translations from Launchpad. [23:54] NCommander: ^- there, just make sure to include that