=== joejaxx [i=joejaxx@fluxbuntu/founder/joejaxx]  has joined #ubuntu-installer
=== xivulon [n=ago@87-194-85-156.bethere.co.uk]  has joined #ubuntu-installer
[12:44] <xivulon> http://wubi-installer.org/devel/dist/
=== xivulo1 [n=ago@87-194-85-156.bethere.co.uk]  has left #ubuntu-installer [] 
=== xivulon [n=ago@87-194-85-156.bethere.co.uk]  has joined #ubuntu-installer
=== xivulon [n=ago@87-194-85-156.bethere.co.uk]  has left #ubuntu-installer [] 
=== mpt [n=mpt@121-72-139-108.dsl.telstraclear.net]  has joined #ubuntu-installer
[05:33] <CIA-18> ubiquity: superm1 * r2347 ubiquity/ (4 files in 4 dirs): merge with ubiquity-mythbuntu. this includes mvo's patch for proper package installation
[05:34] <superm1> (Now that we are past RC)^
[05:35] <superm1> cjwatson, or evand, could you release 1.6.7 sooner rather than later so the dailies can be double checked?  It appears to work for me on both variants (mythbuntu and a gutsy with that applied), but would like to be sure
[05:36] <evand> I'd do it, but I want to make sure these changes are allowed to be in the final release.  I'm still somewhat confused as to what is allowed to change between RC and final.  I thought it was only RC critical bugs.
[05:36] <evand> By make sure I mean check with cjwatson
[05:40] <superm1> well cjwatson had mentioned before when i brought this up that he didn't want to slip it in right before RC, but that we can probably try right afterward
[05:40] <superm1> if it ends up that it can't stick, i'll revert it and our gutsy release will just have to use a PPA built ubiquity
[05:42] <evand> ok
[05:46] <superm1> probably better to wait for his word again though in case he has changed his mind
[05:59] <evand> indeed
[05:59] <evand> hrm, mandriva immediately crashes when I try to install it in VMWare.
[05:59] <evand> as did Fedora Rawhide
[06:00] <evand> they don't seem to like SCSI disks.
=== dietzbp [n=ubuntu@71-209-102-46.dvnp.qwest.net]  has joined #ubuntu-installer
=== mpt [n=mpt@222-155-23-106.jetstream.xtra.co.nz]  has joined #ubuntu-installer
=== dietzbp [n=ubuntu@71-209-102-46.dvnp.qwest.net]  has left #ubuntu-installer [] 
[09:07] <CIA-18> migration-assistant: evand * r67 migration-assistant/ (debian/changelog ma-script-utils):
[09:07] <CIA-18> migration-assistant: * Added a short timeout and retry to unmounting to accomodate slow umounts
[09:07] <CIA-18> migration-assistant:  (LP: #135149).
[09:07] <evand> still mulling over whether or not that's appropriate
[09:08] <evand> shouldn't umount be a blocking operation or is that different in fuse?
[10:12] <cjwatson> superm1: I can see at least one bug in that patch already
[10:12] <cjwatson> (the default updateInterface implementation doesn't return a boolean, which our run() expects
[10:13] <cjwatson> )
[10:13] <cjwatson> superm1: I'm really not very happy about this patch, and I wish you'd asked before merging as now the history will be wonky
[10:15] <cjwatson> evand: it should block or fail, but it is allowed to fail ...
[10:15] <cjwatson> evand: there's umount -l, but I'm not sure if that's appropriate here
[10:18] <cjwatson> 09:17 <mvo> cjwatson: my idea with the patch was that the mythbuntu folks use it, I don't think it should go into our CDs at this point
[10:18] <cjwatson> 09:17 <mvo> cjwatson: that should read "that only they use it"
[10:26] <evand> sorry, what I said was a bit off.  What really confuses me is that it's returning that the device is busy when it's just copying files.  I though the only thing that caused an error was operations that would never end, like sitting in a directory that you're trying to unmount.
[10:26] <evand> of course I could be wrong about this assumption.  I haven't been able to reproduce the bug yet.
[10:26] <evand> but I'll give it more thought in the later morning
=== evand bed
[10:28] <cjwatson> night
=== cjwatson does timezone maths
[10:28] <cjwatson> wow
[10:28] <cjwatson> evand: busy just means "something has a file open on this device"
[10:29] <cjwatson> the kernel doesn't attempt to figure out how long the relevant operation is likely to take
[10:30] <evand> Sorry, I wasn't trying to say that it did, just that it only failed in circumstances like sitting in a directory that needs to be unmounted.  Whenever I unmount a volume it always waits for the writes to finish, then returns.  Is this not always the case?
=== xivulon [i=c2325681@gateway/web/cgi-irc/ircatwork.com/x-f5a60c51d42be0ae]  has joined #ubuntu-installer
[10:33] <evand> s/volume/device/
[10:34] <xivulon> evand, cjwatson, I uploaded also the wubi-cdboot version with autouninstaller
[10:34] <xivulon> http://wubi-installer.org/devel/dist/
[10:35] <xivulon> rev329 is the one with uninstaller, rev328 is the one in the rc
[10:35] <cjwatson> evand: no, it fails if somebody has a file handle open on the device too - that handle happening to be some process' current directory is just a special case of that
[10:35] <cjwatson> xivulon: thanks
[10:35] <evand> ahh
[10:36] <evand> but, I'm guarenteed m-a is not running at that point
[10:36] <cjwatson> evand: are you thinking of removable devices?
[10:36] <cjwatson> oh, hmm
[10:36] <evand> as it's not forked
[10:36] <xivulon> please test it well, and drop me an email if anything is wrong. I'd be particularly interested if you could reproduce the crashes mentioned by evand
[10:36] <cjwatson> evand: where you might have cached writes still happening to USB, say?
[10:36] <evand> yes
[10:36] <cjwatson> evand: ok, then I agree that shouldn't block unmount
[10:37] <cjwatson> but I think it's sane to work around it at this stage
[10:37] <evand> but I'm thinking of that for the example
[10:37] <evand> in this case what I think is happening
[10:38] <evand> is that they have at least two partitions, and m-a runs on the first, then umount is called, but something is still chugging along and the umount fails
[10:38] <evand> the first being ntfs
[10:38] <evand> http://launchpadlibrarian.net/9948608/syslog
[10:38] <evand> of course it's late and I could be completely and wildly off
[10:39] <evand> I'm led to this conclusion as /mnt/migrationassistant is only used by m-a
[10:40] <evand> oh wow
[10:41] <evand> nevermind, thought I saw something
[10:44] <cjwatson> yeah, it's possible
=== Starting logfile irclogs/ubuntu-installer.log
=== ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog]  has joined #ubuntu-installer
=== Topic for #ubuntu-installer: Development of d-i and ubiquity in Ubuntu | http://wiki.ubuntu.com/InstallerDevelopment
=== Topic (#ubuntu-installer): set by cjwatson at Fri Jan  5 15:12:40 2007
=== xivulon looking at storm... cool stuff
=== cr3 [n=cr3@modemcable178.77-70-69.static.videotron.ca]  has joined #ubuntu-installer
[03:58] <CIA-18> oem-config: cjwatson * r376 oem-config/debian/ (59 files in 2 dirs): * Update translations from Rosetta.
[04:03] <CIA-18> ubiquity: superm1 * r2348 ubiquity/scripts/install.py: revert patch from mvo
[04:04] <CIA-18> ubiquity: superm1 * r2349 ubiquity/debian/changelog: cleanup changelog entry from reverted patch
[04:08] <CIA-18> oem-config: cjwatson * r377 oem-config/debian/changelog: releasing version 1.23
[04:17] <cjwatson> ow, those locale hacks in the mythbuntu_apply component are badly broken
[04:17] <cjwatson> they affect the entire frontend process
[04:18] <cjwatson> oh well, it's your problem I guess
[04:19] <CIA-18> ubiquity: cjwatson * r2350 ubiquity/d-i/manifest: revert broken d-i/manifest change
[04:20] <cjwatson> superm1: we'll upload 1.6.7 with those changes if ubiquity needs to be uploaded for something else, but at this point I don't know of anything
[04:20] <cjwatson> evand: what's happening about that "passwords instead of full names" bug? it's still on the gutsy list
[04:20] <superm1> cjwatson, at this point, we needed something to at least let the install finish.  they are just workarounds for now until there is time to fully investigate them (the locale workarounds)
[04:20] <evand> it's fixed in gutsy and I'm testing my fix for it in Feisty
[04:21] <cjwatson> evand: the bug is still open in gutsy; can you update the status so that it gets off the RMs' radar?
[04:21] <superm1> cjwatson, well since you'd prefer to keep mvo's patch just for us for now, we'll go off PPA for the rest of the gutsy cycle, so no rush on our end
[04:21] <evand> cjwatson: will do
[04:21] <cjwatson> superm1: ok
[04:22] <cjwatson> superm1: sorry for the awkwardness, but at this point I think most known ubiquity bugs are better than unknown ones :)
[04:22] <cjwatson> evand: ah, the bug didn't get auto-closed by your m-a upload because there wasn't a migration-assistant task open on the bug
[04:23] <superm1> cjwatson, i agree.  i'd rather not break all of the normal live cd install from our project.  its a good thing that we are still building the cds ourselves for now since we have support to add the PPA into the builds
=== cjwatson nods
[04:23] <cjwatson> it'd be sort of cool for that to be possible for datacentre CD builds (though not those for the main flavours, obviously)
[04:24] <superm1> but during the next cycle, i'd like to explore the proper way to add us to the cd build process and sort the rest of that out
[04:24] <cjwatson> superm1: will you be at UDS?
[04:24] <superm1> cjwatson, yeah
[04:24] <superm1> all week
[04:24] <cjwatson> superm1: I already need to sit down with the Ubuntu Studio folks, so might be good if you joined in too
[04:24] <cjwatson> though my schedule is likely to be tight, so we'll see what we can do
[04:25] <superm1> cjwatson, yeah, just let me know when you'd like to
[04:25] <superm1> i haven't even started to look at a list of sessions or anything, so i'm open right now
[05:48] <evand> ugh, there doesn't seem to be any way to save state in migration-assistant in ubiquity.
[05:48] <evand> as it needs to run every time, filling in the questions as it goes, to discover what its options are
[05:48] <cjwatson> evand: could you look at bug 149473, please? it got reopened with another problem that seems to be valid
[05:48] <evand> will do
[05:49] <cjwatson> thanks
[05:50] <cjwatson> evand: (if a workaround is possible, that would be fine at this point)
[05:50] <cjwatson> (and in fact preferable)
[05:51] <evand> for noninteractive?
[05:51] <cjwatson> yeah
=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-installer
[07:12] <evand> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/152044
[07:13] <evand> ...
[07:13] <evand> I'm not sure if they're trying to point out a documentation bug or if they're just playing with LP.
=== stgraber [n=stgraber@dakara.stgraber.org]  has joined #ubuntu-installer
[08:38] <cjwatson_> evand: we get a bunch of weird bugs like that; I don't know if it's spam or what - though the attachment is new
[08:38] <cjwatson_> I've rejected it anyway
[08:45] <evand> ok
[09:18] <evand> cjwatson_: I have a solution to saving state in m-a in ubiquity, but I think it's too big of a change for Gutsy.  I'll commit a fix for bug 151126 that just drops the user changes on m-a when going back to its page, and merge with my hardy branch when gutsy is released.  That is, if you think this sounds reasonable.
[09:19] <evand> To give a little background to that, m-a used to save state in ubiquity by leaving the page as is if it had already been run, but this obviously doesn't work as the user could go back to the partitioning page and say, "format everything."