[09:47] <CIA-3> ubiquity-slideshow-ubuntu: evand * r230 ubiquity-slideshow-ubuntu/ (4 files in 3 dirs): Use the official Firefox icon, rather than a generic browser icon.
[11:36] <CIA-3> usb-creator: evand * r281 usb-creator/ (3 files in 3 dirs): More unmounting with usb-creator-helper instead of umount as the regular user.
[11:45] <CIA-3> ubiquity-slideshow-ubuntu: evand * r231 ubiquity-slideshow-ubuntu/ (39 files in 4 dirs): Updated slideshow for Kubuntu installer.
[11:46] <CIA-3> ubiquity-slideshow-ubuntu: evand * r232 ubiquity-slideshow-ubuntu/debian/changelog: LP bug reference for previous commit.
[11:50] <CIA-3> ubiquity: evand * r3944 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[11:50] <CIA-3> ubiquity: In the KDE frontend, call reboot with root privileges and try
[11:50] <CIA-3> ubiquity: rebooting via dbus only if a KDE dbus session exists (LP: #540856).
[12:20] <CIA-3> console-setup: cjwatson * r139 ubuntu/debian/ (changelog console-setup.postinst):
[12:20] <CIA-3> console-setup: Don't try to call update-rc.d if it doesn't exist, such as in d-i
[12:20] <CIA-3> console-setup: (LP: #540835).
[12:27] <CIA-3> ubiquity: cjwatson * r3945 ubiquity/ (d-i/make-keyboard-names debian/changelog): merge lucid-beta-1
[12:48] <cjwatson> def record_removed(pkgs, recursive=False):
[12:48] <cjwatson>     """Record which packages we've like removed later"""
[12:48] <cjwatson> what is this, sweet valley high?
[12:55] <ev> like totally
[13:03] <CIA-3> ubiquity: cjwatson * r3946 ubiquity/ (debian/changelog scripts/install.py):
[13:03] <CIA-3> ubiquity: If pkgsel/install-language-support is set to false, then don't install
[13:03] <CIA-3> ubiquity: new language packs from the network, but nevertheless keep any language
[13:03] <CIA-3> ubiquity: packs that are in the live filesystem (LP: #540878).
[13:03] <cjwatson> superm1: ^- this is a semantic correction to your change in r3682.1.24.  Could you please check that it still provides what you need for Mythbuntu?
[13:28] <CIA-3> ubiquity: cjwatson * r3947 ubiquity/ (debian/changelog ubiquity/components/ubi-usersetup.py): Install oem-config-kde in the KDE user-setup plugin (LP: #540895).
[13:52] <CIA-3> ubiquity: superm1 * r3948 ubiquity/ (debian/changelog scripts/install.py): Don't delete the cache too early in select_language_packs.
[14:06] <superm1> cjwatson, looks sane after that fix ^
[15:11] <_ruben> any ideas/tips on how to go about installing a new system with nilfs on a ssd?
[15:18] <cjwatson> superm1: whoops.  thanks
[15:33] <cr3> ev: hey dude, bug #534605 seems to be fixed released as of today (or maybe yesterday). can I mark it as such?
[15:34] <ev> cr3:  hooray, cjwatson's fix must have worked.  By all means, close it.
[15:34] <cr3> ev: awesome, I'll assign it to him so that he gets all the heroic credit :)
[15:35] <ev> heh
[16:20] <shtylman> ev: ever run valgrind on ubiquity?
[16:21] <shtylman> im trying to figure out this 100% cpu problem on the qt side
[16:27] <ev> shtylman: I was playing around with a few of the profiling tools the other day
[16:28] <shtylman> my first step is trying to figure out what the thing to actually run is... something that doesn't exec anything else
[16:29] <shtylman> cause im not sure if the tools can handle exec
[16:29] <ev> sudo python -m cProfile -o stat.prof /usr/lib/ubiquity/bin/ubiquity; sudo gprof2dot -f gprof stat.prof | dot -Tpng -o output.png
[16:30] <ev> I needed to install some packages from multiverse, but I cannot remember what exactly
[16:30] <shtylman> k
[16:31] <ev> that wont be incredibly helpful though, as it's just going to tell you its spending most of its time in the kde event loop
[16:31] <ev> which is fairly obvious
[16:31] <shtylman> great :/
[16:31] <ev> strace is also usually helpful here, but from what I saw it wasn't doing anything crazy
[16:32] <ev> just the usual communication with debconf
[16:32] <shtylman> is there maybe a missing blocking call or something?
[16:32] <shtylman> is it polling instead of waiting?
[16:32] <ev> the first step, which I completely neglected, would be to see if this happens in karmic
[16:35] <shtylman> when you say it was speding its time in the kde event loop... was there a function that was called an abnormal number of times?
[16:36] <shtylman> like if you let it sit there (minimized even)
[16:36] <ev> I don't recall
[16:36] <shtylman> what is the #1 called function in terms of time..
[16:36] <shtylman> k
[16:36] <ev> sorry, I should have saved the chart, but I assumed it was worthless at the time
[16:36] <shtylman> no biggie
[16:38] <cjwatson> not sure valgrind will give you useful answers for a python program
[16:38] <cjwatson> (unfortunately)
[16:39] <cjwatson> ev: there was a design-team bug somewhere about us giving an excessive partitioning warning when there wasn't anything there before to overwrite, wasn't there?  I was thinking of something like http://paste.ubuntu.com/397334/
[16:39] <ev> there was indeed
[16:39]  * ev reads
[16:39] <cjwatson> packages from multiverse> python-profiler at least, probably
[16:42] <cjwatson> ev: it'd need a couple of tweaks elsewhere (ubiquity, kickseed, installation-guide) to deal with preseeding requirements for the new template, but no biggie
[16:42] <ev> cjwatson: looks good!
[16:43] <cjwatson> I'd probably better test it a bit ;-)
[16:44] <CIA-3> usb-creator: evand * r282 usb-creator/ (4 files in 4 dirs): Handle device changes by synthesizing a remove and add.
[16:45] <ev> nah, it's only beta 1, that's what the users are for :-P
[16:45]  * ev looks into pitchfork and torch insurance
[16:45] <shtylman> haha
[16:45] <shtylman> ev where did you find gprof2dot .. the one I got from google code doesn't support -f gprof
[16:45] <ev> I think I downloaded that one from the tubes
[16:45] <shtylman> and with -f prof it says unexpected end of file
[16:46] <shtylman> I guess my tubes are tainted ... O.o
[16:46] <ev> I suspect you have the wrong arguments
[16:46] <ev> gprof2dot.py --help :)
[16:46] <ev> I think it's something like gprof2dot.py -f gprof inputfile.ext, but I could be very wrong
[16:47] <shtylman> yea... that is what I do.. but thats the thing ... the -f gprof format isn't supported
[16:47] <shtylman> only the basic 'prof' format
[16:47] <ev> ohh, sorry, I misread
[16:48] <ev> it's prof
[16:48] <shtylman> well then
[16:48] <shtylman> now the unexpected end of file... is upsetting
[16:48] <ev> err pstats
[16:48] <ev> sorry
[16:48] <ev> brain fail
[16:48] <shtylman> haha
[16:48] <shtylman> that works :)
[16:48] <shtylman> thx
[16:49] <ev> hrmm, can't reproduce the installing a package before running oem-config crashes it bug in regular ubuntu
[16:49] <ev> bug 539710, that is
[16:51] <ev> oh
[16:51] <ev> Mar 16 16:49:35 oem-laptop ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
[16:53] <cjwatson> isn't there an existing bug about lack of passthrough or something?
[16:53] <shtylman> ev: it appears that it keeps calling filtered commands or something which in turn keeps calling run_main_loop
[16:53] <cjwatson> ogra filed something
[16:53]  * ogra looks up
[16:54] <ogra> about passthrough ? i dont think i did, at least not in lucid
[16:54] <cjwatson> never mind then
[16:54] <ev> no, he did
[16:54] <ogra> i did ?
[16:55] <ogra> i filed a ton of oem-config bugs but cant remember filing one for passthrough
[16:55]  * ogra digs in bugmail
[16:56] <ev> ‏‎‏‎bug 530027
[16:56] <ev> cjwatson: ^ is that what you were referring to?
[16:58] <ogra> ah, that might be it, but the debconf frontend is set to noninteractive in my case
[16:58] <ogra> err
[16:58] <ogra> no, only while oem-config is installed ... i'm talking rubbish
[16:59] <ev> shtylman: that is the normal flow of execution
[16:59] <cjwatson> that might have been what I meant
[17:00] <shtylman> ev: right... but shouldn't the watch_debconf_fd_helper_read block or something?
[17:00] <shtylman> it just seems (by the graph) that it isn't
[17:00] <shtylman> so the loop basically becomes a tight loop
[17:00] <shtylman> and eats cpu
[17:03] <ev> shtylman: a higher level library (gobject io_watch or QSocketNotifier) tells it when there's data to read.
[17:03] <shtylman> gotcha
[17:04] <cjwatson> damn, I wish the KDE frontend had useful keyboard navigation
[17:05] <shtylman> cjwatson: :p
[17:05] <shtylman> define useful
[17:05] <cjwatson> hit enter to go forward
[17:05] <shtylman> hmm... does it not do that?
[17:05] <shtylman> I guess cause next isn't selected
[17:05] <cjwatson> nope, there's been a bug about it for about three years :)
[17:05] <shtylman> haha
[17:05] <shtylman> but what if you hit enter in an input field?
[17:06] <shtylman> wouldn't that want to go to the next page?
[17:06] <cjwatson> maybe it works in some cases, it just doesn't work reliably enough (no input fields on most pages)
[17:06] <cjwatson> by the time I reach user-setup I've given up and am using the mouse anyway
[17:06] <shtylman> heh
[17:08] <shtylman> how does it work on the gtk side when you hit enter in an input field?
[17:08] <shtylman> I guess thats sorta like an online form... where hitting enter submits
[17:10]  * ev just keeps hitting alt-f
[17:10] <shtylman> I like to make life difficult for yall ... maybe in the next version I will have the page order be random... that wouls spice things up...
[17:10] <ev> thought enter in the gtk frontend works nicely
[17:10] <ev> though*
[17:12] <ev> shtylman: I know where you live (down to the degree of a few million people's residences) ;)
[17:13] <shtylman> hahaha
[17:47] <shtylman> ev: line 1231 of kde_ui
[17:48] <shtylman> the call to processEvents should be processEvents(QEventLoop.WaitForMoreEvents)
[17:48] <shtylman> imho
[17:48] <shtylman> then it no longer uses 100% cpu
[17:48] <shtylman> cause the call puts the process to sleep basically
[17:48] <ev> shtylman: and you've tested this?
[17:49] <shtylman> ev: yes... but I would use the word "tested" loosely
[17:49] <ev> you've patched it in and run through the installer?
[17:49] <shtylman> I made the change... I can run ubiquity... but I have not done a full install.. only went through a few pages
[17:49] <ev> beautiful
[17:49] <ev> I owe you a beer/coke/prized pig
[17:50] <shtylman> it deff should be tested more.. .cause what this change does mean is that another process cannot cause the loop to end just by setting self.mainLoopRunning = false
[17:50] <shtylman> it would have to wait until the next interation of that loop
[17:50] <shtylman> which may or may not be a problem depending on how the system expects that loop to behave
[17:54] <ev> indeed
[18:00] <cjwatson> KDE: this is odd, oem-config has finished but X is staying there
[18:00] <ev> cjwatson: did you see my recent fix?
[18:00] <ev> perhaps it's the same thing
[18:00] <ev> oh, oem-config
[18:00] <ev> nevermind
[18:00] <cjwatson> yeah, shouldn't be rebooting
[18:00] <ev> right
[18:07] <ev> pyflakes.vim is pretty nice, if you're not already using it
[18:08] <ev> it doesn't catch everything, but every now and again it stops me from doing something stupid
[18:12] <cjwatson> I'm not yet, been meaning to since james_w mentioned it
[18:14] <ev> indeed, that's what got me on it :)
[18:14] <ev> constantly looking for things to improve my python development
[18:14] <cjwatson> is it packaged?
[18:15] <ev> not that I know of
[18:19] <shtylman> I improve my python development by using a compiled language :p
[18:21] <ev> hardy har har
[18:22] <ev> most of these things apply to all languages
[18:22] <ev> code completion, syntax checking, ...
[18:25] <shtylman> ev: any more action on the 100% cpu bug? will you be commiting the change or doing any more testing?
[18:25] <ev> shtylman: by all means commit it to trunk
[18:26] <ev> so I can find you in bzr blame when it breaks ;)
[18:26] <shtylman> ev: :)
[18:29]  * ev heads home
[18:35] <superm1> ev re bug 539710, if you don't have network access during oem-config-firstboot perhaps. the packages would be in the apt cache, but not really installable since they need to come from the tubes
[18:38] <CIA-3> ubiquity: cjwatson * r3949 ubiquity/ (32 files in 8 dirs): remove trailing whitespace (and trailing semicolons in Python code); the red highlights and inability to use paragraph motions in vim were annoying me
[19:02] <cjwatson> I'm seriously tempted to run xlsclients at the end of ubiquity-dm and kill anything that's left over
[19:03] <superm1> either that or just make sure the X server pid is killed at the end of ubiquity-dm
[19:06] <superm1> it's certainly sticking around after a 'stop oem-config'
[20:18] <cjwatson> superm1: except we already try to do that
[20:26] <cjwatson> why it's not working, I'm not sure - we even wait() for it
[20:30]  * cjwatson straces
[20:48] <cjwatson> oh, doh, looks like we never break out after the main server succeeds, and fall through to failsafe instead
[20:48] <ev> hrm, any objection to moving source_ubiquity.py into the apport package, so that it can be used post-install
[20:48] <ev> assuming pitti approves, of course
[20:49] <cjwatson> ok by me
[20:49] <cjwatson> same principle as d-i being there
[20:49] <cjwatson> incidentally, I love the fact that kvm-nbd exists
[20:49] <cjwatson> that plus things like 'kvm-img create -f qcow2 -o backing_file=v.img v2.img' makes it tolerable to hack on oem-config
[20:49] <ev> nice!
[20:50] <ev> *cough* https://wiki.ubuntu.com/Installer/Development/Tips ;)
[20:50] <cjwatson> point :)
[20:50] <cjwatson> of course all of this is a workaround for shift-to-grub-menu not working inside kvm for some reason
[20:57] <soren> Sorry, what?
[20:57] <soren> Oh, "shift" as in the key?
[20:58] <cjwatson> yes
[20:58] <soren> sdl or vnc frontend?
[20:58] <cjwatson> I think it doesn't set the BIOS key modifier state such that grub can see that the shift key is depressed
[20:58] <cjwatson> sdl
[20:59] <soren> Has it always been this way or is this recent breakage? We changes BIOS in... err... lucid, I think.
[20:59] <soren> Yes, lucid.
[20:59]  * ev gave up on the sdl frontend a while back.  Couldn't deal with the ctrl-alt-left/right bug anymore (assuming it still existed and wasn't just in my head)
[20:59] <cjwatson> soren: I think it was the case in karmic as well.  Before that the requirement to use Shift to get to GRUB didn't exist, so I don't know
[21:00] <soren> Right, ok.
[21:00] <cjwatson> I just find it too annoying to have to VNC in separately, I'm afraid
[21:00] <soren> Not using libvirt then, I take it?
[21:01] <cjwatson> nope.
[21:01] <soren> cjwatson: libvirt also wraps up the vnc connectivity quite nicely with either virt-manager or virt-viewer.
[21:01] <cjwatson> libvirt is not optimised for the case of developing the installer
[21:02] <cjwatson> it was enormously tedious to set it up for that last time I tried, and didn't really seem worth it
[21:02] <soren> I think we talked about this before... Did that talk get turned into bug reports of any sort?
[21:02] <cjwatson> I'm not sure - but kvm's sdl frontend normally meets my needs
[21:02] <cjwatson> I don't like configuring things in xml anyway, sorry :)
[21:03] <soren> Noone does :)
[21:03] <cjwatson> I suspect I wasn't motivated to file a bug because I didn't really have any reason to switch
[21:04]  * soren just checked that just pressing shift (not shift+something else) does result in a key event, so if this is not queryably in the BIOS, it's likely a BIOS bug.
[21:05] <cjwatson> where would I look in kvm (or its dependencies)?
[21:05] <cjwatson> it has its own BIOS source, doesn't it?
[21:06] <cjwatson> GRUB looks at the keyboard modifier flag at 0x417 (in the BIOS Data Area), which is AFAIK the only entirely asynchronous way to query key modifier state
[21:07] <soren> I'm not sure at the moment. It didn't to begin with, then it did, and now I /think/ it doesn't.
[21:07] <cjwatson> an OS wouldn't need that, since it just gets a stream of keyboard events and can maintain its own consistent view of the world
[21:07] <soren> Right, exactly.
[21:07] <soren> So only grub suffers.
[21:07] <soren> Well, and DOS and whatever other funny business people are running in kvm.
[21:08] <cjwatson> hmm, do you mean it uses the system BIOS or something?
[21:08] <cjwatson> (how? :-) )
[21:08] <soren> Nono.
[21:08] <soren> It used to use bochs.
[21:08] <soren> bochsbios, to be exact.
[21:08] <soren> ..so it wasn't in the kvm package, but a separate one.
[21:08] <soren> Now it uses a new BIOS, seabios.
[21:08] <cjwatson> for a while it used seabios and/or vgabios, but now it Conflicts/Replaces those
[21:08] <soren> That's why I was curious if it was new breakage. It could be a regression from bochs.
[21:09] <cjwatson> but I think this is just because the source is borged into kvm
[21:09] <cjwatson> judging from the qemu-kvm 0.12.3-0ubuntu5 changelog
[21:09] <cjwatson> I don't think it's new
[21:09] <cjwatson> or if it is, it's new since pre-karmic
[21:11] <soren> You're right.
[21:11]  * soren wonders where the source is for that blob
[21:12] <CIA-3> ubiquity: evand * r3951 ubiquity/ (4 files in 3 dirs): Remove the apport hook, it lives in Ubuntu's apport package now.
[21:13] <cjwatson> I was wondering the same thing
[21:13] <cjwatson> kirkland: ok, I'm lost now.  What BIOS source are we actually using in kvm, where's its source, and why are there binary blobs in the qemu-kvm package?
[21:13] <soren> cjwatson: I just asked upstream.
[21:15] <soren> cjwatson: I see code in bochsbios to handle this. I don't see it in seabios (but that doesn't mean it's not there).
[21:19] <soren> Ok, I see it in seabios now (the source package in universe). It does seem to be supposed to handle it correctly.
[21:20] <CIA-3> ubiquity: cjwatson * r3952 ubiquity/ (bin/ubiquity-dm debian/changelog):
[21:20] <CIA-3> ubiquity: Don't fall through to the failsafe X server if the main X server
[21:20] <CIA-3> ubiquity: succeeds (LP: #540938).
[21:21] <CIA-3> ubiquity: cjwatson * r3953 ubiquity/debian/ (oem-config.oem-config.upstart ubiquity.ubiquity.upstart): merge lp:~mterry/ubiquity/support-uxlaunch
[21:22] <CIA-3> ubiquity: cjwatson * r3954 ubiquity/debian/changelog: changelog entry for lp:~mterry/ubiquity/support-uxlaunch
[21:23] <kirkland> cjwatson: well, we have seabios in the archive now, but upstream qemu strongly recommended that we use the bios they've blessed and released in 0.12.3
[21:23] <cjwatson> mterry: ^- IMO that was obviously correct, so feel free to commit changes of that kind yourself even though you aren't rotated to platform any more
[21:23] <cjwatson> kirkland: we need to ship source for i t
[21:23] <cjwatson> it
[21:23] <cjwatson> it's not OK to have sourceless binary blobs in main
[21:23] <kirkland> cjwatson: we runtime-depended on seabios for a while, but it caused a few bugs that we couldn't reproduce against upstream
[21:24] <kirkland> cjwatson: agreed, this is an oversight
[21:24] <cjwatson> IMO we should be building it too, and making sure we get the same output from doing so
[21:24] <kirkland> cjwatson: open a bug; i'm onsite at dell today/tomorrow, onsite at eucalyptus all of next week; i'll try to find some time
[21:25] <cjwatson> ok
[21:25] <kirkland> cjwatson: http://pastebin.ubuntu.com/397472/
[21:25] <cjwatson> yep, saw that
[21:26] <cjwatson> I understand the reasons, but we're wildly infringing our own policy here
[21:26] <cjwatson> not to mention infringing copyright on the BIOSes, if this is LGPLed (it is, isn't it?)
[21:26] <kirkland> cjwatson: i'm happy to revert that commit, and reopen https://bugs.edge.launchpad.net/ubuntu/lucid/+source/vgabios/+bug/513273
[21:26] <cjwatson> I'm not asking for us to use vgabios specifically
[21:27] <kirkland> cjwatson: -vga std is low on my wishlist, fwiw
[21:27] <cjwatson> the separate source package or whatever
[21:27] <cjwatson> I'm entirely OK with it being shipped by qemu-kvm if that's considered appropriate, but not as binary blobs - we need to ship the matching source
[21:28] <cjwatson> mind if I just quote this IRC conversation rather than retyping?
[21:28] <kirkland> cjwatson: that's fine
[21:28] <kirkland> cjwatson: i'm just going to revert that change, and reopen the bug
[21:29] <kirkland> cjwatson: that's all i have time to fix right now
[21:29] <kirkland> cjwatson: tell me this though ...
[21:29] <cjwatson> ok, bug 541524.  thanks
[21:38] <soren> kirkland: I remember at some point the qemu source package contained a diff against bochsbios upstream. I put that in the bochsbios source package, and compiled a special bochsbios variant for this.
[21:39] <soren> kirkland: Maybe you could poke anthony to do something similar now.
[21:43] <cjwatson> ev: oh my.  wow.  pyflakes.vim is magic.
[21:43] <ev> cjwatson: :D
[21:43] <CIA-3> ubiquity: cjwatson * r3955 ubiquity/bin/ubiquity: remove duplicate import, caught by pyflakes
[21:43] <ev> it's bloody brilliant, isn't it
[21:44] <cjwatson> I just showed it in action to Kirsten and it impressed her, despite her not being a programmer
[21:44] <cjwatson> normally development tools leave her entirely cold :)
[21:45] <ev> ...umount is returning 1 on success...
[21:45] <ev> hahaha, Kat is mostly impressed that programming involves putting pretty colors on the screen.  Beyond that her eyes glaze over.
[21:49] <soren> cjwatson: There's a pyflakes.vim?
[21:49]  * soren recently discovered pyflakes, too.
[21:49] <soren> It's awesome.
[21:50] <soren> Having it integrated in vim: Priceless.
[21:50] <ev> haha
[21:50] <cjwatson> soren: http://www.vim.org/scripts/script.php?script_id=2441
[21:51] <kirkland> cjwatson: is it good enough for now just to runtime depend on seabios and vgabios to pull in bios.bin and vgabios.bin from that source package?
[21:51] <kirkland> cjwatson: ie, the qemu-kvm source package will still contain the bios.bin blob, but that won't be installed anywhere
[21:52] <kirkland> cjwatson: or do i need to prune the blob from the upstream tarball?
[21:53] <kirkland> cjwatson: or do i need to *add* the seabios source to the upstream tarball?
[21:55] <cjwatson> kirkland: I think we'll still be infringing upon the licence unless you do 2) or 3)
[21:55] <cjwatson> both vgabios and seabios are under (various versions of) the LGPL, which doesn't permit us to ship copies of the binary without source
[21:55] <kirkland> cjwatson: agreed
[21:57] <kirkland> cjwatson: the OpenBIOS, video.x, PXE roms are also a problem, i suppose?
[21:57] <cjwatson> any binary blobs, yes
[21:57] <soren> cjwatson: Yes.
[21:57] <soren> Whoops.
[21:57] <soren> kirkland: Yes.
[21:57] <cjwatson> unless the binary is in fact the preferred form for modification
[21:58] <soren> kirkland: The PXE roms should be provided by the kvm-pxe package.
[21:58] <soren> kirkland: openbios is a long-standing problem.
[21:58] <soren> kirkland: Let me find the bug #.
[22:00] <soren> kirkland: https://bugs.edge.launchpad.net/ubuntu/+source/openbios-sparc/+bug/183495
[22:01]  * soren could have sworn the was another bug to roughly the same effect
[22:01] <soren> Err.. We're wildly off topic for this channel, though :)
[22:02]  * soren is still looking for a good solution to that bug, though.
[22:02] <CIA-3> ubiquity: cjwatson * r3956 ubiquity/debian/ (changelog control): ubiquity-frontend-gtk depends on gksu (LP: #540331).
[22:08] <CIA-3> ubiquity: cjwatson * r3957 ubiquity/ (3 files in 2 dirs): Change .desktop translation domain to ubiquity-desktop (LP: #540936).
[22:12] <davmor2> go for it
[22:13] <cjwatson> set show_panic_message=true
[22:13] <davmor2> this is in grub shell yes?
[22:13] <cjwatson> (er, hang on, just working out the next bit)
[22:13] <cjwatson> yes
[22:14] <cjwatson> search -s -f -n /ubuntu/disks/root.disk
[22:15] <cjwatson> tell me what that says if it gives you any output
[22:15] <davmor2> no output
[22:15] <cjwatson> echo ${root}
[22:16] <cjwatson> [for onlookers: I'm walking through wubi/data/wubildr.cfg]
[22:16] <davmor2> hd0,3 which would be correct
[22:16] <cjwatson> loopback loop0 /ubuntu/disks/root.disk
[22:17] <davmor2> done
[22:17] <cjwatson> set root=(loop0)
[22:17] <davmor2> done
[22:17] <cjwatson> ls /boot
[22:17] <cjwatson> don't bother typing back all the output - I just want to know if it looks roughly right
[22:18] <davmor2> error: unknown filesystem
[22:18] <cjwatson> hmm
[22:18] <cjwatson> well, that would suck then
[22:18] <cjwatson> can you loop-mount that file from a rescue CD?
[22:19] <davmor2> 2 ticks
[22:19] <cjwatson> hm, I have an old wubi installation here, I wonder if grub-emu will reproduce this
[22:20] <cjwatson> nope, works here from grub-emu
[22:21] <cjwatson> so could be specific to particular filesystem layouts, or could be something I've missed
[22:25] <davmor2> cjwatson: whats the filesystem type it won't let me mount it with out it is it ext3/2?
[22:31] <davmor2> ev: what is the filesystem type of root.disk please?
[22:32] <ev> should be ext4
[22:32] <cjwatson> yes
[22:33] <ev> but I'm a bit confused
[22:33] <ev> I thought we weren't past ubiquity yet
[22:34] <davmor2> mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error  In some cases useful info is found in syslog - try dmesg | tail or so
[22:35] <davmor2> ev: no this is from the live cd
[22:35] <cjwatson> oh, this is before ubiquity?  how come there's a root.disk then?
[22:36] <davmor2> cjwatson: Just to check I'm calling this right.  sudo mount -o loop -t ext4 /media/Vista/ubuntu/disks/root.disk disk/
[22:36] <cjwatson> that's right, but ...
[22:36] <ev> cjwatson: sparse file?
[22:36]  * ev tries to recall
[22:36] <cjwatson> is that new behaviour?
[22:37] <cjwatson> not seeing that in wubi ...
[22:37] <ev> perhaps not
[22:37] <ev> indeed
[22:38] <ev> davmor2: can you just clarify, at what point of the install were you at when you hit the bug
[22:39] <ev> had you run through ubiquity yet?
[22:39] <davmor2> nope
[22:39] <davmor2> it had done the windows side of things and would be the reboot into ubiquity
[22:40] <cjwatson> was there a previous wubi install here?
[22:40] <davmor2> cjwatson: no
[22:40] <CIA-3> ubiquity: cjwatson * r3958 ubiquity/ (debian/changelog ubiquity/misc.py):
[22:40] <CIA-3> ubiquity: Report disk sizes in decimal units in the manual partitioner, for
[22:40] <CIA-3> ubiquity: consistency with partman and to abide by the new units policy
[22:40] <CIA-3> ubiquity: (LP: #539653).
[22:42] <davmor2> cjwatson, ev: shall I go back to windows remove this attempt ensure that the ubuntu folder is completely gone and try again?
[22:42] <ev> I'm quite curious to know where this root.disk came fro
[22:42] <ev> m
[22:43] <cjwatson> I think that would be a good idea.  ev?
[22:43] <ev> sure
[22:43] <cjwatson> if mount -t ext4 doesn't like it, then it's probably just blank space or something
[22:43] <cjwatson> if it comes back on another run, then we'll know for sure we have something to look into
[22:44] <davmor2> actually I just thought would it be remnants of a much older version of wubi that didn't remove the folder?
[22:44] <davmor2> ah actually no it can't be cause the newer version do
[22:46] <davmor2> cjwatson: mount: root.disk is not a block devise (maybe try `-o loop'?)
[22:47] <davmor2> I'll go for the wiping thing then and come back to you
[22:50] <cjwatson> sorry, mount -t ext4 was just shorthand for mount -o loop -t ext4 /media/Vista/ubuntu/disks/root.disk disk/, there
[22:51] <cjwatson> ev: bug 539827 looks a bit complicated - the dbfilter might not be running, right?
[22:51] <cjwatson> but presumably we actually need to make sure it starts, and then wait for it to finish
[22:51] <cjwatson> hm, wait, this is odd
[22:52] <davmor2> cjwatson, ev: right I've removed that install and double checked and there is no longer an Ubuntu folder on C:
[22:52] <cjwatson> the report shows that button being clicked after localechooser has *finished*!
[22:52] <ev> yeah, I was a bit confused there
[22:53] <ev> how on earth is this happening?
[22:53] <ev> clever timing on the user's part?
[22:54] <cjwatson> there's a two-minute gap in the log
[22:55] <ev> interesting
[22:55] <cjwatson> oh, that'll be ntp correction won't it
[22:55] <cjwatson> bug 541081 has a one-second gap
[22:55] <ev> incidentally, we probably want to disable the try button once they click install
[22:55] <cjwatson> might not be ntp correction, doesn't add up with rdate's output
[22:56] <ev> as clicking try after install ("oh god, didn't want that") results in badness
[22:56] <cjwatson> yes
[22:56] <cjwatson> bonus points if you can back up from the timezone page and then select try
[22:56] <ev> right, nearly broke that :)
[22:57] <davmor2> right so I have now reinstalled the windows part of wubi and there is a root.disk and swap.disk file in disks again
[23:03] <cjwatson> eeeenteresting
[23:03] <davmor2> rebooted and straight into grub shell again
[23:03] <cjwatson> ah, create_virtual_disks
[23:03] <cjwatson> so - how did this work before? :)
[23:03] <cjwatson> maybe grub happened to not care
[23:03] <ev> damn grep, failing to parse python and all
[23:03] <cjwatson> how about http://paste.ubuntu.com/397508/ ?  might need context to be readable
[23:04] <cjwatson> davmor2: did wubi leave you at a shell after the message "It is not possible to boot from the Ubuntu image." blah blah?
[23:04] <cjwatson> or just a bare grub shell?
[23:07] <davmor2> cjwatson: didn't it just have a magic grub line that made it do something before?
[23:07] <ev> looks reasonable
[23:07] <cjwatson> davmor2: hmm?
[23:07] <davmor2> Gnu Grub version 1.98-1ubuntu1 is the top line
[23:08] <cjwatson> no explanatory text?
[23:08] <davmor2> nope
[23:08] <cjwatson> odd, I wonder why not
[23:22] <davmor2> okay so anything else I can do?
[23:24] <CIA-3> ubiquity: evand * r3959 ubiquity/ (debian/changelog ubiquity/components/ubi-language.py): Don't let the user select both "Try Ubuntu" and "Install Ubuntu".
[23:31] <CIA-3> ubiquity: evand * r3960 ubiquity/ (debian/changelog ubiquity/components/ubi-language.py):
[23:31] <CIA-3> ubiquity: Provide visual feedback for clicking "Try Ubuntu" in the form of a
[23:31] <CIA-3> ubiquity: spinning cursor.
[23:44] <davmor2> cjwatson, ev: I've opened up bug 541607 so I can mark the test a fail and I'm off to bed, I'll try some of the other wubis tomorrow to make sure it's not a freak cd or something.
[23:47] <ev> damn, he left before I could say thanks