[01:03] <CIA-3> debian-installer: cjwatson * r1290 ubuntu/ (57 files in 2 dirs): Update help text translations from Launchpad.
[05:53] <superm1> ev, is there a particular reason that usb-creator appends noprompt to the default kernel command line?  wouldn't the users still want to remove the usb disk so it wasn't booted off the next time?
[08:33] <CIA-3> ubiquity: ogra * r4095 ubiquity/ (debian/changelog debian/control scripts/install.py): add support for omap bootloader installation
[08:33] <CIA-3> ubiquity: ogra * r4096 ubiquity/debian/changelog: releasing version 2.2.19
[09:21] <CIA-3> ubiquity: evand * r4096 ubiquity/ (debian/changelog debian/control scripts/install.py): Merge with ogra's branch for ubiquity 2.1.19.
[09:44] <CIA-3> ubiquity: evand * r4097 ubiquity/debian/changelog: releasing version 2.2.20
[10:24] <ev> hrm, "Try Ubuntu" on a USB disk with persistence enabled takes quite a bit as a update-initramfs trigger runs for console-setup, but I suppose that's unavoidable/desirable.
[11:00] <xivulon> ev on the forum the only issue worth investigating seems to be: http://ubuntuforums.org/showpost.php?p=9140185&postcount=110 (no root)
[11:09] <xivulon> davmor2, any issue on your side I should be aware of?
[11:10] <davmor2> xivulon: not that I'm aware of I'll be doing some testing latter though so I'll keep you in the loop with that
[11:24] <dmarkey> cjwatson: change freeze on 10.04 yet? :)
[11:30] <cjwatson> dmarkey: yep
[11:37] <dmarkey> cjwatson: ah i was just kidding. Anyway i'd just like to thank you for all your time/support in trying to get xen support in 10.04!
[12:30] <ev> Can someone spot-check this: http://paste.ubuntu.com/418527/
[12:38] <ev> erm, perhaps I should've been less open given the time of day.  cjwatson, do you have a minute to look that over?  No rush, but perhaps we can sneak it onto the RC.
[13:08] <rgreening> ev: ping
[13:09] <rgreening> ev: bug 566390 seems important. Format button should be disabled if partition is not FAT and set the NEEDS_FORMAT.. yes?
[13:16] <cjwatson> ev: I'm not sure I'm comfortable with that; it seems like "you answered a question a bit differently, so we'll nuke your data" which worries me
[13:16] <cjwatson> ev: maybe this should just be an explicit error?
[13:16] <cjwatson> but early enough to allow better recovery
[13:41] <ev> rgreening: do you mean the Install button?  In the case of the partition being something other than FAT, their only recourse is to erase the disk.
[13:42] <ev> cjwatson: I'm not convinced it should be an error, given that its our combination of having ecryptfs copied to their system and then removed that's causing the bug in the first place.
[13:42] <rgreening> I think the bug indicates that the Make Startup Disk button is enabled, even though the partition isnt of correct type.
[13:42] <rgreening> ev: ^
[13:42] <ev> rgreening: right, that's what I mean
[13:43] <ev> you said "format button should be disabled"
[13:43] <rgreening> my bad
[13:43] <rgreening> sleeptalking
[13:43] <rgreening> :)
[13:43] <ev> heh
[13:44] <cjwatson> ev: well, maybe, but removing their .ecryptfs while keeping the rest of their home directory seems like it could well be undesired, too
[13:45] <cjwatson> since that may essentially render their home directory contents useless
[13:45] <ev> yeah, you're right
[13:45] <ev> okay
[13:45] <ev> error it is
[13:45] <cjwatson> it seems like a sort of "we can't deal with this situation yet" error
[13:45] <cjwatson> as in not technically a real error but ...
[13:47] <ev> I don't suppose there's a nice utility to un-ecryptfs a home directory?  Not for us to use, but to point the user at in this situation.
[13:47] <ev> kirkland`: ?
[13:48] <ev> ah, google is my friend
[14:05] <CIA-3> usb-creator: evand * r303 usb-creator/ (debian/changelog usbcreator/frontends/gtk/frontend.py):
[14:05] <CIA-3> usb-creator: Continue evaluting whether or not a partition can be used even if
[14:05] <CIA-3> usb-creator: there is no source present (LP: #566390).
[14:05] <ev> ^ rgreening that fixes it for me in the GTK frontend
[14:07] <rgreening> thanks ev. I'll have a look
[14:12] <ev> cjwatson: oo, perhaps I'm trying to be too clever for my own good, but what if we solve this by forcing the encrypted home option in user-setup when / or /home is not marked to be formatted but ~/.ecryptfs is present.
[14:13] <cjwatson> that's another option, sure - if anything else is going to give another error anyway ...
[14:13] <cjwatson> I wonder whether it would confuse people more or less.  I'm not sure
[14:18] <rgreening> ev: that enables the Make Startup Disk even is SOURCE_IMG is not available or selected. It shouldn't enabled the Make Startup Disk (install button) technically...
[14:19] <rgreening> its close though... :P
[14:19] <ev> damn :)
[14:19] <ev> sorry, I rushed that one
[14:19] <rgreening> np. thats what you have me for ;)
[14:19] <rgreening> ha
[14:19] <ev> cjwatson: talked with mpt about it, he thinks the radio button approach is acceptable, for what it's worth
[14:19] <ev> rgreening: :D
[14:20] <ev> this does mean that we'll be mounting what will be / and (optionally) /home, which is a bit disgusting, but I cannot think of a more elegant approach
[14:20] <ev> mounting in user-setup, that is
[14:23] <ev> cjwatson: sorry about chatting with mpt offline, I need to be more cognisant of the fact that it doesn't give you an equal voice in the conversation
[14:35] <ev> nevermind the comment about mounting them in user-setup, I'll do it in partman-target and pass it through debconf.
[14:41] <rgreening> ev: just testing that bug further and I cannot reproduce the situation with 0.2.22 as user claims with either gtk or kde version.. strange
[14:42] <ev> rgreening: start usb-creator without a disk plugged in, then plug it in before or after you select a source image
[14:42] <rgreening> ev: ok. I'll try that ( I have the stick inserted and part mounted)
[14:44] <rgreening> ev: It only occurs if you mount the partition manually outside creator (at least in the gtk one). I'll verify in kde one.
[14:44] <ev> no, it occurred for me without manually mounting it
[14:45] <rgreening> hmm... ok, I couldn't get that to occur.
[14:46] <rgreening> as Free Space was not showing anything and therefore part was unavailable. Could it be that the Gnome Desktop auto mounted it for you?
[14:46] <rgreening> KDE doesnt automount
[14:46] <ev> right
[14:46] <ev> ah
[14:46] <rgreening> by default
[14:46] <rgreening> so, its a bug... triggered if outside app automounts the partition
[14:47] <rgreening> ev: I can confirm behaviour now based on this in both apps. I'll try and update your fix now.
[14:47] <ev> thanks
[14:48] <rgreening> np
[14:48] <rgreening> ev: got it. will upload now
[14:52] <rgreening> after testing gtk frontend of course (kde on works correctly now)
[14:55] <rgreening> ev: ok, I can make the kde one work as expected. hell if I can get the gtk one to work.
[14:57] <rgreening> ev: I think its cause you do not start with Make Startup Disk set to disabled (which should be the correct default). Thats what KDE frontend does.
[14:57] <ev> rgreening: okay, I'll look into it once I'm done with this encrypted home bug
[14:58] <rgreening> np ev. I'll keep poking at it. I'll upload the kde fix in the mean time
[14:58] <ev> rgreening: by upload do you mean commit?
[14:58] <rgreening> ya
[14:58] <ev> okay, cool
[15:11] <cjwatson> ev: forcing the radio button?  it's OK to me
[15:11] <cjwatson> by me
[15:11] <cjwatson> michaelforrest: FYI, I discussed the splash screen with sabdfl, and he said to me that he only wants the text/logo blanked but doesn't want the bottom icons removed
[15:11] <cjwatson> michaelforrest: so I implemented that last night
[15:14] <michaelforrest> cjwatson: ok thanks
[15:28] <CIA-3> usb-creator: rgreening * r304 trunk/usbcreator/frontends/kde/frontend.py:
[15:28] <CIA-3> usb-creator: Update check in kde frontend which verifies we CAN_USE selected partition and if not
[15:28] <CIA-3> usb-creator: tell user it needs formatting.
[15:29] <rgreening> ev: can you review that change? It works for KDE frontend, but similar does not under gtk one. dunno why.
[15:29] <ev> yes, once I'm done with this encrypted home stuff
[15:29] <rgreening> ev: oh, and needed to add back the msg about requiring format.
[15:30] <ev> whoa, why?
[15:30] <rgreening> you'll see when you look at the diff
[15:30] <ev> ominous, but okay :)
[15:30] <rgreening> makes complete ui sense
[15:30] <rgreening> otherwise user doesn't know why the make startup button is still disabled
[15:31] <rgreening> :)
[15:35] <ev> yeah, I'm really, really keen on not re-enabling that in Lucid given how poorly it functioned previously and how far into the freeze we are.  They'll find the format button quickly enough.
[15:35] <ev> but I'll look at the patch when I get a chance
[15:38] <rgreening> ev: yeah, I only enabled the 'label' per-se.
[15:38] <rgreening> to allow the user some reason why or what to do next.
[15:39] <rgreening> ev: will you setup a UI review session for usb-creator for UDS. I think we really need to look at this.
[15:40] <rgreening> from a usability perspective.. maybe we can get seele to join/assist.
[15:40] <ev> sure
[15:41] <rgreening> cool.
[15:41] <rgreening> :P
[15:48] <ev> cjwatson: entirely untested, but does this look okay in principal: http://paste.ubuntu.com/418636/ http://paste.ubuntu.com/418637/ http://paste.ubuntu.com/418638/
[15:49] <ev> mm, I should probably handle that question not existing in partman-target
[15:49] <cjwatson> ev: we're going to mount those partitions anyway, so why not do the check after doing so?
[15:49] <cjwatson> oh, because ubiquity isn't ordered that way :-(
[15:49] <ev> indeed
[15:51] <cjwatson> yes, seems OK in principle
[15:51] <ev> okay, cool.  I'll start testing it then
[15:51] <ev> thanks
[16:46]  * cjwatson tries to work out why grub-installer/bootdev's translation isn't being used
[17:18] <cjwatson> oh argh, it was due to a string change I didn't record in my usual place for end-of-cycle translation updates
[17:29]  * cjwatson dives down rabbit-hole of broken cron jobs
[17:59] <CIA-3> partman-target: evand * r793 ubuntu/ (3 files in 2 dirs):
[17:59] <CIA-3> partman-target: Notify user-setup that there is an encrypted home partition present
[17:59] <CIA-3> partman-target: (LP: #566552).
[17:59] <CIA-3> user-setup: evand * r220 ubuntu/ (3 files in 2 dirs): Allow forcing the encrypted home option (LP: #566552).
[18:00] <CIA-3> ubiquity: evand * r4098 ubiquity/ (debian/changelog ubiquity/components/ubi-usersetup.py): Honor user-setup/force-encrypt-home (LP: #566552).
[18:19] <sweeze> for https://bugs.launchpad.net/ubuntu/+source/casper/+bug/565047 , what's the best way of building an install image w/ xhci (usb 3.0) support?  -- or are there other approaches I should be trying?
[18:46] <ev> so I've tested the encrypted home fix by touching /target/home/evan/.ecryptfs.  I've set up a VM with a real encrypted home install on it to test tonight/tomorrow and I'll give the alternate CD a go with that as well.
[18:48] <ev> sweeze: attaching /casper.log from the initramfs might help get to the bottom of your bug: https://wiki.ubuntu.com/DebuggingCasper#casper and kernel log files
[18:49] <sweeze> ev:  doesn't appear to be any way to get casper.log off the machine:  usb key not showing up in /dev/sd*, and no network....
[20:58] <sweeze> ok, managed to get casper.log & dmesg log off the machine through the built in SD-cart slot, updated bug with those logs