[00:03] <cjwatson> soren: because it needs large chunks of it anyway in order to generate configuration files that refer to other detected operating systems
[00:03] <cjwatson> soren: also, it *does* call grub-install
[00:04] <cjwatson> soren: the thing it's really replicating is update-grub (grub-install doesn't generate a configuration file ...), and that's because update-grub really isn't all that good at handling the initial installation case
[00:06] <soren> cjwatson: Ah, right. Other operating systems. That was the missing piece of the puzzle. I haven't had to worry about such a thing for a looong time :)
[00:29] <xivulon> I have uploaded umenu code to https://code.launchpad.net/umenu
[00:30] <xivulon> make prerequisites && make && make test
[03:35] <TheMuso> Ok, there is one bug I can consistantly reproduce with partman-dmraid, however its a little hard to explain without knowing how partman presents the UI. How can I turn up debugging to max so I can get a deacent log to show to you guys?
[04:08]  * TheMuso smacks whoever wrote the part of the dmraid init script that sources /etc/default/rcS, and doesn't check whether it even exists.
[06:53] <cjwatson> TheMuso: DEBCONF_DEBUG=developer is usually the most useful kind of logging for that
[06:58] <TheMuso> cjwatson: Thanks, once I get an install done, I'll dig deeper. Still got to get my custom CD to behave first. :p
[07:22] <evand> cjwatson: if you have a free moment today, I've finished off the patch I showed you before that there was confusion over.  If you could just review the partman-partitioning changes and let me know if they're too hackish to use, I'd very much appreciate it.
[07:22] <evand> http://pastebin.ubuntu.com/4535/
[07:44] <TheMuso> Yes! Passed the kernel/base system stage. Now the only worry is grub/grub-installer.
[08:15] <TheMuso> gah. Grub failure, somewhat expected.
[08:16] <TheMuso> evand: If you're still around, and had made a start on dmraid main inclusion, do you have anything that I might find useful for the report?
[08:17] <evand> TheMuso: I haven't had a chance to touch it all.  Unfortunately, I leave you with a blank slate.
[08:17] <TheMuso> evand: No problem, thanks anyway.
[08:25] <CIA-22> ubiquity: evand * r2454 ubiquity/ubiquity/frontend/kde_ui.py: Stub set_grub_combo in kde_ui for the time being so it doesn't crash.
[08:27] <TheMuso> evand: How is that privelage separation stuff going? Is that likely to land before FF?
[08:28] <evand> TheMuso: oh wow, I never did merge that.  I'll take care of that today.
[08:28] <evand> It's done though.
[08:28] <evand> Though I might need to update it slightly to reflect some recent changes.
[08:29] <TheMuso> evand: Right, let me know, and I'db e glad to hammer it, at least with accessibility testing. :)
[08:30] <evand> TheMuso: will do :)
[08:32] <tjaalton> cjwatson: got time to talk about input-hotplug?
[08:33] <tjaalton> cjwatson: I heard you are in the middle of a meeting, so ping me when done
[08:41] <TheMuso> cjwatson: Where is the best place to set that debconf variable?
[08:44] <cjwatson> TheMuso: kernel command line
[08:44] <cjwatson> tjaalton: sure
[08:46] <tjaalton> cjwatson: ok, so I'm aware that FF is tomorrow, and we still don't use input-hotplug. I tried to get the hal-script working (to autoconfigure the devices on fly), but either it won't work or I'm doing something wrong
[08:47] <tjaalton> cjwatson: I sent an email to debian-x about it, and David answered a month ago saying that he prefers patching the server to use the settings on the xorg.conf, which would make it work for everyone
[08:47] <cjwatson> patching the server to do what?
[08:47] <tjaalton> cjwatson: but he's been really busy lately, and hasn't published any patches
[08:47] <cjwatson> oh
[08:47] <cjwatson> sorry, I'm dense and can't read
[08:47] <tjaalton> heh
[08:47] <cjwatson> does it not honour xorg.conf right now?
[08:47] <tjaalton> no
[08:47] <tjaalton> if using input-hotplug
[08:47] <cjwatson> for keyboard layout and such?
[08:47] <tjaalton> rihgt
[08:48] <tjaalton> -ght
[08:48] <cjwatson> huh, ok
[08:48] <cjwatson> I think I also prefer patching the server
[08:48] <cjwatson> my concern is that the installer changes required are ... well, not hideously complicated, but not trivial either
[08:48] <cjwatson> and we're really short of installer bandwidth for feature freeze
[08:48] <tjaalton> are there any changes needed, really?
[08:49] <tjaalton> console-setup works and the xorg configuration still feeds on that
[08:50] <tjaalton> let me dig up the post for you, a sec
[08:51] <tjaalton> http://lists.debian.org/debian-x/2007/12/msg00234.html
[08:51] <tjaalton> I also tried #hal, but got no help :/
[08:53] <tjaalton> the problem with _not_ going input-hotplug is that upstream is still fixing issues with legacy input
[08:53] <tjaalton> they are all using evdev now
[08:54] <cjwatson> changes> console-setup generates /etc/default/console-setup, xorg generates xorg.conf based on that. Does the HAL script use either of those?
[08:54] <cjwatson> ah, I see from your post
[08:55] <cjwatson> ok, I'm less concerned about something that uses the same keyboard configuration files
[08:55] <tjaalton> right
[08:56] <cjwatson> sleep 15> does output from 'set -x' go anywhere?
[08:56] <tjaalton> I need to reproduce it now, but AIRI it didn't
[09:01] <cjwatson> you could do 'exec 2>/tmp/foo' up-front
[09:02] <tjaalton> before running hal?
[09:02] <cjwatson> no, at the top of your hal script
[09:02] <tjaalton> ah, ok
[09:02] <cjwatson> right below the shebang
[09:03] <tjaalton> ok, I'll play with it and report back what happens
[09:03] <tjaalton> thanks
[09:12] <CIA-22> ubiquity: evand * r2455 ubiquity/ubiquity/frontend/kde_ui.py: Replicate fix for the installer window briefly showing in kde_ui.
[09:20] <tjaalton> cjwatson: ok, the same as before; without sleeping I get 'Could not initialise connection to hald.' after the command, and with sleep 15 it doesn't even run h-s-p
[09:21] <tjaalton> but the hald output says '/usr/lib/hal/scripts/hal-setup-xorg exited'
[09:22] <cjwatson> sleep 15 || true
[09:22] <cjwatson> ?
[09:22] <cjwatson> oh, I wonder if its PATH is bogus
[09:22] <cjwatson> try PATH=/usr/sbin:/sbin:/usr/bin:/bin at the top?
[09:22] <cjwatson> export PATH=blah, that is
[09:23] <tjaalton> but it runs without sleep, and hal has a default value all scripts can use
[09:23] <cjwatson> doesn't seem to be a problem for built-in scripts though
[09:23] <tjaalton> setting || true didn't help
[09:33] <tjaalton> ok, it terminates the script after 10 seconds, so setting sleep 9 makes it complain the same about hald not running
[09:34] <tjaalton> hrm, what about running the script from /etc/X11/Xsession.d ?-)
[09:40] <tjaalton> nope, no change. the fault is not that hald isn't running, the command works when run by hand
[09:57] <tjaalton> hmm, maybe policykit has something to do with this
[10:15] <TheMuso> Does anybody know off-hand what an error code of 20 from grub-installer is supposed to mean?
[10:16] <TheMuso> Oh its something to do with debconf in this situation. Will need to dig into the source...
[10:18] <cjwatson> $ grep 20 /usr/share/perl5/Debconf/ConfModule.pm
[10:18] <cjwatson>         syntaxerror => 20,
[10:18] <cjwatson>  should come with an attached descriptive message
[10:29] <TheMuso> cjwatson: Yeah I saw that in the debug output which was how I worked it out.
[11:55] <TheMuso> \o/
[11:55]  * TheMuso has an install of hardy on a dmraid setup.
[12:02] <tjaalton> cjwatson: I sent an email to the hal-list, hopefully it'll get sorted
[12:07] <cjwatson> tjaalton: cool, thanks
[12:07] <cjwatson> TheMuso: nice. what was the grub-installer problem?
[12:07] <TheMuso> cjwatson: db_input input not being given enough arguments. I've already tested the fix, and its in bzr.
[12:08] <TheMuso> The fix allowed the install to happen to be precise.
[12:09] <TheMuso> Note that this wasn't a dual boot. If I can get this in as a feature before FF, I intend to put it all through its paces, including an install alongside 1 and 2 different windows installs, on the same fakeraid setup.
[12:12] <TheMuso> cjwatson: So to have it considered as a feature, is it just a matter of filling out an MIR, or is there more to the process than that?
[12:12] <cjwatson> TheMuso: looks good; please upload grub-installer at your convenience. I've committed the same fix upstream.
[12:13] <TheMuso> cjwatson: Ok, I assume you saw my change...
[12:13] <cjwatson> TheMuso: https://wiki.ubuntu.com/MainInclusionProcess and it would probably be best to explicitly talk to pitti about it
[12:14] <cjwatson> TheMuso: yep, I updated when you said you'd committed it
[12:14] <cjwatson> TheMuso: that's on the error path though - if that error fires, surely the install is broken?
[12:14] <cjwatson> (the fix was clearly right all the same)
[12:15] <TheMuso> Yeah, why it triggered an error though, I don't know. But yes, that gets triggered if there is a problem, which is why several configs need testing.
[13:01] <TheMuso> Hrm. Looks like whatever does the UUID to device name/node translation is picking up the first disk in the raid1 mirror, instead of the devmapper device. Need to check dmraid bugs to see if there is any thing similar reported.
[13:25] <TheMuso> cjwatson: We're in luck. Theres already an MIR for dmraid. I'll give it a look over, and change anything that needs changing, and file the bug if that also hasn't been done already.
[13:53] <cjwatson> cool
[14:16] <evand> cjwatson: did you happen to catch my above message?  If you haven't had a chance to look it over, that's perfectly fine, I just wanted to make sure you saw it.
[14:27] <TheMuso> Ok, dmraid MIR reviewed, and looks ok. Wrote partman-dmraid MIR, and filed bugs for both. Unless anybody needs help with other FF stuff, I'm off to bed.
[14:28] <evand> goodnight TheMuso
[14:40] <cjwatson> evand: I'm still not entirely confident I understand it, but please go ahead and commit and if there's a problem I'm sure it'll come to light later
[14:42] <evand> cjwatson: ok, it will probably be easier to follow when you can see the UI in action anyway.
=== cjwatson_ is now known as cjwatson
[15:27] <CIA-22> ubiquity: evand * r2456 ubiquity/ (debian/changelog ubiquity/frontend/kde_ui.py):
[15:27] <CIA-22> ubiquity: * Add the progress bar for automatic mode that was already present in
[15:27] <CIA-22> ubiquity:  gtk_ui to kde_ui.
[15:45] <CIA-22> ubiquity: evand * r2457 ubiquity/ (5 files in 4 dirs): * Replace the resize slider with a custom widget in gtk_ui.
=== evand_ is now known as evand
=== cjwatson_ is now known as cjwatson
[20:02] <CIA-22> ubiquity: evand * r2458 ubiquity/ (d-i/manifest debian/changelog):
[20:02] <CIA-22> ubiquity: * Automatic update of included source packages: apt-setup
[20:02] <CIA-22> ubiquity:  1:0.31ubuntu5, grub-installer 1.27ubuntu5, hw-detect 1.58ubuntu2,
[20:02] <CIA-22> ubiquity:  partman-partitioning 54ubuntu2.
[20:12] <CIA-22> ubiquity: evand * r2459 ubiquity/debian/changelog: releasing version 1.7.7
[20:14] <CIA-22> ubiquity: evand * r2460 ubiquity/ (9 files in 6 dirs): Bump to 1.7.8
=== cjwatson_ is now known as cjwatson
[22:33] <TheMuso> Hrm. Dmraid doesn't 1) halt on a degraded array setup, and 2) have any options to state that you don't want a degraded array, and no real way of checking the status, and getting something meaningful back with an exit code.
[23:02] <TheMuso> And, the array doesn't seem to be rebuilding under Linux, as well as dmraid stating that status is ok, even though it is incomplete...