[09:53] <Ng> before I file a bug, would encrypted home directory be expected to have worked in yesterday's amd64 alternate daily?
[09:55] <cjwatson> please go ahead and file that
[09:57] <Ng> ok :)
[09:59] <cjwatson> oh, actually
[09:59] <cjwatson> maybe don't bother
[10:00] <cjwatson> bug 395082 seems likely to apply
[10:00] <ubottu> Launchpad bug 395082 in ecryptfs-utils "No sudo access after installing of Ubuntu amd64 from July 2 daily." [High,Confirmed] https://launchpad.net/bugs/395082
[10:00] <cjwatson> Ng: ^-
[10:00]  * Ng looks
[10:01] <cjwatson> the lack of sudo access is fixed now, but there was an underlying ecryptfs breakage there too
[10:02] <cjwatson> which didn't seem to me to be especially specific to TheMuso's setup
[10:02] <Ng> I think I have slightly newer looking errors after user-setup, but I guess that just matches up with your comment on that bug
[10:02] <Ng> otherwise it seems to be trying to say the same kinda thing
[10:05] <Ng> thanks :)
[12:53] <CIA-8> debian-installer-utils: cjwatson * r680 ubuntu/debian/changelog: releasing version 1.70ubuntu1
[13:32]  * rgreening cracks code whip... {eyes evand}
[13:33] <evand> rgreening: indeed.  Unfortunately the development machine that I've been using for usb-creator hacking is in pieces scattered about two rooms (new carpets going in today), so I'm afraid I wont be able to work on it until later.
[13:33] <rgreening> gak! :)
[13:33] <rgreening> who said you could remodal :P
[13:33] <rgreening> lol
[13:34] <rgreening> evand: got anything you can push/publish ?
[13:34] <rgreening> oh, nm... scattered...
[13:34] <rgreening> haha
[13:34] <evand> unfortunately not, it's a local bzr branch that I quite stupidly haven't pushed anywhere yet
[13:35] <evand> quite close to doing so though, I did a fair amount of clean up on it this morning before they came to put the carpets in
[13:35] <rgreening> you need a cortical implant... to work directly with the ubu hive
[13:35] <evand> hahaha
[13:35] <rgreening> ;)
[13:36]  * rgreening ponders, does that make mark the borg queen?
[13:40] <evand> star trek humor is lost on me (despite having seen the recent film)
[13:54] <evand> cjwatson: I think https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/396414 is invalid for ubiquity, but do you have differing thoughts, or can you think of a more suitable target for it?  perhaps gnome-app-install?
[13:54] <ubottu> Ubuntu bug 396414 in ubiquity "No kde language support in Ubuntu by default" [Undecided,New]
[13:54] <rgreening> evand: it's one of those genres... either you love it or you hate it... I'm in the former camp
[13:55] <rgreening> though, I cant quote entire movies verbatim like some fans I know
[13:55] <rgreening> :)
[13:55] <evand> heh
[13:56]  * rgreening helps 'put down' the carpet for evand... {BAD CARPET... BAD CARPET...}
[13:56] <evand> haha
[14:01] <cjwatson> evand: yeah, somewhere in the package management frontend system anyway ...
[14:02] <evand> thanks
=== robbiew1 is now known as robbiew
[16:41] <cjwatson> fader: looking at your logs now ...
[16:41] <cjwatson> (bear with me, I'm trying to upgrade a chroot at the same time)
[16:41] <fader> cjwatson: Thanks.  I have the machine sitting here with the broken install if you need it
[16:42] <fader> cjwatson: No problem -- I'm actually sprinting right now so take your time :)
[16:43] <cjwatson> fader: could you confirm the contents of /lib/modules/ in the installer environment?
[16:44] <cjwatson> just the immediate subdirectory of that
[16:44] <cjwatson> fader: also, which kernel version is listed in /cdrom/pool/main/l/linux/ ?
[16:44] <fader> cjwatson: Will do.... lost my connection so give me 2-3 minutes
[16:53] <fader> cjwatson: ~ # ls /lib/modules/
[16:53] <fader> 2.6.24-24-generic
[16:55] <fader> cjwatson: /cdrom isn't mounted but this is on the NFS server: linux-image-2.6.24-24-server_2.6.24-24.55_amd64.deb
[17:02] <cjwatson> fader: check for kernel-image-*, please?
[17:02] <cjwatson> i.e. udebs not debs
[17:04] <fader> fader@nickel:~/servers.hardy$ ls /srv/enablement/www/cdimage.ubuntu.com/ubuntu-server/hardy/daily/current/hardy-server-amd64/pool/main/l/linux/kernel-image*
[17:04] <fader> oops heh
[17:05] <fader> kernel-image-2.6.24-16-generic-di_2.6.24-16.30_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-17-generic-di_2.6.24-17.31_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-18-generic-di_2.6.24-18.32_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-19-generic-di_2.6.24-19.41_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-20-generic-di_2.6.24-20.38_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-21-generic-di_2.6.24-21.43_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-22-generic-di_2.6.24-22.45_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-23-generic-di_2.6.24-23.52_amd64.udeb
[17:05] <fader> kernel-image-2.6.24-24-generic-di_2.6.24-24.55_amd64.udeb
[17:05] <cjwatson> ok
[17:06] <cjwatson> this set of errors is pretty baffling
[17:06] <cjwatson> any way I can get a shell?
[17:06] <cjwatson> Jul  7 11:12:06 main-menu[2582]: (process:14177): mdadm: /dev/sda5 does not appear to be an md device
[17:06] <cjwatson> Jul  7 11:12:06 main-menu[2582]: (process:14177): mdadm: /dev/sda1 does not appear to be an md device
[17:06] <cjwatson> Jul  7 11:12:06 main-menu[2582]: (process:14177): mount: Mounting /dev/sda1 on /target/ failed: No such device
[17:06] <cjwatson> *appears* to be the relevant stuff but why on earth would mdadm be involved?
[17:13] <cjwatson> I think the mdadm thing is a red herring
[17:13] <cjwatson>                         if mdadm --detail "$fs" | greq -qsi " raid1$" 2>/dev/null; then
[17:13] <cjwatson> (a) probably needs 2>/dev/null on the first command too (b) can't spell "grep"
[17:13] <cjwatson> but not a regression in hardy ...
[17:15] <fader> cjwatson: Looks like this particular one has a failed RAID drive, but I've been seeing install problems on other machines as well
[17:16] <fader> cjwatson: Let me dig in and see what else I can turn up on other machines in that environment
[17:16] <c0nfus3d> Hi All, I am trying to figure how I can change the text in Ubiquity "Prepare Disk Space" window - kindly refer the following image - http://imagebin.org/54855
[17:16] <c0nfus3d> i am basically trying to customize the live CD
[17:17] <cjwatson> c0nfus3d: change /.disk/info on the CD
[17:17] <c0nfus3d> thanks cjwatson - let me try it
[17:17] <cjwatson> the first two fields are used for the partitioning display
[17:40] <eeejay> hola
[17:40] <eeejay> i am trying to preseed ubiquity over dhcp, is this possible?
[18:18] <evand> rgreening: lp:~usb-creator-hackers/usb-creator/cleanup - it's still fairly incomplete, but it's mostly cleaned up.  Feel free to start hacking on it.  I'm trying to do proper test driven development this time around, so I would greatly appreciate it if you write tests before code, but don't fret too much if that becomes a burden.  I've written a fake devicekit-disks to allow us to test without having devicekit installed, and to help us identify 
[18:19] <evand> I haven't written any policykit code yet as that appears to be in a state of flux in devicekit (it was ripped out of gnome-disk-utility before the last release and appears to have been refactored in dk trunk since)
[18:19] <rgreening> heh
[18:20] <evand> I'd like to move any common frontend/backend code into the respective base frontend/backends, if any exists
[18:20] <rgreening> I'll grab it and look it over...
[18:20] <evand> (see what ubiquity does for an example of that)
[18:20] <rgreening> sure
[18:21] <evand> I remerged bin/usb-creator as the two separate files were quite similar and we can just do runtime importing to sort out which frontend/backend to use (though that code is a bit ugly at the moment)
[18:21] <rgreening> as long as gtk/gobject/glib and kde/qt never meet or cross over
[18:22] <rgreening> dunno if I like that...
[18:22] <evand> glib is in the devicekit backend at the moment, but only because I haven't ported that work over from trunk yet
[18:22] <evand> oh?  What are your concerns with it?
[18:23] <rgreening> evand: I think keeping two seperate bin would be better and not do runtime checking...
[18:23] <rgreening> imo
[18:24] <evand> I'm concerned about the code duplication there, but I'm sure there's an easy solution to that
[18:24] <rgreening> in the fe bin?
[18:24] <evand> feel free to tackle that bit, or I'll take a look myself tomorrow
[18:24] <evand> in bin/usb-creator-{gtk,kde,win}
[18:25] <rgreening> evand: the traceit, fail, excepthook should be pulled ouyt i
[18:25] <rgreening> stead into a sep lib
[18:25] <evand> I'm keen to get rid of the trace option
[18:25] <rgreening> then no code dup issues and we have diff bins
[18:25] <rgreening> me too
[18:26] <rgreening> imo, no need for trace in user version. if it works, it works...
[18:26] <evand> option parsing would still be duplicated, but I think you're on the right track, we should just have a common module to source that stuff from
[18:26] <rgreening> option parsing is not dups
[18:26] <rgreening> look again at the kde version
[18:26] <rgreening> :)
[18:27] <evand> ah
[18:27] <rgreening> I use the kde equiv of cmdline
[18:27] <rgreening> :)
[18:27] <evand> okay, fair enough
[18:27] <rgreening> but, yeah, pull the common into a seperate file...
[18:28] <rgreening> so, backend,py, install,py, and tools.py (or similar)
[18:28] <evand> Indeed, I'll unwind that mess tomorrow
[18:28] <rgreening> awesome :)
[18:28] <rgreening> you da man
[18:29] <cjwatson> fader: I've reopened the bug, but I think the problem is that your mirror is hosed
[18:29] <cjwatson> Jul  7 11:10:41 anna[6644]: wget:
[18:29] <cjwatson> Jul  7 11:10:41 anna[6644]: server returned error 404: HTTP/1.1 404 Not Found^M
[18:30] <fader> cjwatson: Hmm, let me take a look.  Maybe something has moved on me again.
[18:33] <cjwatson> easiest way to see what URL it's fetching is probably in the server logs unfortunately
[18:34] <cjwatson> but it'll be http://10.189.90.1/enablement/cdimage.ubuntu.com/ubuntu-server/hardy/daily/current/hardy-server-amd64/dists/something
[18:42] <tormod> is there a way with grub2 to set boot options for certain kernels only? (like there was for grub-legacy)
[18:44] <cjwatson> you can use GRUB_CMDLINE_LINUX or GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub depending on what you want
[18:44] <cjwatson> anything more fine-grained than that in grub legacy never really worked with automatic updates anyway
[18:46] <tormod> I thought I could do per-kernel options with kopt_2_6_31 etc, but in fact I don't know how well it actually worked
[18:47] <cjwatson> oh, maybe you could, I'm not sure about that
[18:47] <cjwatson> there's no such facility in grub2 right now - please do take it up upstream if you can justify it
[18:47] <tormod> ok thanks
[19:34] <fader> cjwatson: The only 404s I'm seeing on the server are for hardy-updates.  I see the same thing for karmic installs (which succeed), so I'm not sure that's the problem with the install.
[19:34] <cr3> eeejay: did you get an answer regarding preseeding ubiquity?
[19:48] <cjwatson> fader: hmm. the problem is definitely that the ext3 module isn't available ...
[19:49] <cjwatson> and it's not even trying to load fs-core-modules, which is the udeb containing it
[19:50] <cjwatson> I wonder if the overrides are busted
[19:53] <cjwatson> hmm! the CD has -23 on it
[19:53] <cjwatson> oh, I see, incorrect seeds
[19:54] <cjwatson> fader: ok, sorry, that was a bit of a saga, largely because there were uncommitted changes in my platform.hardy seeds branch so a simple grep didn't find the problem
[19:54] <cjwatson> fader: the next CD build should work - I'll do a special one shortly
[19:54] <fader> cjwatson: You rock. :)  Thanks!
[19:56] <cjwatson> oh, if I rocked that much I'd have committed these changes when I made them locally, which was apparently *months* ago
[19:56] <cjwatson> like, February
[19:56] <fader> Hehe
[19:57] <cjwatson> server CD build running now ...
[20:10] <cjwatson> right, *now* it's better
[20:10] <cjwatson> fader: wanna re-mirror and try again?
[20:10] <cjwatson> I've verified that 2.6.24-24 udebs are on the new server CD images
[20:33] <fader> cjwatson: Roger, images are downloading.
[20:34] <cjwatson> cool
[20:40] <fader> cjwatson: That seems to have fixed it.  I'm seeing results start to trickle in from the automated tests :D
[20:48] <cjwatson> fader: thank goodness for that
[20:48] <fader> :)
[21:01] <sbeattie> fader: yay!
[21:02] <fader> sbeattie: Indeed!  I'll whip up an HTML report once the results are all in.
=== robbiew is now known as robbiew-afk