[00:02]  * shtylman is thinking it is time to try a clean install of the new alpha...oh this will be failue...I can smell it :)
[01:37] <xivulon1> so I finally been able to do a full installation in my vm...
[01:38] <xivulon1> update-grub has to be fixed slightly but otherwise things seem ok
[01:39] <xivulon1> main issue is that I get almost consistent fs corruption (for the loopfile) at each reboot...
[01:39] <xivulon1> will investigate that in the coming days
[01:40] <xivulon1> also have an error when inserting i915, but should be orthogonal to wubi and I guess you know about it already
[01:40] <xivulon1> cjwatson ^
[01:42] <xivulon1> thanks soren for the kvm tips
[02:46] <shtylman> cjwatson: you around?
[03:14] <shtylman> cjwatson: well...im gonna sleep some...but I am in the middle of an alpha 5 install..actually just need to install grub2 at this point. LP #420992 is stopping me. I am still in the install livecd system and would like to help work on or create a fix for installing grub onto dmraid devices. I can use the debbug patch as a starting point if you can point me in the right direction for which source package to work with (aka...the
[03:14] <shtylman>  source package that does that text-based grub installer) ... thanks and I will see if I can come up with a fix :)
[08:36] <StevenK> evand: Hey! I installed UNR via Wubi and it doesn't boot with "Unable to find a medium containing a live file system"
[08:39] <evand> StevenK: it's my day off, but I have a few minutes.  Can you post the casper.log on pastebin?
[08:40] <StevenK> evand: It has "/init: line 1: can't open /dev/sr0: No medium found"
[08:41]  * StevenK makes sure to select the CD is mounted
[08:42] <evand> select the CD is mounted?  I don't follow.
[08:43] <StevenK> evand: Sorry, I'm fiddling in VirtualBox
[08:43] <evand> it shouldn't need the CD drive at all
[08:43] <evand> it copies the ISO to disk
[08:45] <StevenK> evand: How is a good way to debug this?
[08:47] <evand> StevenK: given that a regular install is working just fine for me, compare what wubi is producing for UNR vs a regular Ubuntu install
[08:48] <evand> make sure the kernel command lines match up and that all the paths exist
[08:48] <davmor2> evand: morning
[08:48] <evand> davmor2: good morning
[08:50] <davmor2> evand: would it be okay to play with wubi on unr today see if we can't get it to work by the end of the day?
[08:50] <evand> davmor2: sure, but I'm not available to help.  Today's my day off and I'm going into town in a few minutes.
[08:50] <StevenK> davmor2: I just tried it, it doesn't boot, but it does install
[08:51] <davmor2> StevenK: Yeah that was the issue I had before
[08:51] <davmor2> evand: okay how about Monday instead then :)
[08:51] <evand> davmor2: sure
[08:51] <davmor2> Be nice to get it working :)
[08:52] <StevenK> davmor2, evand: I'll leave it to you two, then :-)
[08:53] <davmor2> evand: out of interest the grub issue was it in the wubi package?   and did you upload it so I can pull it and try it out.  Or is it still in the works?
[08:53] <evand> davmor2: it'll be on the next CD spin
[08:53] <evand> alternatively you can pull it from http://people.ubuntu.com/~evand/wubi/karmic/
[08:53] <davmor2> evand: Okay cool :)
[08:54] <davmor2> I'll have a play and let you know monday :)
[08:55] <evand> good deal
[08:55] <evand> thanks
[09:04] <cjwatson> shtylman: well, how about I make that the next bug I try to fix?
[09:05] <cjwatson> hmm, I thought somebody said there was a patch for dmraid in the Debian bug, but it's just for multipath AFAICS
[09:07]  * cjwatson breaks out Luke's test dmraid qcow2 images
[09:25] <xivulon> evand, cjwatson left a msg yesterday night ^^
[09:26] <xivulon> have also played a bit with loopback function of grub2
[09:27] <xivulon> I can list the content of the disk image, which is encouraging
[09:27] <xivulon> (using loop   ext2 grub modules)
[09:29] <xivulon> but if I try to access a dir therein e.g. ls (loopdev)/etc => error: out of disk
[09:29] <xivulon> does that sound familiar?
[09:36] <cjwatson> no - I can't reproduce it with a small test image
[09:36] <cjwatson> (using grub-emu)
[09:36] <cjwatson> if there's any way I can reproduce this without a full wubi installation, that would be good
[09:37] <cjwatson> what's the exact text of the error message?
[09:37] <xivulon> "out of disk"
[09:37] <cjwatson> ah, there it is
[09:38] <cjwatson> so that actually means out of range
[09:38] <xivulon> It might be related to the ext4 corruption problem mentioned earlier though, will try again tonight ensuring that I run this on a clean partition
[09:38] <cjwatson> do you know whether LBA is enabled on the containing disk?
[09:39] <yann|work> I narrowed my problem to "apt-get install <task>^" not finding any task, even "minimal"
[09:39] <xivulon> hmm didn't check that
[09:40] <yann|work> strace seems to show that it is looking inside the Package files, unlike tasksel
[09:40] <cjwatson> xivulon: it's more likely to be straightforward filesystem corruption, or a bug in grub2's ext2 code, but it's also possible that it's outside the range it can read with non-LBA accesses
[09:41] <cjwatson> yann|work: it relies on correct Task fields being present in the Packages file; if you regenerated Packages and you weren't careful, you may have broken those
[09:42] <xivulon> cjwatson, will try again tonight and provide more informative feedback
[09:43] <yann|work> cjwatson: I did not touch the original ones, they do have their Task: fields - only the Packages file for my "extra" component does not have those
[09:44] <cjwatson> you might like to use 'apt-cache show util-linux' (as an example) to check that it shows the Task field
[09:46] <yann|work> Ah, it does not show - and apt-cache policy shows that the same version exists in both main and extras - so this is where I shot myself in the foot, my filter does not work
[09:46] <yann|work> cjwatson: thx
[09:47] <xivulon> re LBA, the bios is the stock KVM one
[09:50] <xivulon> cjwatson what were the settings to keep author changelogs together in dch?
[09:51] <yann|work> cjwatson: btw, how are the task fields added ?  I did not find any info about that when looking for it - I would have thought there was some option in apt-ftparchive config file, but did not find one
[09:52] <cjwatson> xivulon: I use this in .devscripts:
[09:52] <cjwatson> DEBCHANGE_RELEASE_HEURISTIC=changelog
[09:52] <cjwatson> DEBCHANGE_MULTIMAINT_MERGE=yes
[09:52] <cjwatson> yann|work: look for "extra overrides"
[09:53] <xivulon> cjwatson thx!
[09:55] <yann|work> cjwatson: ah ok - and there is some tool to generate extra-override file from ubuntu-tasks.desc ?
[10:00] <cjwatson> yann|work: it's generated, although not that particular way round
[10:00] <cjwatson> our debian-cd instance spits out an extra overrides file, if nothing else
[10:01] <cjwatson> based on germinate output
[10:02] <cjwatson> yann|work: but you may also be able to use the override.*.extra.* files in the /ubuntu/indices/ directory of an Ubuntu mirror, as a short-cut
[10:04] <yann|work> cjwatson: ok, thanks
[10:05] <yann|work> I did not know germinate, useful tool indeed :)
[12:07] <yann|work> cjwatson: shouldn't "apt-ftparchive -o BinDirectory::ExtraOverride=myfile" be enough to add Task fields ?
[12:26] <shtylman>  cjwatson: ok... I can test any potential fixes if you need ... I am curious though...does the grub-pc source package make all the grub-* suite of tools?
[12:36] <cjwatson> yann|work: maybe Tree::ExtraOverride; it's been a while since I looked at any of this
[12:36] <cjwatson> shtylman: yeah
[14:24] <yann|work> damned, Tree::ExtraOverride does not work either :(
[14:33] <yann|work> cjwatson: FWIW, options for the config file are ignored when passed on commandline, and unrecognized options are silently ignored
[16:12] <cr3> cjwatson: it might be possible that the alternate image kernel wasn't updated: "The installer cannot find a suitable kernel package to install."
[16:13] <cjwatson> I don't think that's the cause. Full logs please?
[16:14] <cjwatson> that means it couldn't even find an image of the right type, never mind ABI version
[18:04] <mterry> cjwatson, I'm looking at console_setup.py, where it modifies xorg.conf.  It looks like it only modifies anything if there's a 'Driver kbd' section.  Is that expected?
[18:05] <cjwatson> I think so, yes
[18:06] <cjwatson> why?
[18:06] <mterry> cjwatson, well, I thought that was the primary way we set default layout.  If user doesn't have an InputDevice or Device kbd section, they don't get new layout?
[18:07] <cjwatson> X will pick it up from /etc/default/console-setup if it's not separately configured in xorg.conf
[18:07] <mterry> cjwatson, ah, that makes sense then, thanks.  :)
[18:07] <mterry> cjwatson, I see that bit of code now
[18:07] <cjwatson> see /usr/lib/hal/debian-setup-keyboard
[18:08] <cjwatson> or possibly something newer for halsectomy, but that's the general idea
[18:08] <mterry> :)
[18:08] <mterry> Nice, thanks.
[19:23] <CIA-33> ubiquity: superm1 * r3429 ubiquity/debian/ (changelog oem-config.init):
[19:23] <CIA-33> ubiquity: Use the usplash init script to stop usplash in the oem-config init script
[19:23] <CIA-33> ubiquity: It seems to do a better job, and prevents a black screen on boot with some
[19:23] <CIA-33> ubiquity: drivers that aren't as usplash friendly. (LP: #403021)
[21:18] <cjwatson> superm1: oh, cool, thanks for figuring that out
[21:19] <superm1> no prob.  it was actually totally accidental. i was debugging a different problem on a freshly installed system, and found out that oem-config was working without usplash, so put two and two together :)
[21:19] <cjwatson> reassigned the bug back so that it gets auto-closed properly