[03:01] <mshadle> sure enough, uninstall debconf and reinstall and im fine
[03:06] <mshadle> so something with di-tools, systemimager, or something else corrupted my debconf when i removed it
[09:34] <cjwatson> evand: 320 is probably actually closer, but we wanted to be conservative in a few places and said 384
[10:38] <tjaalton> cjwatson: did you discuss console-setup with gravity at FOSSCamp?
[10:38] <tjaalton> and if, what was the outcome
[10:38] <tjaalton> +so
[10:40] <cjwatson> erm, what about it?
[10:40] <cjwatson> we did talk a bit, though I forget the exact details; if you remind me which bit you care about, I may remember ...
[10:41] <tjaalton> well, our xkb layout configuration depends on it
[10:41] <tjaalton> but debian uses something different
[10:41] <cjwatson> Debian will be moving to console-setup in time
[10:41] <tjaalton> oh
[10:41] <cjwatson> and our XKB layout configuration does not depend on console-setup
[10:41] <cjwatson> it's the other way round
[10:42] <cjwatson> well, though it does fish its initial value out of what console-setup did in the installer, true
[10:42] <tjaalton> yes
[10:42] <tjaalton> I just did some thinking about how to get the values for hal
[10:42] <tjaalton> and how to keep them in sync
[10:43] <cjwatson> http://wiki.debian.org/DebianInstaller/ConsoleSetupSwitch
[10:43] <tjaalton> oh
[10:43] <tjaalton> goal for lenny, sweet
[10:45] <cjwatson> I think in practice sorting out console-setup layout/variant names i18n is the hardest problem
[10:45] <cjwatson> bryce said he'd help out with that for hardy
[10:45] <cjwatson> anyway, do go on regarding hal?
[10:46] <tjaalton> right.. so AIUI it was decided that hal should ship a script that maintains the fdi-file
[10:47] <tjaalton> or do it in config/postinst
[10:47] <tjaalton> but that would mean running dpkg-reconfigure when doing a change
[10:50] <tjaalton> so I was thinking, if console-setup is the "master" place to store the data (I can't think of a situation where you'd have different layout on the console), there could be a "update-kbdlayout" or similar that would update the fdi
[10:51] <tjaalton> console-setup seems to store the information in debconf
[10:52] <cjwatson> debconf should never be the canonical place to store anything
[10:52] <cjwatson> console-setup stores it in /etc/default/console-setup
[10:52] <cjwatson> agreed that there needs to be a simple command to change it
[10:52] <cjwatson> editing XML by hand is not good
[10:52] <tjaalton> yes, I know that "debconf should not be a database" :)
[10:52] <cjwatson> I don't think either console-setup or X needs to be the "master", if it's being kept in hal ...?
[10:53] <cjwatson> but it doesn't hugely matter, I guess
[10:53] <tjaalton> well, console-setup doesn't need hal, although they are both installed on every system..
[10:54] <cjwatson> yes, that could be a sticking point in Debian
[10:54] <cjwatson> it would mean committing to having hal in the base system
[10:54] <cjwatson> for that matter, I don't think hal is part of Ubuntu's base system
[10:54] <cjwatson> it's priority optional
[10:55] <tjaalton> so it seems..
[10:55] <tjaalton> hmm
[10:55] <cjwatson> right now, it's part of desktop
[10:55] <cjwatson> server installs don't have it
[10:55] <cjwatson> could hal fish it out of a non-fdi file?
[10:55] <tjaalton> yep, didn't bother to check :)
[10:55] <cjwatson> like /etc/default/console-setup?
[10:56] <tjaalton> it could
[10:56] <cjwatson> I think that might be better
[10:56] <cjwatson> if it fetched it dynamically at run-time
[10:56] <cjwatson> the console setup is the sort of thing you need to edit with very few tools, and having it as a simple text file seems like a win
[10:57] <cjwatson> having it in hal (the protocol) seems more important than having it in hal's native file format
[10:57] <tjaalton> how to do that in runtime?
[10:58] <cjwatson> not my problem
[10:58] <cjwatson> ;-)
[10:58] <tjaalton> haha
[10:58] <cjwatson> hal has plenty of scripts that it calls to figure stuff out
[10:58] <cjwatson> e.g. for power management
[10:58] <cjwatson> I'm not saying it's trivial but it ought to be possible
[10:58] <tjaalton> so you mean it's better to have the information only in one place (on disk) and read that on fly?
[10:59] <cjwatson> it feels better
[10:59] <tjaalton> sounds more consistent
[11:00] <tjaalton> for us it's simple to rely on console-setup, and then Debian can add code to get the information from current xorg.conf or whatever
[11:00] <tjaalton> until they use console-setup
[11:01] <cjwatson> or migrate it from xorg.conf once-only into an fdi file if they prefer
[11:01] <tjaalton> yeah, that could be done in some postinst
[11:02] <cjwatson> so what will the gnome keyboard layout thing do?
[11:02] <cjwatson> presumably it can't set the value in hal, since it's per-user not system-wide
[11:02] <tjaalton> right
[11:02] <cjwatson> I guess it just carries on doing what it's doing now
[11:02] <tjaalton> it should let the user change the layout if he needs to
[11:02] <tjaalton> but, there are bugs
[11:03] <tjaalton> at least now that the default is us. If I add fi to the list, I can't make it default (on my session) until I remove us
[11:03] <cjwatson> ugh
[11:03] <tjaalton> then if I plug in another keyboard, it uses us, and the moment I type with it the whole session uses "us"
[11:04] <tjaalton> :P
[11:04] <tjaalton> corner cases, but still
[11:06] <tjaalton> hmm, /usr/lib/hal/scripts has stuff that should help
[11:06] <tjaalton> ..figuring out how to do it
[11:07] <tjaalton> oh, just echo the values.. cool
[11:07] <tjaalton> dead simple :)
[11:07] <tjaalton> how the hell no-one thought of this before
[11:09] <tjaalton> now something completely different: has it been discussed if we could use 'relatime' mount option by default?
[11:09] <tjaalton> Fedora8 does that
[11:10] <tjaalton> currently even every read from the cache forces a write to the disk
[11:11] <cjwatson> yes, it has
[11:11] <cjwatson> partman now (hardy) supports relatime, but doesn't yet support the concept of default mount options
[11:12] <cjwatson> so that needs to be added first
[11:12] <tjaalton> cool
[11:12] <cjwatson> but I think it would be a good plan
[11:12] <tjaalton> there is a spec about noatime, but relatime is better
[11:12] <tjaalton> since some apps have problems with noatime
[11:12] <tjaalton> https://blueprints.edge.launchpad.net/ubuntu/+spec/noatime
[11:13] <tjaalton> hmm, it would be nice to see directly when a spec has been created
[11:14] <cjwatson> sigh @ spec proliferation
[11:14] <tjaalton> yeah..
[11:19] <tjaalton> should I draft a spec about it, and then later mark the noauto-spec as superceded?
[11:20] <tjaalton> hog
[11:20] <tjaalton> uh
[11:20] <tjaalton> "oh"
[11:20] <tjaalton> cjwatson: didn't notice your comment that a spec is not necessary :)
[11:21] <cjwatson> it's yet another case where a simple bug would be perfectly fine
[12:36] <twb> cjwatson: is partman-auto/purge_lvm_from_device supposed to work under gutsy's d-i?
[12:36] <twb> I get "Volume group name already in use".
[12:37] <cjwatson> sorry, I don't know offhand
[12:37] <twb> AFAICT I can't make an automated lvm-using install idempotent.
[12:37] <twb> I got that entry from the Sid install guide, so it may not be applicable to gutsy.
[12:37] <cjwatson> I don't know why it wouldn't work
[12:37] <cjwatson> it's there
[12:38] <twb> Hmm.
[12:38] <cjwatson> perhaps some stupid device name difference
[12:38] <twb> I'm also using oem-config, if that makes a different.
[12:38] <twb> *difference
[12:38] <cjwatson> no
[12:39] <twb> I don't know how to analyse the problem.
[12:40] <twb> Oh, this VM isn't using DEBCONF_DEBUG, lemme reboot
[14:44] <cjwatson> evand: did you get my mail about clock-setup?
[14:44] <cjwatson> in reply to your merge requests
[14:44] <evand> indeed, I'm working on it as we speak
[14:45] <cjwatson> ok, thanks
[14:46] <cjwatson> localechooser done, console-setup imported into bzr and nearly done, hw-detect imported into bzr and done, elilo-installer synced
[14:47] <evand> awesome
[14:47] <evand> was ntp previously handled by a different component?
[14:54] <cjwatson> it wasn't done at all
[14:55] <evand> ah, that clears things up, thanks
[15:05] <soren> Just FYI: mathiaz has done the ntp merge, I just need to review it.
[15:21] <cjwatson> console-setup uploaded, os-prober synced
[15:22] <CIA-4> oem-config: cjwatson * r383 oem-config/ (7 files in 2 dirs): * Convert to python-central.
[15:24] <CIA-4> oem-config: cjwatson * r384 oem-config/ (debian/changelog scripts/localechooser-apply):
[15:24] <CIA-4> oem-config: * Adjust for localechooser 1.39:
[15:24] <CIA-4> oem-config:  - Don'\''t edit /etc/environment unless it already contains LANG or
[15:24] <CIA-4> oem-config:  LANGUAGE settings.
[15:25] <CIA-4> oem-config: cjwatson * r385 oem-config/ (debian/changelog lib/components/language.py):
[15:25] <CIA-4> oem-config: * Adjust for localechooser 1.40:
[15:25] <CIA-4> oem-config:  - Cope with localechooser asking countrychooser/country-name rather than
[15:25] <CIA-4> oem-config:  countrychooser/shortlist.
[15:25] <CIA-4> ubiquity: cjwatson * r2360 ubiquity/ (debian/changelog ubiquity/components/language.py):
[15:25] <CIA-4> ubiquity: * Adjust for localechooser 1.40:
[15:25] <CIA-4> ubiquity:  - Cope with localechooser asking countrychooser/country-name rather than
[15:25] <CIA-4> ubiquity:  countrychooser/shortlist.
[15:28] <CIA-4> ubiquity: cjwatson * r2361 ubiquity/ (debian/changelog scripts/install.py):
[15:28] <CIA-4> ubiquity: * Remove the pregenerated snakeoil certificate and reconfigure ssl-cert so
[15:28] <CIA-4> ubiquity:  that each system gets a unique snakeoil certificate.
[15:32] <cjwatson> evand: I think we should skip apt-setup for alpha 1; it requires new apt, new pkgsel, and new di-utils
[15:32] <cjwatson> which is all kind of a pain to get in place by Thursday
[15:33] <evand> indeed
[15:34] <twb> What happens on Thursday?
[15:34] <evand> cjwatson: http://people.ubuntu.com/~evand/upload/clock-setup_0.92ubuntu1.dsc
[15:34] <evand> http://people.ubuntu.com/~evand/bzr/clock-setup/
[15:34] <evand> that should address the issues you raised
[15:34] <evand> I looked over it a few times just to be sure, but you might want to review it one more time, just in case
[15:35] <cjwatson> twb: alpha 1 planned to be released then
[15:36] <cjwatson> evand: thanks, looking
[15:36] <cjwatson> evand: could you please merge my changes? bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/clock-setup/ubuntu/
[15:36] <cjwatson> err
[15:37] <cjwatson> I didn't make any changes there; did you throw away and start over?
[15:37] <evand> indeed, it seemed cleaner to do it that way.  Should I not have?
[15:37] <cjwatson> please don't in future, it's confusing
[15:37] <evand> I figured you hadn't merged from me
[15:37] <evand> ok
[15:37] <evand> sorry about that
[15:38] <cjwatson> hmm, I wonder what LP will do if I uncommit
[15:38]  * cjwatson goes to look that up
[15:38] <evand> probably explode
[15:39] <cjwatson> I don't think so, it does branch.pull(self._source_branch, overwrite=True)
[15:39] <cjwatson> so I'll just uncommit back to 0.16ubuntu1 and pull again
[15:40] <cjwatson> generally not good to uncommit on a published branch though, but in this case I guess it's the easiest recovery path
[15:40] <evand> ok
[15:41] <cjwatson> evand: this time you seem to have dropped the UTC question *and* its changelog entry
[15:41] <cjwatson> I sort of meant to keep the question instead
[15:41] <cjwatson> (due to bug 28961)
[15:42]  * evand checks
[15:49] <evand> ah, I misread and thought that they had merged that bit
[15:49] <evand> though on further inspection, no, they have not
[15:49] <evand> fixing now
[15:51] <cjwatson> thanks
[15:53] <evand> ok, pushed
[15:56]  * evand crosses fingers
[16:34] <cjwatson> looks good
[16:35] <evand> great.  Shall I move on to base-installer, or are you already working on that?
[16:35] <cjwatson> I am not
[16:36] <evand> ok
[16:36] <cjwatson> clock-setup uploaded, thanks, sorry for the long back-and-forth :)
[16:36] <cjwatson> I'm working on the rather epic task of importing debian-installer's history into bzr
[16:36] <evand> sorry for messing it up three times :)
[16:37] <evand> yikes
[16:37] <cjwatson> took a while to find all the tarballs I had from warty ...
[16:37] <cjwatson> I want to have the aid of bzr for the merge though
[16:37] <evand> haha
[16:39] <cjwatson> urgh, bzr-svn doesn't seem to have done the right thing with $Id$ expansions
[16:41] <cjwatson> https://blueprints.launchpad.net/bzr/+spec/bzr-keyword-expansion, sigh, guess I'll just ignore those conflicts
[16:42] <cjwatson> maybe I should use tailor instead ...
[16:57] <twb> I wouldn't trust tailor for more than a one-off migration of data from one SCM to another
[17:00] <cjwatson> I've used it before with moderate success, and in this case I have already tried everything else that I know to be available
[17:00] <cjwatson> plus I have some checks and balances available to me on an ongoing basis, so I'm not worried
[17:01] <cjwatson> that said, tailor isn't working for me either at the moment
[17:01] <twb> You've used it successfully for two-way bzr svn interaction?
[17:01] <cjwatson> I don't need two-way
[17:01] <twb> Oh, OK
[17:02] <cjwatson> I'm just working around the fact that a cscvs bug means that Launchpad can't import this particular Subversion repository into bzr as yet
[17:04] <cjwatson> looks like I'm stuck with bzr-svn's bugs though
[21:01] <evand> cjwatson: http://people.ubuntu.com/~evand/bzr/base-installer/ and http://people.ubuntu.com/~evand/upload/base-installer_1.85ubuntu1.dsc
[21:01] <evand> Not entirely sure if I did kernel/tests/sparc/niagara-t1-* correctly.  I was going to bump the kernel version, but linux-image-2.6.22-14-sparc64 doesn't exist according to p.u.c.
[21:03] <knowmad> Hi, is this an appropriate channel for discussing usplash customization issues?
[21:04] <evand> knowmad: #ubuntu-devel might be more appropriate.  My usplash knowledge is somewhat limited.
[21:05] <knowmad> evand: thanks! i'm being challenged by it at the moment myself.
[21:22] <cjwatson> evand: ok, I'll look tomorrow morning
[21:22] <cjwatson> thanks
[21:22] <cjwatson> the kernel versions in tests aren't too important
[21:35] <evand> ah, thanks