[00:55] <CIA-33> ubiquity: cjwatson * r3538 ubiquity/ (debian/changelog partman/check.d/partition_too_small):
[00:55] <CIA-33> ubiquity: Skip partition_too_small check during Wubi installs, as Wubi does some
[00:55] <CIA-33> ubiquity: of its own checks and the delay imposed by this check looks particularly
[00:55] <CIA-33> ubiquity: weird in Wubi. This may or may not be the cause of apparent hangs
[00:55] <CIA-33> ubiquity: towards the end of partitioning, but I suspect that it will at least get
[00:55] <CIA-33> ubiquity: rid of some conflated reports and make testing quicker.
[01:07] <CIA-33> ubiquity: cjwatson * r3539 ubiquity/ (155 files in 3 dirs): Update translations from Launchpad.
[01:20] <CIA-33> ubiquity: cjwatson * r3540 ubiquity/ (d-i/manifest debian/changelog):
[01:20] <CIA-33> ubiquity: Automatic update of included source packages: clock-setup 0.98ubuntu3,
[01:20] <CIA-33> ubiquity: flash-kernel 2.13ubuntu13, grub-installer 1.43ubuntu6, partman-auto
[01:20] <CIA-33> ubiquity: 89ubuntu2, partman-target 64ubuntu4.
[01:43] <CIA-33> ubiquity: cjwatson * r3541 ubiquity/debian/changelog: releasing version 2.0.1
[10:08] <ogra> cjwatson, for your entertainment :) https://wiki.ubuntu.com/ARM/BabbageHeadlessKarmicDesktopInstall
[10:12] <cjwatson> nice
[10:21] <xivulon> cjwatson in /bin/partman I have that PARTMAN_NO_COMMIT=1
[10:21] <xivulon> not sure where that is set, but that makes partman exit, is that normal?
[10:22] <xivulon> ps mounting /host probably is orthogonal, was some spurious reboot-makes-it-work thing
[10:23] <xivulon> have to go, hope the above helps
[10:24] <xivulon> evand ^
[10:25] <cjwatson> sigh, I can't conduct a conversation when people join and quit like that :-/
[10:33] <ogra> cjwatson, i see bug 360925 returning on the imx51 vfat alternate images, intrestingly i can rename the file on the mounted vfat image from d-i's shell
[10:35] <ogra> cjwatson, which makes me think we miss something at image build time here
[10:52] <TheMuso> cjwatson: Looks like the hang with formatting filesystems using parted_server is another weird powerpc gcc bug. I am just double checking, but it seems if I build parted_server/partman-base with -O2 for powerpc instead of -Os, thigns work fine.
[10:53] <cjwatson> aha
[10:53] <cjwatson> I'd never have found that, glad you did
[10:53] <cjwatson> happy to change that for post-RC, I think
[10:53] <TheMuso> Right. I am checking with a live CD, but want to check with alternates as well.
[10:53] <TheMuso> s/alternates/altnerate
[10:54] <cjwatson> remind me of the bug number?
[10:54] <TheMuso> one sec
[10:55] <cjwatson> if you can make sure a gcc bug is filed as well, I'd appreciate it
[10:55] <cjwatson> with preprocessed source
[10:55] <TheMuso> Ok, against which source gcc package?
[10:55] <TheMuso> its bug 450214
[10:55] <cjwatson> gcc-4.4
[10:56] <TheMuso> Ok./ Whats the easiest way to get pre-processed source?
[10:56] <cjwatson> build the package, copy and paste the gcc line that builds the relevant program, delete -c and -o parted_server, add -E
[10:57] <cjwatson> the gcc people will need to know where the hang is though ...
[10:57] <TheMuso> Ok, will confirm everything, and fix up bugs. Shall I open a task against gcc-4.4 on the same bug, or should I open a fresh bug?
[10:57] <cjwatson> so it's just partman-base that needs to be rebuilt, not parted as well?
[10:57] <TheMuso> I would think another task is ok
[10:57] <cjwatson> opening a task is fine, I think
[10:58] <TheMuso> This is what I am checking. I am booting avanilla live CD, copying rebuilt partman-base binaries in, and seeing what happens.
[10:58] <cjwatson> it could of course still be a parted_server bug that optimisation changes just happen to trigger
[10:58] <TheMuso> Right.
[10:59] <CIA-33> partman-base: cjwatson * r170 ubuntu/ (Makefile debian/changelog):
[10:59] <CIA-33> partman-base: Build with -O2 on powerpc to avoid a suspected toolchain bug
[10:59] <CIA-33> partman-base: (LP: #450214).
[10:59] <cjwatson> BTW timer "exceptions" aren't really exceptions, they're just the way parted progress information is propagated up
[10:59] <TheMuso> Right
[11:08] <TheMuso> Looking at the build logs, libparted is built with -O2 anyway.
[11:13] <TheMuso> Ok, with ubiquity/live CD with rebuilt partman-base binaries copied in, -O2 is allowing things to function as normal. I think we can go on this, but I'm going to check with the alternate just to be safe, since libparted is in udeb form and built differently.
[11:16] <TheMuso> I think I already mentioned in the bug where the hang occurred. If built with -Os, the hang occurs when calling ped_timer_new from a parted_server function, can't remember which one from the top of my head.
[11:25] <cjwatson> ok, won't upload straight away anyway, and I think there may be one more partman-base change we need
[11:25] <cjwatson> evand: did you get anywhere with that parted_server syslogging work?
[11:26] <TheMuso> Yeah of course.
[11:26] <evand> cjwatson: no, I was having some trouble with it and temporarily moved on to other bugs.
[11:27] <TheMuso> re not uploading, due to RC and its ports after all.
[11:28] <cjwatson> evand: shout if you need a hand ...
[11:28] <cjwatson> xivulon: PARTMAN_NO_COMMIT=1 is entirely normal
[11:29] <cjwatson> partman is divided into two phases in ubiquity; parted_server stays running between them
[11:29] <evand> will do; I'll have another look as soon as I've got these kde issues sorted out
[11:29] <cjwatson> evand: I was wondering if there's an outside chance that it's causing occasional wubi hangs, you see
[11:30] <evand> ah, noted.  Priority bumped.
[11:30] <cjwatson> since at least some of those have been in the partman-commit phase too
[11:30] <xivulon> well the first stage completes successfully I have no tracback on stage 2
[11:31] <xivulon> will try to get something tonight
[11:33] <xivulon> No partman or any other shell script in /lib/partman is called after that as far as I can see
[11:36] <ogra> cjwatson, bah, my funny remote install fails in UserSetupApply
[11:37] <cjwatson> ogra: you might need to take some care with the user id
[11:37] <ogra> well
[11:37] <cjwatson> ogra: note that casper is very deliberately created at uid 999
[11:37] <ogra> its not actually a supported way of installation anyway
[11:37] <cjwatson> use 998 :)
[11:37] <ogra> hmm
[11:38] <cjwatson> or actually, why not just set a password for the ubuntu user?
[11:38] <cjwatson> and ssh in as that
[11:38] <ogra> oh, right
[11:38]  * ogra tries that 
[11:41] <TheMuso> cjwatson: Ok parted_server manages to format a swap partition, however I think mke2fs is choaking in a similar way to parted_server, which makes me think that, once again, the e2fsprogs udeb is built with -Os for powerpc.
[11:41] <TheMuso> this is on the alternate
[11:44] <cjwatson> yes, see BF_CCOPTS in e2fsprogs/debian/rules
[11:47] <TheMuso> yep just found that myself
[11:49]  * TheMuso rebuilds with -O2 to see if there is a difference.
[12:04] <CIA-33> ubiquity: evand * r3542 ubiquity/ (2 files in 2 dirs):
[12:04] <CIA-33> ubiquity: Properly set the size of the partition to be created upon resizing
[12:04] <CIA-33> ubiquity: in the KDE frontend (LP: #455580).
[12:09] <TheMuso> cjwatson: ok rebuilding e2fsckprogs-udeb with -O2 has things working
[12:13] <cjwatson> ok, I'll add an e2fsprogs task to that bug
[12:21] <TheMuso> Ok. I'll get some pre-processes source for parted_server.c at least.
[12:23] <evand> davmor2: updated bug 455653 requesting some details from you.
[12:24] <davmor2> evand: both but I'll be running checks on kubuntu shortly so I'll double check on that one for you
[12:24] <evand> okay
[12:25] <evand> for what it's worth, I cannot reproduce it in 20091019.2
[12:32] <TheMuso> cjwatson: Ok I'll do other alternate tests tomorrow night for a few other common install cases, just to ensure we catch as much as possible. I suspect this happens with anything dealin with disks, so lvm, cryptsetup etc probably need checking.
[12:34] <cjwatson> ok, thanks
[12:38] <CIA-33> ubiquity: evand * r3543 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[12:38] <CIA-33> ubiquity: Hide the encrypt home radio button in the KDE frontend when in oem-config
[12:38] <CIA-33> ubiquity: mode (LP: #455479).
[14:24] <CIA-33> ubiquity: cjwatson * r3544 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[14:24] <CIA-33> ubiquity: KDE frontend: Fix incorrect error message when the slideshow doesn't
[14:24] <CIA-33> ubiquity: exist.
[14:51] <evand> cjwatson: anything else you want to land in trunk before I do an upload?
[14:54] <cjwatson> evand: go for it, anything I discover with wubi is going to take a while
[14:55] <evand> incidentally, I've run headfirst into the "Try (hd0,0): NTFS5:" issue on the test install I've been running in the background.
[14:57] <evand> perhaps I'm forgetting a bit of history, but it seems odd that we set ubiquity/reboot to true in wubi.  Of course usability issues are for a different time in the cycle. :)
[14:57] <cjwatson> try finding the top-level grub config file in the ntfs filesystem and putting 'set debug=all' at the top of it
[14:58] <evand> will do
[15:35] <evand> cjwatson: for what it's worth, http://people.canonical.com/~evand/tmp/wubi-failure-2.png
[15:49] <ogra> wow, my remote install which i started 6h ago on my babbage board finbally finished ...
[15:49] <ogra> package removal did crawl ... took several hours
[15:53] <evand> interesting.  Wait long enough and it boots, which I think is in line with what davmor2 was experiencing.
[15:54] <evand> and it boots fine every time now.  argh.
[16:25] <CIA-33> ubiquity: evand * r3545 ubiquity/debian/changelog: releasing version 2.0.2
[16:45] <davmor2> evand: we went out for 2 hours the last time I had that issue and it hadn't started how long is a long time?
[16:46] <evand> ten minutes or so
[16:46] <evand> perhaps it was just a sufficient number of reboots / mounts
[16:46] <cjwatson> davmor2: reproduced this under strace, digging ...
[16:47] <cjwatson> (not that it's immediately illuminating, but)
[16:55] <cjwatson> without a doubt, something else is asynchronously opening stopfifo, and I'm pretty sure it isn't ubiquity
[16:56] <cjwatson> my suspicions are drifting back in the direction of sreadahead, so I'm going to give that a try
[17:09] <evand> not sure if it's just as a result of me rebooting a third time, but diverting /sbin/readahead fixed the hangs I was getting in partman.
[17:12] <cjwatson> it's working well for me, though I removed /etc/init/sreadahead.conf
[17:12] <cjwatson> so far, anyway
[17:13] <cjwatson> Keybuk's comments on #ubuntu-release filled in the gaps of understanding I had on how sreadahead might be breaking it
[17:13] <cjwatson> (you mean /sbin/sreadahead?)
[17:14] <evand> err yes
[17:14]  * evand reads up
[17:15] <cjwatson> 4/4 successful so far (I rebooted once it got to "Calculating files to skip copying")
[17:16] <cjwatson> now to try without strace, which will be faster
[17:20] <cjwatson> oh, and FWIW, ghastly rune for arranging to strace both parted_server and partman-commit was to put this in /scripts/casper-bottom/25configure_init in the initrd:
[17:20] <cjwatson> sed -i "s/return ('\/bin\/partman-commit'/import subprocess; subprocess.Popen(['strace', '-f', '-o', '\/tmp\/parted_server.trace', '-s', '1024', '-tt', '-p', subprocess.Popen(['pidof', 'parted_server'], stdout=subprocess.PIPE).communicate()[0].strip()]); return (['strace', '-f', '-o', '\/tmp\/partman-commit.trace', '-s', '1024', '-tt', '\/bin\/partman-commit']/" /root/usr/lib/ubiquity/ubiquity/components/partman_commit.py
[17:32] <CIA-33> casper: cjwatson * r720 trunk/ (debian/changelog scripts/casper-bottom/25configure_init):
[17:32] <CIA-33> casper: scripts/casper-bottom/25configure_init: Disable sreadahead on live CD
[17:32] <CIA-33> casper: boot. Not only does it profile the live CD boot to no benefit, but it
[17:32] <CIA-33> casper: also looks as if it may be responsible for breaking Wubi installs by
[17:32] <CIA-33> casper: reading from partman's synchronisation FIFOs (LP: #439279).
[17:33] <CIA-33> casper: cjwatson * r721 trunk/debian/changelog: releasing version 1.205
[17:36] <davmor2> cjwatson: will you back online latter I'll let you know how I get on with the new cds
[17:38] <cjwatson> I'll be off IRC for a couple of hours, then probably back later in the evening ('cos my life is so exciting)
[17:39] <davmor2> I don't know what you mean I'll be burning and testing cd's till midnightish
[17:40] <cjwatson> hah
[17:40] <cjwatson> hopefully this lot will be a bit more rewarding, wubi-wise
[17:42] <davmor2> \o/
[17:45] <cjwatson> and there we go, rebooted fine for me
[21:29] <xivulon_> Hi colin, noticed you fixed 439279 thanks a lot
[21:30] <davmor2> xivulon_: Just got to wait for the iso's to test it out fully now :)
[21:30] <xivulon_> yep!
[21:31]  * davmor2 is looking forward to a fully functioning wubi :)
[21:31] <xivulon_> Well actually I can test now with break=init + sed
[21:33] <xivulon_> I do think I tried to kill sreadahead in the past (as per colin suggestion), hmm
[21:34] <xivulon_> but that was definitely after chroot...
[21:34] <davmor2> xivulon_: yeah so did I but it was also held up by something just before it.
[21:35] <davmor2> xivulon_: cjwatson solved that one and this one was left
[21:36] <xivulon_> ah cool
[21:38] <davmor2> xivulon_: he tried it about 8 times before he had to shoot off.  So he is hoping that that it is now :)
[21:39] <davmor2> xivulon_: I think evand had a success doing the same thing too (but I could be wrong)
[21:48] <xivulon_> my karmic kvm jams randomly by the way
[22:03] <xivulon_> sedded 25configure_init, and did a full installation, the installer is way beyond the point where it usually jams
[22:04] <xivulon_> fingers crossed
[22:08] <xivulon_> of course I used break=mount not break=init
[22:30] <xivulon_> :) works here
[22:31] <xivulon_> cjwatson you get a bottle of champagne or a box of coffee at your choice
[22:31] <xivulon_> ^ that is real coffee, not the dark stuff I see you guys drinking...
[23:19] <cjwatson> xivulon_: hooray for workingness. I think this was probably the core of the problem all along, but there were some other random problems as well that were masking it
[23:21] <xivulon_> was a close one... fantastic job, as usual
[23:22] <xivulon_> well at least I know a bit more about partman :P
[23:22] <cjwatson> hard work tracking it down today, was still a guess in the end
[23:22] <cjwatson> couldn't actually catch the whole thing in the act except by stracing the *entire system* somehow ;-)
[23:22] <cjwatson> which didn't sound like much fun
[23:23] <xivulon_> guess have to top up my offer
[23:23] <cjwatson> hmm, thinking about it I suppose I could have inserted an lsof call into parted_server or similar, but meh
[23:23] <cjwatson> meh, it's my job :)
[23:23] <cjwatson> will you be at the release party?
[23:23] <xivulon_> most likely yes
[23:24] <cjwatson> I think I will be - have to take the dog to be neutered the next morning, but can probably stay for a short while
[23:24] <xivulon_> hope to see you there!
[23:44] <davmor2> cjwatson: bug 456776
[23:45] <davmor2> cjwatson: I've asked fader_ to confirm asap
[23:49] <davmor2> cjwatson: anything else you want on that bug before I sod off to bed?
[23:50] <davmor2> this is an install against karmic, I don't know if that is relevant
[23:51] <cjwatson> so you did one install on sda1 (/) sda5 (swap), then another install on sda6 (/) sda7 (swap), and only the second showed up in grub.cfg?
[23:51] <cjwatson> os-prober found it, at least, I can see that much in the log
[23:51] <davmor2> cjwatson: looks that way yes unless I'm completely mis-reading it
[23:52] <cjwatson> I wonder if it then completely failed to parse grub.cfg
[23:53] <cjwatson> ... no, it's producing result: lines there
[23:54] <davmor2> cjwatson: there are only 4 lines showing up on the menu.  Current kernel, current kernel rescue and the 2 memtests
[23:56] <cjwatson> yeah, can see that in the generated grub.cfg
[23:56] <cjwatson> nothing obviously wrong, guess I'll have to try to reproduce this - shouldn't need anything else from you right now, thanks
[23:56] <davmor2> cjwatson: Cool nn