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