[02:04] <ev> bdmurray: they're just downloaded
[02:06] <ev> cjwatson: what are your thoughts on installing them around the point of install_extras in O?
[02:06] <ev> should be a simple apt-get upgrade call continuing on errors
[02:06] <ev> the confusion around download updates vs download and install is fairly common
[02:28] <bdmurray> ev: I didn't see any in /var/cache/apt/
[02:29] <bdmurray>  /var/cache/apt/archives/ that is
[02:29] <bdmurray> I was looking at bug 761094
[02:29] <ubot2> Launchpad bug 761094 in ubiquity ""Download updates while installing" checkbox does nothing" [Undecided,New] https://launchpad.net/bugs/761094
[02:36] <bdmurray> I tried recreating and have a debug log if that would help
[02:57] <superm1> ev, actually you can let the updates get installed from within ubiquity without needing to do apt-get upgrade
[02:57] <superm1> it's just code like this:
[02:57] <superm1>         for key in cache.keys():
[02:57] <superm1>             if cache[key].is_upgradable:
[02:57] <superm1>                 to_install.append(key)
[02:58] <superm1> i did some experiments in a ubiquity plugin trying that out and didn't find an easy way to break it at least
[04:25] <stgraber> superm1: If I understand correctly the code you paste above, you're basically appending any package that's available for upgrade to the apt install list so ubiquity does an apt-get install on it. That should be fine in most cases, but might fail for Edubuntu.
[04:25] <stgraber> superm1: in Edubuntu we have an extra ubiquity step that lets you remove packages from the target system, basically updating the ubiquity blacklist based on what you choose
[04:26] <stgraber> superm1: I'm not sure of what happens if you just to remove a package (or meta package) from Edubuntu and that package is available for update as it'd end up in both the install list and the blacklist
[04:26] <stgraber> (I haven't looked at that part of ubiquity's code in quite a while)
[04:27] <stgraber> this might also affect regular (non-edubuntu) packages that are usually blacklisted (extra langpacks, ubiquity itself, ...)
[04:28] <stgraber> if that's indeed an issue, it should be relatively easy to make sure whatever gets the list of updates is running late enough in ubiquity that we know the blacklist is "final" and can then avoid adding anything to to_install that's currently in the blacklist
[05:11] <superm1> stgraber, that's a good point you raise, should need to be investigated
[05:12] <superm1> i just wanted to raise that it should be fairly achievable (*) with the current infrastructure in ubiquity without having to rely on apt-get
[05:13] <superm1> it might just be solvable by having code compare what's in the blacklist to what's in the upgrade list and tear it out of the upgrade list if necessary
[06:10] <dluzius> how do I get my laptop to connect to my wifi network
[09:15] <ev> superm1: err yes, of course. Apols, it was 2am.
[09:27] <CIA-7> ubiquity: evand * r4691 trunk/debian/changelog: LP bug reference
[10:26] <cjwatson> rbelem: drop scripts into /usr/lib/oem-config/post-install/, and make sure their filenames don't contain '.'
[10:26] <cjwatson> ev: I thought we'd discussed that and agreed that it would be better to reboot into the real system ASAP
[10:27] <cjwatson> ev: also a bit worried that we'd spend our entire lives investigating weird problems caused by some buggy package or another :-)
[10:29] <ev> you're right, we had. I forgot about that specific point
[10:29] <ev> and I completely agree
[10:34] <ev> I'll write it into the spec so I don't forget again
[10:41] <ev> I'm trying to organize bugs for O so we have a list of things we'd rather not lose track of before we hit freezes in that cycle
[10:42] <ev> right now this involves nominating for O, but I suspect that's going to drive skaet up the wall as it fails to differentiate between release-critical bugs (as is my understanding of what the milestone is for) and ones that would be nice to fix
[10:42] <ev> err what the series nomination is for
[10:43] <ev> it's great that we can finally set that ahead of time.  It would be even better if we could set the milestone field ahead as well
[10:45] <ev> not sure if I'm the only one who has this particular use case though
[11:20] <cjwatson> I can probably create a bunch of milestones
[11:21] <cjwatson> now that I've configured unity to stop making me feel vaguely ill
[11:22] <ev> lol
[11:24] <cjwatson> created no
[11:24] <cjwatson> w
[11:25] <cjwatson> so you should be able to set milestones happily now
[11:26] <ev> brillaint!
[11:26] <ev> brilliant even
[11:26] <ev> thanks so much
[11:27] <jussi> vaguely ill. rofl.
[11:28] <cjwatson> the wall slide animation was making me feel seasick (and I'm a very heavy user of workspaces)
[11:28] <cjwatson> turn the duration down to 0, all better
[11:31] <ev> I'm just so happy the battle was won over showing the dock from anywhere. Now if only they could turn off drag to scroll and just make that the action for moving items around, I'd be nearly happy.
[11:58] <kim0> hey folks, my machine waits idle around 2-3 minutes while booting Natty. Any ideas on how I can figure out what it's doing in that time? (console doesn't say anything)
[11:59] <kim0> sorry for being OT wrt installer .. but I figured enough foundations people would be here :)
[12:01] <ev> kim0: https://wiki.ubuntu.com/BootCharting
[12:01] <ev> but this is really off topic for this channel
[12:02] <ev> so please ask further questions about such things in #ubuntu
[12:42] <rbelem> thanks cjwatson :-)
[12:46] <CIA-7> console-setup: cjwatson * r406 ubuntu/debian/changelog: releasing version 1.57ubuntu19
[12:51] <ev> stgraber: that seems to be the same patch you posted before, which didn't work for me
[12:52] <ev> apols for the late reply
[14:19] <ev> so lets see if I still understand this. Any pofile with a base language translation in languagelist or is itself in languagelist should not be removed provided that it's not just noise.
[14:23] <stgraber> ev: hi
[14:24] <stgraber> ev: it's not the same patch, the new one has a " and grub_bootdev in (part[0] for part in misc.grub_options()):" added to it
[14:24] <ev> ahh, I missed that
[14:24] <ev> okay, having a look
[14:24] <stgraber> ev: which "should" fix what you were seeing before
[14:27] <ev> right-o
[14:42] <CIA-7> ubiquity: evand * r4692 trunk/ (bin/ubiquity-dm debian/changelog): Disable ubiquity panel for openbox session.
[14:52] <CIA-7> ubiquity-slideshow-ubuntu: evand * r351 ubiquity-slideshow-ubuntu/ (334 files in 7 dirs): Update translations from Launchpad.
[15:14] <cjwatson> ev: I don't suppose the fix for bug 725408 might have fixed bug 740903 as well?
[15:14] <ubot2> Launchpad bug 725408 in partman-auto "installer hangs detecting existing partitions" [High,Fix released] https://launchpad.net/bugs/725408
[15:14] <ubot2> Launchpad bug 740903 in ubiquity "return_to_partitioning fails when the replace option fails" [High,Confirmed] https://launchpad.net/bugs/740903
[15:16] <Kurisutian> Hey there. Does anyone have experienced the same problems like I did when installing ubuntu-server on a btrfs formated partition? It seems to be quite impossible....
[15:17] <cjwatson> what kinds of problems?
[15:26] <cjwatson> Kurisutian: ^-
[15:27] <Kurisutian> cjwatson: see, I'm running in all kind of problems with that. Not just on arch.... good to see you here... ;-)
[15:28] <ev> cjwatson: not sure, but I'll test to see if it's still an issue nowish
[15:28] <Kurisutian> cjwatson: when choosing btrfs as my rootfs and not having another partition for the install (except a swap partition) I'm not able to install since the installer tells me it was unable to mount the /home partition (which I never did set up in any way)...
[15:29] <cjwatson> Kurisutian: can you give me a recipe for reproducing this?
[15:29] <cjwatson> complete details of which exact CD image you used, what options you selected, etc.; logs wouldn't hurt either
[15:32] <Kurisutian> cjwatson: I'm not at the university right now where this kind of setup is running but I'll do my best to give those information right now
[15:33] <Kurisutian> cjwatson: running on a dell poweredge 1950 with ubuntu-server 64. 2 SAS Drives running a RAID1 with all in all 450GB available. I used the beta 1 cd to install
[15:34] <cjwatson> there've been several critical btrfs fixes between beta 1 and beta 2, so stop there and try beta 2 instead ...
[15:35] <Kurisutian> cjwatson: Kept the english language (although I'm running this setup in germany, but all I need to have is a german keyboard layout, which btw won't be set in the installer either, even when choosing that) and I'm manually partitioning the drive(s)
[15:35] <Kurisutian> cjwatson: Thank you, I will.... I'll get back to you when I did that and it still won't work. I'll be there on monday again.... :-)
[15:36] <cjwatson> I hope that's "if" rather than "when" :-)
[15:36] <cjwatson> (although I know the German construction that comes from ...)
[15:40] <annunaki2k2> Hi everyone - hoping someone can help me here. I'm having trouble preseeding partman-auto "raid" configuration
[15:40] <bdmurray> Earlier I asked about "download updates while installing".  Should those end up in /var/cache/apt/archives?
[15:41] <annunaki2k2> I've checked & double checked, but I can't find any problem with my preseed configuration.
[15:41] <ev> bdmurray: /target/var/cache/apt/archives while the install is running, but after that, yes
[15:42] <bdmurray> ev: I did a couple of installs after the archive unfroze and didn't see anything there
[15:43] <ev> interesting
[15:43] <ev> I'll have a look
[15:43] <bdmurray> I have a debug log from one fwiw
[15:45] <annunaki2k2> anyone? I can pastebin the relevant sections of my preseed file (assuming someone can help).
[15:45] <bdmurray> When I was looking I didn't see the relationship between prepare_download_updates and download_updates
[15:46] <ev> bdmurray: could you pastebin that debug log?
[15:50] <bdmurray> ev: i've added it to bug 761094
[15:50] <ubot2> Launchpad bug 761094 in ubiquity ""Download updates while installing" checkbox does nothing" [Undecided,New] https://launchpad.net/bugs/761094
[15:53] <bdmurray> ev: In ubi-prepare.py I don't see download_updates being set if prepare_download_updates is selected
[15:53] <bdmurray> ev: if that is what is supposed to happen
[15:54] <ev> oh bum
[15:54] <ev> I think I see the problem
[15:55] <ev> and I wonder how, if at all, this worked in maverick
[15:55] <bdmurray> I'd be curious to know what it is since I was looking at the code a bit.
[15:56] <ev> if you search your debug log for ubiquity/download_updates
[15:56] <ev> you'll see that it does get set to true
[15:56] <bdmurray> right, I saw that
[15:56] <ev> but then when the installer tries to read it back later, it's false
[15:57] <ev> my first guess would be that we use parallel debconf instances one you get past partitioning
[15:57] <ev> and the one for the file copy (which is where the updates downloading lives as well) doesn't have any knowledge of the state in the other
[15:59] <ev> mind you, I could be getting this all a bit wrong.  My brain is a bit mush today after I walked home last night ill-equipped for the cold.
[16:11] <ev> stgraber: still no luck.  Deleting an unrelated partition sets the bootloader back to /dev/sda from /dev/sda1
[16:12] <stgraber> ev: hmm, ok. So in your tests, you have two disk with existing partitions, set an existing partition for grub, remove another one and it gets back to /dev/sda ?
[16:12] <ev> stgraber: no, just one
[16:12] <ev> with /dev/sda1 (ext4) /, and /dev/sda5 (swap)
[16:12] <ev> set the bootloader to /dev/sda1
[16:12] <cjwatson> FYI folks, I'm leaving in an hour or two and will be off the grid until Tuesday night / Wednesday morning
[16:12] <ev> then delete /dev/sda5
[16:12] <ev> it will set the bootloader back to /dev/sda
[16:12] <cjwatson> so if you need anything from me then now's a good time to ask
[16:13] <stgraber> hmm, weird, I thought I tested that ... I'll have a look at it now
[16:17] <bdmurray> ev: Is there anything else I can do?
[16:17] <ev> bdmurray: nope, not at present
[16:17] <ev> thanks for bringing this to my attention though
[16:21] <stgraber> ev: ok, found the issue, fixing it now.
[16:21] <ev> cool
[16:32] <stgraber> ev: http://paste.ubuntu.com/594513/ this one should make sure that the current grub option is always in debconf. So a UI reload or even changing ubiquity page should keep the value (as long as the partition exists)
[16:43] <ev> stgraber: looks good, merging
[16:46] <CIA-7> ubiquity: evand * r4693 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py):
[16:46] <CIA-7> ubiquity: Do not reset the bootloader choice unless it's absolutely necessary
[16:46] <CIA-7> ubiquity: (LP: #756920). Thanks Stéphane Graber!
[16:53] <CIA-7> ubiquity: jriddell * r4694 ubiquity/ (debian/changelog ubiquity/plugins/ubi-partman.py): Make radio buttons use label wording for screen reader (LP: #749653)
[16:59] <ev> I was going to wait for her to finish that, but I suppose this is better than nothing given how close we are to the edge
[17:05] <superm1> ev, don't forget to update PageKde for that set_grub_options change too
[17:07] <kirkland> cjwatson: today's daily server image dropped the aubergine background
[17:07] <cjwatson> huh, that's odd
[17:08] <cjwatson> oh, inverted test
[17:08] <cjwatson> kirkland: thanks, fixed
[17:09] <ev> superm1: ah, nice one.  On it now
[17:10] <kirkland> cjwatson: okay, thanks
[17:11] <CIA-7> ubiquity: evand * r4695 trunk/ubiquity/plugins/ubi-partman.py: Fix setting the bootloader in KDE.
[17:19] <CIA-7> ubiquity: evand * r4696 trunk/ (debian/changelog scripts/plugininstall.py):
[17:19] <CIA-7> ubiquity: Move installation of the nvidia driver to after the removal of
[17:19] <CIA-7> ubiquity: unneeded kernels. Divert update-initramfs for the duration and
[17:19] <CIA-7> ubiquity: trigger it afterwards (LP: #759804).
[17:35] <stgraber> oops, should have thought of doing it for KDE too ...
[17:42] <ev> it's okay, I always forget :-P
[17:59] <CIA-7> ubiquity: evand * r4697 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py):
[17:59] <CIA-7> ubiquity: Make the 'name already exists on the network' warning message not
[17:59] <CIA-7> ubiquity: block the user from moving forward (LP: #760884).