[03:07] <HauntedUnix> Morning
[04:19] <sivang> can someone put the agenda link on the channel's topic?
[05:09] <ploum> I put already a link about my opinion
[05:09] <ploum> http://ploum.frimouvy.org/?2004/10/25/6-i-dont-want-people-to-use-gnome-applications-anymore
[05:29] <doko> I know I am late ... are people already busy working? so quiet ...
[05:29] <Keybuk> half an hour early
[05:30] <doko> ahh still summertime in the UK?
[05:31] <Keybuk> meeting time is UTC, not BST/GMT
[05:31] <Keybuk> we're UTC+0100 at the moment
[05:38] <lamont> doko: so you're early. :-)
[05:38] <doko> lamont: at least that can't be wrong ;)
[05:39] <lamont> yeah
[05:55] <sivang> doko : early enough :)
[05:55] <mdz> jdub: are you here for the duration?  thanks for staying up
[05:56] <jdub> probably
[05:56] <jdub> i'm hammered
[05:56] <jdub> got up at 4am
[05:56] <daniels> ouch
[05:56] <daniels> you're turning into fabio :\
[05:56] <fabbione> tsk :P
[05:56] <sivang> hey lamont
[05:56] <fabbione> he should be honoured of that ;)
[05:57] <sivang> fabboine : still insomnic ?
[05:57] <thom> fabbione: the word in english is "suicidal" ;-)
[05:57] <daniels> or terrified, either way
[05:57] <mdz> jdub: had a nap along the way, I hope
[05:57] <bob2> daniels: think how much fun you'll have over there!
[05:58] <jdub> mdz: no
[05:58] <bob2> "little daniel, it's 4am, let's hack x.org!"
[05:58] <mdz> ...daniels awakes as a bucket of ice water is emptied over his head
[05:59] <Keybuk> right, better get tea
[05:59] <daniels> mdz: 4am is generally when I go to sleep these days
[06:00] <mdz> ok
[06:00] <mdz> called to order, etc.
[06:00] <mdz> is everyone here who ought to be?
[06:00] <lamont> morning sivang
[06:01] <sivang> lamont : good evening, it's 18:00pm here ;-)
[06:01] <mdz> me waits a moment for stragglers to arrive
[06:01] <sabdfl> hi all
[06:01] <pitti> Hi fearless sabdfl!
[06:02] <sivang> Hi fearless leader! :)
[06:02] <sabdfl> hey all, mdz will be chairing this one
[06:02] <seb128> evening sabdfl
[06:02] <mdz> ok, we have a ton of ground to cover, so let's get started
[06:02] <doko> evening all
[06:02] <tseng> 'lo
[06:02] <mvo_> hi
[06:02] <mdz> fisrt agenda item is to review the release schedule, and probably make some adjustments. jdub, are you back with Sprite?
[06:03] <mdz> I believe the schedule requires updating to reflect changes to the GNOME 2.10 schedule
[06:04] <mdz> ok, let's skip ahead to the merge process for now
[06:04] <Kamion> and we need to fiddle the CD milestone dates
[06:04] <jdub> it does
[06:04] <mdz> ok, let's not :-)
[06:04] <Keybuk> who wants some cute stats about warty?
[06:04] <mdz> jdub: any changes which we should talk about here?
[06:04] <jdub> http://www.gnome.org/start/2.9/
[06:04] <jdub> mdz: not significant enough, no
[06:04] <jdub> ^ that's the gnome schedule, for the record
[06:04] <jdub> ours just needs tweaking
[06:05] <daniels> fwiw, the proposed gnome schedule: http://www.gnome.org/start/2.9/
[06:05] <Keybuk> jdub: by how much?
[06:05] <jdub> days
[06:05] <mdz> Kamion: I'm happy for you to tweak the CD milestone dates as you feel is appropriate; you might want to wait for jdub's changes though
[06:05] <Kamion> mdz: not in a hurry, just flaggint it
[06:05] <Kamion> flagging
[06:05] <mdz> ok, nothing major in that department, then; we can move on
[06:05] <mdz> to THE MERGE
[06:05] <mdz> elmo: what's the status of the sync infrastructure?
[06:06] <mdz> ...creepy organ music plays...
[06:06] <elmo> mdz: mostly ready - I need two things before I can go:
[06:06] <elmo> a) proper seed lists for hoary
[06:06] <elmo> b) a decision on what, if anything, we're doing about indices files for hoary?
[06:06] <Gmail> am i allowed to say a few comments?
[06:07] <daniels> Gmail: we are talking about the huge merge with sid.  if it is appropriate and on-topic, yes.
[06:07] <ploum>  March 9th: 2.10.0 release! (wow, my birthday :-) )
[06:07] <mdz> Gmail: yes, this is a public meeting, but please try to stay on topic, we have a great deal to discuss
[06:07] <Kamion> Gmail: we're on an agenda here, let's stick to it and have any other business at the end.
[06:07] <mdz> elmo: what sort of indices?
[06:07] <elmo> mdz: Packages/Sources, etc.  there was talk of pw-protecting and/or hiding them at one stage
[06:07] <mdz> elmo: until we have the initial merge sorted out?
[06:08] <jdub> elmo: that was about crack-o-the-day, not hoary
[06:08] <mdz> there may be something to be said for that
[06:08] <elmo> jdub: no, it really was  hoary at one stage.
[06:08] <lamont> elmo: I thought that applied more to grumpy start (at hoary freeze...)
[06:08] <mdz> we really don't know how bad the breakage will be, though
[06:08] <jdub> elmo: it was about hoary while warty was still in devel
[06:09] <mdz> the only compelling justification is so that people don't dive into it when it's known to be severely broken
[06:09] <sabdfl> basic question, do we think people will expect hoary to be sane-if-there?
[06:09] <mdz> which I think it very well could be at the very beginning
[06:09] <Kamion> sabdfl: we've been telling people not to, but I'm sure they will
[06:09] <mdz> sabdfl: perhaps not sane, but installable and not breaking their desktop
[06:09] <fabbione> sabdfl: mostlikely
[06:09] <daniels> sabdfl: you can s/warty/hoary/ now, and apt-get update won't error our
[06:09] <mdz> those who have been warned deserve what they get, but there will be others who have not been warned
[06:09] <elmo> daniels: eh, you'll screw your system
[06:09] <sabdfl> but there's nothing in their system telling them to s/warty/hoary/
[06:10] <sabdfl> it will take longer to get through the pain of merging if we try to keep hoary sane at all times
[06:10] <mdz> elmo: regarding the seed lists, let's use the Warty seed lists; we can update them later
[06:10] <mdz> elmo: we'll need to have a review of the proposed seed changes, and I expect we won't get to it during this meeting
[06:10] <elmo> mdz: ok
[06:10] <Kamion> mdz: are we going to duplicate them in the wiki, or do I not need to change Germinate yet?
[06:10] <Gmail> ok as i goto sleep here are a few ideas: you know you new usplash thing add to it that alt+flock's F1 == alt+F1 it get really anoying on crappy key baords that have f-lock off by default
[06:10] <fabbione> elmo, mdz: please kill anything X related in the seeds, we don't want to merge xfree86 from sid
[06:11] <elmo> fabbione: we won't merge it - it's ubuntu modified
[06:11] <sabdfl> gmail: msg me oob and i'll raise them at the end
[06:11] <mdz> Kamion, elmo: let's continue to use germinate pointing to the Warty seeds
[06:11] <fabbione> elmo: perfect
[06:11] <mdz> so what elmo and I discussed was that his tool would automatically import unmodified packages
[06:12] <mdz> and for modified packages (those with an ubuntu version number), send out a notification
[06:12] <mdz> probably a simple email to start
[06:12] <Keybuk> notification to whom?
[06:12] <mdz> a mailing list seems appropriate
[06:12] <doko> notification of what? resync, or keep it?
[06:12] <mdz> doko: a notification of the fact that it needs review
[06:12] <lamont> and then we either merge, or sync new-debian
[06:12] <Keybuk> http://people.ubuntu.com/~scott/patches/warty/
[06:12] <elmo> mdz and I discussed including the changelog from the debian version, to aid in prioritzation
[06:13] <mdz> then someone will read the changelog, determine if there are changes which have not been merged upstream, and either request a sync of the Debian version (if none), or do a manual merge (if so)
[06:13] <fabbione> wouldn't be better to track it in bugzilla?
[06:13] <Keybuk> ^ that's the set of patches made to warty since Debian-freeze
[06:13] <Keybuk> http://people.ubuntu.com/~scott/patches/debian/
[06:13] <mdz> elmo: yes, that would be great
[06:13] <fabbione> so we are sure of what is done or not?
[06:13] <Keybuk> ^ that's the changes to those packages in Debian since the freeze
[06:13] <lamont> elmo: sweet
[06:13] <mdz> fabbione: we discussed it briefly, it is a possibility
[06:13] <Keybuk> http://people.ubuntu.com/~scott/output/
[06:13] <mdz> I am concerned about generating a huge number of bugs that way
[06:13] <Keybuk> ^ result of merging the two together, with a bunch of rejects to review
[06:13] <Kamion> fabbione: bugzilla feels extraordinarily heavyweight for this, to me
[06:13] <mdz> but we have the tools to do it
[06:14] <fabbione> Kamion: i think it's easier since you go, pickup, kill and so on...
[06:14] <mdz> bugzilla does have the advantage of making it easy to track assignments, so we know if something is being done or not
[06:14] <fabbione> Kamion: otherwise we might lose track of the list
[06:14] <elmo> we're talking about 248 bugs
[06:14] <elmo> just for main
[06:14] <pitti> mdz: and we could also sort out the "who does what" easily in bz
[06:14] <mdz> elmo: let's create bugs automatically for the initial batch at least
[06:15] <elmo> *shrug* k
[06:15] <mdz> we'll need to figure out what to do for the ongoing merges, based on that experience
[06:15] <sabdfl> could equally well be a single wiki page
[06:15] <pitti> sabdfl: where everybody marks the packages he will merge?
[06:15] <pitti> would work, too; maybe easier than bz
[06:15] <elmo> what do we want to do about universe?  the majority of those changes were "make it build" fixes that should be irrelevant - I'm semi-tempted to overwrite, but that may just be me
[06:16] <daniels> doing X could be really interesting -- personally, I'd really like a lock on the repository for 48h to just do X stuff and deal with the fallout, if any.
[06:16] <mdz> let's start with bugzilla, and if it becomes cumbersome, we can switch to something else
[06:16] <mdz> elmo: let's ignore universe for now
[06:16] <elmo> mdz: err.. mmk
[06:16] <elmo> not even sync the unmodified stuff?
[06:16] <mdz> hmm
[06:16] <mdz> sure, why not
[06:16] <fabbione> daniels: no need to. we will use chroots for that
[06:16] <fabbione> daniels: let's discuss it tomorrow
[06:16] <mdz> but we don't want bugs or notifications about the rest of it until we've finished with the initial work for main
[06:17] <elmo> ok
[06:17] <mdz> elmo: what about accessing the morgue?
[06:17] <elmo> mdz: what do you think Scott's been doing?
[06:17] <sabdfl> re universe, are there any changes other than "make it build" changes?
[06:17] <sabdfl> if not, let's just throw open the doors
[06:17] <mdz> elmo: no idea
[06:17] <Keybuk> elmo: I'm convinced he has me on ignore these days <g>
[06:17] <jdub> sabdfl: some resyncs
[06:17] <doko> elmo: can you publish a list of changed packages in universe?
[06:17] <mdz> sabdfl: yes, we've done things like the libtiff transition
[06:17] <elmo> mdz: anyway, it's on rookery, I can make it via http, if you want
[06:17] <jdub> sabdfl: libtiff-- yeah
[06:18] <pitti> sabdfl: I added some RC bug fixes regarding file conflicts
[06:18] <mdz> elmo: what I expect we want for the merge tool is a Sources.gz
[06:18] <sabdfl> did the libtiff stuff not get take upstream?
[06:18] <mdz> elmo: or a bunch of them
[06:18] <pitti> sabdfl: not all of them are already fixed in sid
[06:18] <sabdfl> ok
[06:18] <Keybuk> mdz: what would this merge tool do?
[06:18] <mdz> Keybuk: :-)
[06:18] <mdz> Keybuk: a lower form of magic
[06:18] <elmo> mdz: sure, can create a sources.gz
[06:18] <mdz> just a simple 3-way merge from 1.0-1, 1.0-1ubuntu3 and 1.0-2
[06:18] <Kamion> pitti: I thought almost everything did, it was blocking britney for ages and isn't any more
[06:18] <elmo> might take a day or two, but ;P
[06:18] <sabdfl> if libtiff was a lamont-automated-patch then we can recreate it quickly enough
[06:18] <Keybuk> mdz: ah, yes.  you get http://people.ubuntu.com/~scott/output/ when you do that
[06:19] <mdz> libtiff was
[06:19] <Keybuk> did that over the weekend because I was bored
[06:19] <jdub> sabdfl: (yeah)
[06:19] <mdz> Keybuk: is that from hct?
[06:19] <Keybuk> mdz: no, just low-level magic
[06:19] <jdub> i think sync-and-overwrite in universe is fairly sane
[06:19] <doko> keybuk: hmm, that output is useful for new upstream versions as well?
[06:19] <Keybuk> tla was taking too long
[06:19] <mdz> Keybuk: it has lots of lovely rejects
[06:19] <mdz> Keybuk: what are the numbers like?
[06:20] <Keybuk> mdz: 10,704 "rejects"
[06:20] <Keybuk> around 7,000 of those with same changes on each side
[06:20] <Keybuk> 3,596 left as different changes to both sides
[06:20] <mdz> Keybuk: that's number-of-hunks or number-of-files?
[06:20] <Keybuk> some 2,500 of those in .po files and debian/changelog or debian/control
[06:20] <Keybuk> mdz: number-of-files
[06:20] <lamont> Keybuk: sounds like you need to autodetect same-changes case, eh?
[06:21] <sabdfl> Keybuk: any magic you can bring to the next two weeks will make you friends for life :-)
[06:21] <Keybuk> warty has some 295,004 hunks
[06:21] <sabdfl> we can drop po
[06:21] <Kamion> sabdfl: uh, I think that's a really bad idea for d-i
[06:21] <sabdfl> Kamion: true
[06:21] <Keybuk> 42,680 patched files ... 1,320 patches in 387 packages
[06:21] <daniels> Keybuk: (you can safely exclude xfree86 from that list of number of hunks)
[06:21] <Kamion> sabdfl: we put enormous amounts of effort into the .po branding
[06:22] <sabdfl> right
[06:22] <doko> sabdfl: but not for all of the installer packages (s/Debian/Ubuntu).
[06:22] <sabdfl> right again
[06:22] <Keybuk> yes, I'd like daf to teach us how we merge changes between .po files
[06:22] <Keybuk> because whoeever designed that file format is getting a beating if I ever meet them
[06:22] <doko> use Rosetta?
[06:22] <sabdfl> rosetta gets you faster community translations
[06:23] <sabdfl> but wn't help maintain an effective long-lived branch
[06:23] <Keybuk> Kamion's hunch was right ... it actually is easier to apply the debian changes to warty than try to go back and apply warty's changes to debian
[06:23] <sabdfl> real solution is to parameterise the branding
[06:23] <doko> hmm, I didn't send kamion the script I used for merging the translations ...
[06:23] <Kamion> sabdfl: I spent quite a lot of thought on it and TBH I'm not very convinced that it's possible
[06:23] <sabdfl> parameterisation?
[06:24] <Kamion> at least, not without FAR greater gettext-fu than I possess or have so far seen
[06:24] <Kamion> right
[06:24] <sabdfl> i'll knock on daf's door
[06:24] <daf> Keybuk: what sort of merge? simple join of two PO files, three-way merge between translators or three-way merge with message ID and translator changes or or something else?
[06:24] <sabdfl> better than def's door
[06:24] <Keybuk> daf: three-way merge.  you have original .po and two sets of patches to it
[06:24] <mdz> daf: in  this case it's a 3-way merge with both message ID and translations changed :-)
[06:25] <Keybuk> Kamion: I actually don't see any po/ failures in debian-installer
[06:25] <Kamion> there will be a number of cases where we just have to re-brand, there's no choice
[06:25] <Keybuk> I think it was happy with most of them :o)
[06:25] <Kamion> Keybuk: debian-installer is just the build system.
[06:25] <Keybuk> oh :'(
[06:25] <Kamion> Keybuk: it doesn't HAVE any .po files :-)
[06:25] <Keybuk> bah
[06:25] <fabbione> lol
[06:25] <Keybuk> I broke apart all the patches as well
[06:25] <mdz> Keybuk: so how much of this can we realistically automate?
[06:25] <Keybuk> http://people.ubuntu.com/~scott/patches/warty/
[06:26] <Keybuk> that's each "change" to warty
[06:26] <mdz> if we can get it down to a level where, for the simple case, we can end up with a source package, complete with changelog entry, read for upload
[06:26] <Kamion> for .po files I'm happy to do it by steam for now and gradually automate; I think I've got the majority of the changes there
[06:26] <mdz> that'd be ideal
[06:26] <fabbione> Keybuk: the list isn't complete, is it?
[06:26] <Keybuk> fabbione: packages for which there is both a debian and ubuntu verison in the morgue and debian < ubuntu
[06:26] <Keybuk> (ie stuff we've changed)
[06:26] <Keybuk> though the gnome stuff we can probably ignore, because we *really* changed that <g>
[06:26] <Keybuk> http://people.ubuntu.com/~scott/patches/debian/
[06:26] <daf> Keybuk: what are the two sets of patches?
[06:26] <Keybuk> that's the debian side of it
[06:26] <fabbione> Keybuk: ok
[06:27] <Keybuk> daf: "ubuntu changes" and "debian changes"
[06:27] <mdz> Keybuk: output/ is the result of applying debian/ to warty-current?
[06:27] <sabdfl> yes, gnome, x, we figure we take the lead
[06:27] <Keybuk> mdz: yup
[06:27] <Kamion> daf: Ubuntu changes generally fall into two groups: branding, and minor translation updates from overenthusiastic people who thought we had a good process for translation updates in warty :-)
[06:28] <mdz> Keybuk: <mdz> if we can get it down to a level where, for the simple case, we can end up with a source package, complete with changelog entry, read for upload
[06:28] <mdz> Keybuk: doable?
[06:28] <daf> if you simply have a patch that adds/changes translations, you simply apply the patch, regenerate the .pot file and use msgmerge
[06:28] <Kamion> daf: Debian changes you know
[06:28] <mdz> s/read/ready/
[06:28] <Keybuk> it actually ends up with about 1,000 rej files that need manually checking (3 per package) ... and a lot of those are hopefully simple fixes
[06:28] <Kamion> daf: the patch typically doesn't apply
[06:28] <Keybuk> mdz: well, you still need a human to resolve the case where debian and ubuntu have gone in different directions
[06:28] <mdz> Keybuk: yes, but we have a lot of stuff which should be non-overlapping
[06:29] <daf> Keybuk: ok, you need to find the file the patch applies to, apply it to that and then do further merging with the patched file
[06:29] <daf> arg
[06:29] <daf> s/Keybuk/Kamion/
[06:29] <mdz> the changelog in particular will always conflict due to diff/patch being how they are, but that's something we should be able to consistently resolve automatically
[06:29] <Keybuk> mdz: yeah, need to figure out a trick for that one :)
[06:30] <Kamion> daf: ah, so we unpack the branchpoint package for that
[06:30] <daniels> mdz: you could reasonably trivially write a changelog merge tool tho
[06:30] <daniels> mdz: the only problem is that patch doesn't understand changelog format
[06:30] <sabdfl> hm... changelog.ubuntu, which points into changelog.debian would be easier
[06:30] <jdub> separate ubuntu changelog would be really useful
[06:30] <Kamion> sabdfl: urk, debian/changelog is something understood by all sorts of tools
[06:31] <sabdfl> i'm not sure what the tools would do with that
[06:31] <elmo> hoary's been seeded with woody, and sync's running for non-modified stuff now
[06:31] <daf> in general, I think the method is this: (1) for each patch, apply it to the file it was originally for; (2) call msgcat on all the files to join them all together; (3) regenerate POT; (2) use msgmerge on the results of (2) and (3)
[06:31] <pitti> can we please resolve these technical details later and go on with the agenda?
[06:31] <Keybuk> elmo: did you really mean "woody"? :p
[06:31] <daniels> elmo: woody?
[06:31] <Kamion> it's more useful to users not to have a separate Ubuntu changelog, I feel
[06:31] <mdz> pitti: the technical detail of the merge is significant because it will determine how the work progresses
[06:31] <sabdfl> the changelog problem is one of a general class of problems we'll have to solve for derivatives
[06:31] <elmo> yeah, I thought it'd give us a special old skool flavour
[06:31] <sabdfl> Kamion: think about the general problem, debian->ubuntu->kubuntu
[06:31] <mdz> if we're going to fix up all of the conflicts by hand, we also need to do it consistently
[06:31] <sabdfl> and i don't think a single file can convey it
[06:31] <doko> daf: you need to recode file if the encoding changed
[06:32] <Keybuk> mdz: so yeah, if we can work out a way of automating a given type of conflict, I can put that logic into hct so it can do it automatically later
[06:32] <sabdfl> certainly not one in the current format
[06:32] <Kamion> sabdfl: I know, but I still think it's actively more useful to users to have a single changelog
[06:32] <mdz> Keybuk: yeah, you'll need to do that anyway
[06:32] <daf> doko: urgh, good point
[06:32] <Kamion> sabdfl: I've considered this fairly carefully ...
[06:32] <sabdfl> Kamion: or a tool which presents it that way
[06:32] <mdz> Kamion: we'd need a changelog format which could represent branches meaningfully
[06:32] <jdub> i find it a pain to maintain ubuntu+debian packages
[06:32] <mdz> which would probably require version numbers which can represent branches meaningfully
[06:32] <daf> there are disadvantages to using msgcat, though
[06:32] <mdz> which is a ways off :-)
[06:32] <Kamion> mdz: nah, I have a suggestion I'll feed you offline
[06:33] <fabbione> sabdfl: changelog is used also to build the package itself. it's not a good idea to fiddle with it too much
[06:33] <Keybuk> mdz: /debian/changelog.rej and /ChangeLog.rej I'm tempted to just do by stripping the context and applying them at 0,0 -- that usually "works" :o)
[06:33] <pitti> With my recent merges, I packaged every ubuntu change as a debian/patches/ubuntu- patch, took the pristine Debian package and documented the Ubuntu patches in the changelog
[06:33] <mdz> Keybuk: apart from being out of order
[06:33] <Kamion> Keybuk: better to merge changelogs in version order if possible ...
[06:33] <daf> Keybuk: I'd be interested to hear your thoughts on a file format that would be better than PO (even if they only relate to making diffs work better)
[06:33] <pitti> This was quite a bunch of work, but it is very clean
[06:33] <sabdfl> i understand that the toolchain uses it heavily, but part of our hoary goal is to generalise the platform for derivatives, and that will mean touching the toolchain
[06:33] <Keybuk> mdz, Kamion: I've applied debian to warty, not the other way around
[06:33] <mdz> pitti: yes, that works when the package is already using dpatch
[06:33] <Keybuk> it's the debian changelog entries conflicting
[06:34] <Keybuk> so putting those at the top *does* put them in order
 <new debian> <warty> <old debian>
[06:34] <jono> hi all
[06:34] <mdz> Keybuk: no, it doesn't
[06:34] <pitti> mdz: for dpatch/cdbs packages this is actually very nice
[06:34] <pitti> mdz: so we could do it for packages supporting it
[06:34] <Keybuk> moving warty to the top actually takes the changelog out of version order
[06:34] <mdz> Keybuk: the correct order could be something like <old debian> <less old debian> <old ubuntu> <current debian> <current ubuntu>
[06:34] <Kamion> sabdfl: I don't think separating the changelogs out is the right answer, though; the nCipher changelog format would be better (it documents branches inline), and I'll suggest something like that when we're not in a meeting
[06:34] <Keybuk> mdz: that's the order we're going to get
[06:35] <mdz> Keybuk: ah, if you do the merges in version number order, yes
[06:35] <mdz> wait, no
[06:35] <Keybuk> mdz: *nods* :)
[06:35] <mdz> you'd need to do them in date order
[06:35] <sabdfl> Kamion: ok, sounds good
[06:35] <daniels> mdz: surely version order is more meaningful?
[06:35] <Kamion> sabdfl: (this would also have benefits for things like BTS version tracking)
[06:35] <mdz> daniels: it gets weird
[06:36] <daniels> mdz: it more accurately represents the branches, though
[06:36] <pitti> daniels: but you cannot really sort 2.0-0ubuntu1 and 2.0-1
[06:36] <mdz> version order leaves us with something that makes more sense in and of itself :-)
[06:36] <pitti> daniels: either one may happened sooner or later
[06:36] <Keybuk> mdz: tomorrow afternoon UK, I can give you a collection of source packages with changelog and anything else I can obviously do automatically resolved
[06:36] <daniels> mdz: if you do it in date order, you'll end up with confusion because stuff that got changed in debian, wasn't in ubuntu at that stage
[06:36] <Keybuk> each one will be accompanied by a "this fell out" patch which will need manual review
[06:36] <mdz> Keybuk: great
[06:36] <Keybuk> and if we find ways of automatically doing that review, then I want to know about it to write code to do that next
[06:36] <sabdfl> ok, i think we can take this discussion out of band
[06:37] <mdz> ok
[06:37] <Keybuk> the total lines of "this fell out" are pretty tiny, around 3,000 in total
[06:37] <mdz> initial merge strategy is to let Keybuk lock himself in a room for a day
[06:37] <mdz> and then create bugs on the remainder
[06:37] <Keybuk> which given nearly a million lines of changes is pretty good <g>
[06:37] <Keybuk> (ignoring .po files, which are evil, evil, evil)
[06:37] <mdz> if the remainder is small enough, we'll just do it by hand
[06:37] <sabdfl> great
[06:37] <mdz> eek, we do need to resolve that .po issue
[06:37] <azeem> this whole problems smells like an application for that conary package thingy, which reportedly handles branches, patches and merges pretty well
[06:38] <Keybuk> daf: not putting a changing line number right before the bit that changes would be swell
[06:38] <jdub> azeem: ssshhh, be wery, wery quiet.
[06:38] <mdz> ok, onward to feature goals
[06:39] <mdz> let's take it from top to bottom
[06:39] <mdz> and for each item, determine whether it makes most sense for one of us to do it, or see if someone else listening would like to volunteer
[06:40] <mdz> first item is UTF-8, which is a bit of amorphous
[06:40] <mdz> we'll set UTF-8 by default early in the release cycle, and just fix whatever breakage comes up
[06:40] <mdz> it's really a bunch of unclassified bugs at this point, rather than a feature
[06:40] <Keybuk> yeah, I've been running utf-8 for a couple of years now; zsh is about the only breakage I notice
[06:40] <pitti> I have UTF-8 running for very long now, works nice for most parts
[06:40] <mdz> what will we do about existing Ubuntu installations?
[06:41] <mdz> leave them at non-UTF8, send out an announcement asking them to change?
[06:41] <fabbione> mdz: wiki -> utf8 howto ?
[06:41] <pitti> would make most sense
[06:41] <doko> changing the default from ISO to UTF8 on upgrade?
[06:41] <Keybuk> Kamion: what does debconf do in this situation?
[06:41] <mdz> fabbione: we should supply a script I think
[06:41] <sivang> add something to ubuntu-desktop to do that? :)
[06:41] <pitti> changing ~/.profile files on upgrading would be hell
[06:41] <Keybuk> first install the question was too low a priority to get asked
[06:41] <mdz> which handles generating locales and setting the default
[06:41] <Keybuk> what happens if the value is different on the update
[06:41] <Kamion> Keybuk: which?
[06:41] <Keybuk> does it keep the old or go with the new?
[06:41] <jdub> mdz: shouldn't we switch as part of the upgrade, so systems are consistent by default?
[06:41] <enrico> make an application to handle post-upgrade configuration issues?
[06:41] <mdz> jdub: changing the locale on the user sounds fairly evil
[06:42] <mdz> enrico: something more like that, yes
[06:42] <fabbione> i wouldn't go for automatic changes of that level
[06:42] <doko> mdz: we don't change the locale, but the encoding
[06:42] <enrico> Like one runs that and gets a TODO-list of things to check
[06:42] <Kamion> Keybuk: it's got a value already, it keeps it unless told otherwise
[06:42] <mdz> doko: that is a locale setting
[06:42] <elmo> yeah, that's like spitting on the golden rule thing
[06:42] <Keybuk> Kamion: and a dpkg-reconfigure locales would change to the new value?
[06:42] <pitti> mdz: we can't change the encoding automatically; this would break _every_ text file the user created
[06:42] <sabdfl> jdub: golden rule
[06:42] <Kamion> Keybuk: no
[06:42] <mdz> pitti: we are in agreement
[06:42] <Keybuk> or do you have to nuke out config.dat ?
[06:42] <Kamion> Keybuk: EVIL EVIL EVIL
[06:42] <seb128> if we change the system locale, what will happen with filename ?
[06:43] <mdz> we will provide a tool which the user can run which will DTRT
[06:43] <sivang> pitti is right. why wasn't it set at UTF8 from first place?
[06:43] <mdz> who will write it?
[06:43] <jdub> sabdfl: not a user chosen setting :)
[06:43] <seb128> we need to convert the filesystem ?
[06:43] <pitti> sivang: because there are still some bugs
[06:43] <mdz> sivang: bugs
[06:43] <seb128> filenames even
[06:43] <sivang> oh
[06:43] <Kamion> we should make sure that UTF-8 is generated where possible, but I'm very leery of changing the default for existing installations
[06:43] <sabdfl> i think this falls into the category of things that new installations get by default, upgrades get if they themselves do it
[06:43] <sabdfl> Kamion: agreed
[06:43] <jdub> yeah
[06:43] <pitti> sabdfl: agreed
[06:43] <Keybuk> enrico: GNOME does UTF-8 filenames whatever charset you're in, I think
[06:43] <mdz> Kamion: will you write the utf8-enabler tool?
[06:44] <pitti> Autodetecting the existing encoding of an ASCII file is practically impossible
[06:44] <sabdfl> we will have a good "release notes" and "upgrade notes" which can document this
[06:44] <Kamion> mdz: can do, yeah
[06:44] <enrico> Keybuk: even on things like BIG5 VFATs?  (it would create illegal names)
[06:44] <mdz> ok, great
[06:44] <mdz> and the bugs we'll fix as they come
[06:44] <mdz> next is a big one
[06:44] <Kamion> pitti: autodetecting the existing encoding of an *ASCII* file is trivial ... :-)
[06:44] <mdz> unified hardware detection
[06:44] <ogra> will there be any iso support in the apps left ?
[06:44] <seb128> Keybuk: nautilus does, but a lot of files are created out of nautilus ...
[06:44] <pitti> Kamion: okay, but you don't need to change them anyway
[06:44] <daniels> mdz: i would kill to move off discover1
[06:44] <sabdfl> ogra: yes, aiui
[06:45] <mdz> ogra: yes, we won't try to remove support for non-utf8 encodings
[06:45] <pitti> Kamion: but take a look at my ~, there are thousands of files with different encodings; some already in UTF-8, some in LATIN9, etc.
[06:45] <sabdfl> by unified we mean:
[06:45] <sabdfl>  - installer
[06:45] <sabdfl>  - installed system
[06:45] <sabdfl>  - live cd
[06:45] <mdz> right
[06:45] <Kamion> pitti: (you said ASCII, not text)
[06:45] <daniels> sorry, my bad.
[06:45] <mdz> currently those use: discover1, hotplug and knoppix, respectively
[06:45] <pitti> Kamion: whoops
[06:45] <mdz> my position is that hotplug is the way forward for all three
[06:46] <daniels> yes
[06:46] <Keybuk> I guess hotplug is the target for unification
[06:46] <sabdfl> in addition there's the layer of intelligence above the detection tools
[06:46] <daniels> however, currently discover1-data has by far the most accurate hardware list, afaik
[06:46] <sabdfl> for example, x resolution and refresh
[06:46] <fabbione> we might still need discover for X
[06:46] <Kamion> ok, hotplug is one of the post-sarge goals for d-i
[06:46] <Kamion> we can move forward on that ourselves, given udev-udeb and hotplug-udeb packages
[06:46] <mdz> fabbione: yes, I consider X a separate issue
[06:46] <fabbione> mdz: ok
[06:46] <mdz> this one is purely kernel stuff
[06:46] <rburton> doesn't discover load a few drivers which hotplug doesn't?
[06:46] <Kamion> hotplug doesn't do X stuff, so discover is still needed for that, but that's OK
[06:47] <sabdfl> mdz: but we'll still need to unify the live cd x detection with the installer
[06:47] <mdz> rburton: installed Ubuntu has been using hotplug exclusively for some time now
[06:47] <sivang> rburton : this is what I was once told by joeyh
[06:47] <mdz> sabdfl: yes, I think we should consider that separately as well
[06:47] <pitti> daniels: does hotplug have hw lists at all? I thought it just uses the modules file from the kernel
[06:47] <bob2> pitti: purely from the kernel
[06:47] <rburton> mdz, ah ok
[06:47] <Kamion> pitti: yes, modules.pcimap
[06:47] <sabdfl> it's fundamental to the feature goal
[06:47] <sivang> rburton : experimenting with that backed up his statement.
[06:47] <bob2> isn't that generated from the kernel?
[06:47] <sivang> (on sid)
[06:48] <daf> Keybuk: yeah, that would help
[06:48] <daniels> sabdfl: tbh I haven't even looked at the live CD's autodetection, but that's one of the things we can look at
[06:48] <lamont> and then for grumpy eliminate the "separate but equal" (X vs kernel)?
[06:48] <sabdfl> sound, video, webcam, modem, network
[06:48] <Kamion> I'm happy to do the hotplug d-i integration, but does anyone know udev and hotplug well enough to produce udebs?
[06:48] <Keybuk> pitti: if the kernel doesn't know a module can be used with a given id, it's a lost cause trying to load it *anyway*
[06:48] <sabdfl> i'd like to be using the same codepaths for all of them
[06:48] <mdz> Kamion: should be easy
[06:48] <Kamion> (I don't; I looked briefly before warty released, and got lost)
[06:48] <mdz> hotplug is just a bunch of scripts
[06:48] <lamont> Kamion: I expect creating udeb's wouldn't be _that_ difficult, no?
[06:48] <pitti> Keybuk: right; at the time I typed this question I still thought we want to use it for X :-/
[06:48] <mdz> udev isn't much more
[06:48] <mdz> Kamion: I'll lend a hand with that
[06:48] <Kamion> lamont: it's not hard, just a question of knowing the package really
[06:49] <Kamion> mdz: thanks
[06:49] <lamont> ah, ok
[06:49] <mdz> fabbione: I know you have some ideas about the way forward for X autodetection
[06:49] <Kamion> Keybuk: that's not always true
[06:49] <mdz> fabbione: what is the right way to unify it between the live CD and the installed system?
[06:49] <fabbione> mdz: yes
[06:49] <Kamion> can I just flag up buses that aren't hotplug-enabled, too
[06:49] <Kamion> the mac-io bus on powermacs is the big one
[06:49] <mdz> Kamion: I have a patch for that
[06:49] <Keybuk> isn't that enabled yet?
[06:49] <Kamion> mdz: what, to the kernel?
[06:49] <Keybuk> I thought that was floating
[06:49] <mdz> Kamion: yes
[06:49] <Kamion> mdz: cool
[06:50] <sabdfl> very
[06:50] <fabbione> mdz: i can simply create a script that simulate an installation to detect the hardware as i do in the normal installation and create a live config
[06:50] <mdz> we can stage it for upstream
[06:50] <Kamion> we'll still have the installer's register-module facility available for corner cases
[06:50] <mdz> fabbione: so we would change morphix to invoke something which would trigger the debconf magic, rather than using the knoppix stuff
[06:50] <fabbione> mdz: correct
[06:50] <sabdfl> fabbione: can we shift the x scripts to python please?
[06:51] <amu> i think rewriting live-hwdesting using discover/hotplug is not such diffifult, timeuseage is very high
[06:51] <fabbione> sabdfl: no
[06:51] <sabdfl> fabbione: why not?
[06:51] <mdz> amu: it should just be a matter of calling /etc/init.d/hotplug start, if we do our work correctly
[06:51] <sabdfl> mdz: plus the config layer
[06:51] <Kamion> sabdfl: .config scripts can only use Essential: yes packages safely
[06:51] <mdz> sabdfl: config layer? for hotplug?
[06:51] <sabdfl> Kamion: see further down the list :-)
[06:52] <fabbione> sabdfl: because it is too much rework and as i was telling you a couple of days back i understimated the load to switch to x.org
[06:52] <sabdfl> mdz: for eg sound config
[06:52] <fabbione> sabdfl: so i much rather keep what we can from Xfree86
[06:52] <Kamion> sabdfl: diverging from Debian on something as big as the X .config script is busy-work, surely?
[06:52] <mdz> sabdfl: we should use all of the stock Ubuntu stuff for that
[06:52] <amu> mdz: with cdbackup it works
[06:52] <sabdfl> detecting the card is one thing, setting appropriate levels etc
[06:52] <Kamion> sabdfl: also, upgrades
[06:52] <sabdfl> Kamion: i'm trying to standardise skill sets, which will pay off for us as a team later
[06:52] <Kamion> sabdfl: I know, but Essential is a very hairy place
[06:53] <mdz> the other issue is that python is huge for an essential package
[06:53] <sabdfl> understood, having python there is not something i'm going to budge on
[06:53] <Keybuk> sabdfl: the issue comes where Python has to be installed, configured and completed before *any* package using it is installed
[06:53] <sabdfl> python-base
[06:53] <Keybuk> so it gets a bit hairy
[06:53] <mdz> sabdfl: the python guys will scream if we split up the standard library further :-)
[06:53] <sabdfl> the python guys will be thrilled that python has become Essential
[06:53] <jdub> ooof, which bits would you choose for python-base, too...
[06:54] <doko> we had the split once in Debian. there are no clear lines where to split it. but that further down the list.
[06:54] <sabdfl> as for scchnnnaaakkee...
[06:54] <fabbione> sabdfl: we are going to deal with a new upstream and that will be already hell of a job. perhaps we can reconsider it for hoary+1, but i am not too crazy to do it now
[06:54] <Kamion> will they? they weren't so thrilled about distutils not being there ...
[06:54] <sabdfl> fabbione: no, since we are creating these packages from scratch, i'd like to do it right the first time
[06:54] <Kamion> I don't think they'd be happy unless the standard library's in one piece
[06:54] <sabdfl> Kamion: it will be, post install
[06:54] <Kamion> sabdfl: in some configurations ... :)
[06:55] <Keybuk> sabdfl: but then you can't use any of the Python standard library in Python scripts in packages
[06:55] <Keybuk> sabdfl: and Python is pretty useless without its standard library :(
[06:55] <doko> keybuk: depends which modules and extensions you compile in statically
[06:55] <sabdfl> ok, separate discussion, i dont mind really, just do mind that python is in essential for ubuntu
[06:55] <sabdfl> and that we use it for all system functions unless there's a bollocking good reason not to
[06:55] <Keybuk> (personally, I'd like to kick perl out of Essential :p)
[06:56] <Kamion> sivang: Essential's a technical category
[06:56] <mdz> ok, the current unresolved item is the unification of hardware detection
[06:56] <mdz> we can either do this as one task, or break it down
[06:56] <mdz> Kamion said he would do the hotplugification of d-i
[06:56] <sabdfl> mdz: i think we're all agreed on hotplug for device detection
[06:56] <sabdfl> amu: live cd
[06:56] <mdz> so the remainder is live CD work
[06:56] <mdz> amu: ?
[06:57] <jdub> mdz: can we put someone in charge of that goal in general?
[06:57] <mdz> jdub: I will take responsibility for tracking the sub-tasks
[06:57] <jdub> that was easy ;)
[06:57] <mdz> fabbione: what is your opinion about dynamic X reconfiguration at boot, to detect hardware changes?
[06:57] <amu> hmm good question, therorethically it should work
[06:58] <fabbione> mdz: i have some ideas already in that direction
[06:58] <mdz> fabbione: that would bring the live CD and the installed system in line with each other
[06:58] <fabbione> mdz: and a possible solution
[06:58] <mdz> nd we will need it for a gui installer asa well
[06:58] <fabbione> mdz: that will come after X.org is out
[06:58] <mdz> fabbione: hoary?
[06:58] <fabbione> mdz: probably
[06:58] <Kamion> mdz: we don't need that for a GUI installer
[06:58] <sabdfl> kernelfb?
[06:58] <Kamion> right
[06:58] <Kamion> gtk+directfb
[06:58] <mdz> ok
[06:58] <daniels> mdz: it's difficult to do that without crapping all over user changes
[06:58] <fabbione> mdz: i am boiling the idea. i need to see with daniel if it's possible
[06:58] <mdz> well, in both cases we need _something_ which works at boot
[06:58] <daniels> yes, X is too heavy for a GUI installer and a bootsplash.
[06:59] <jdub> daniels: not for the installer
[06:59] <fabbione> mdz: hold on a sec. we are confusing 2 things here
[06:59] <mdz> daniels: we could do it only if X fails to start
[06:59] <jdub> X is a good option for the installer
[06:59] <daniels> gui installer is directfb domain, imho, and bootsplash is mad phat splash's area
[06:59] <Kamion> jdub: not convinced
[06:59] <fabbione> one thing is configuring X at boot time for liveCD
[06:59] <mdz> ok, let's leave the gui installer discussion for another time
[06:59] <jdub> Kamion: easier to deal with than gtkfb or directfb
[06:59] <fabbione> and one is autoconfiguring it for the normal installation
[06:59] <mdz> we're talking about unifying X config between the live CD and the installed system
[07:00] <fabbione> mdz: ok. i have already a solution for that. and yes it will be hoary
[07:00] <mdz> I think there is overlap between that, and dealing with hardware changes in the desktop
[07:00] <Kamion> jdub: directfb just comes up and just works, no effort whatsoever; I don't see how X could be easier
[07:00] <fabbione> jdub: Kamion is right
[07:00] <fabbione> jdub: X will only bring problems
[07:00] <daniels> (my parting shot: the framebuffer very rarely goes wrong -- like, ever; however, looking at the list, X autodetection is harder)
[07:00] <sabdfl> mdz: at the very least, it would be possible to store a set of "detected values", and see if that has changed from one boot to the next, and prompt for reconfig
[07:00] <daniels> anyway, yeah, unifying the config from livecd to ubuntu is hoaryable
[07:00] <mdz> fabbione: ok, so you will take care of moving the live CD X configuration over to use our config system rather than knoppix
[07:01] <sabdfl> i agree the gui installer is more directfb territory
[07:01] <fabbione> mdz: if i get the resources yes.
[07:01] <jdub> daniels: (using fb doesn't rule out X...)
[07:01] <ogra> what about kdrive ?
[07:01] <mdz> sabdfl: let's treat the live CD piece of it as part of the unification goal, and the reconfigure-on-hardware-change as a separate feature?
[07:01] <sabdfl> fabbione: you will, it's a priority, in python
[07:01] <fabbione> mdz: when i offered my help for the livecd, my ping was lost
[07:01] <daniels> ogra: awful hardware support
[07:01] <sabdfl> mdz: yes, that's what i was suggesting
[07:01] <ogra> daniles: vesa ?
[07:01] <daniels> ogra: not an option
[07:01] <ogra> k
[07:01] <fabbione> sabdfl: sorry.. i lost the contest...
[07:02] <sabdfl> have a tool that looks at a store of "what was previously detected" and sees if that has changed
[07:02] <sabdfl> fabbione: you will get the resources to unify live cd and installer x config in python
[07:02] <mdz> fabbione: contest?
[07:02] <fabbione> sabdfl: ok
[07:02] <fabbione> mdz: typo
[07:03] <fabbione> sabdfl: but that will kill the plan to configure X at debian-installer time
[07:03] <fabbione> sabdfl: that is something that we can probably do for hoary
[07:04] <mjg59> sabdfl: One issue with using directfb for the installer is that someone needs to write an accessibility interface for directfb/atk then
[07:04] <mdz> fabbione: we don't need to configure X at debian-installer time; the current timing is OK for hoary
[07:04] <mdz> mjg59: good call
[07:04] <mjg59> X gives you already working a11y infrastructure
[07:04] <Kamion> mjg59: text mode + speakup might make more sense for hoary
[07:05] <sabdfl> mjg59: hmm... can we run x on directfb?
[07:05] <mdz> however, using X in the installer would seem to be in conflict with Kamion's idea to support floppy installs :-)
[07:05] <rburton> mailq
[07:05] <mdz> sabdfl: yes
[07:05] <mdz> sabdfl: well, on fb
[07:05] <mjg59> Kamion: Speakup requires extra hardware, doesn't it?
[07:05] <sabdfl> and we still have fall-back to text mode
[07:05] <Kamion> mjg59: well, yeah, depends on the kind of a11y
[07:05] <mdz> at present, GUI installer is not on the hoary list
[07:06] <mdz> and we have many more items to review which are
[07:06] <jdub> um
[07:06] <mdz> so can we table that discussion for now?
[07:06] <sabdfl> yes
[07:06] <jdub> gui installer is on the hoary list, but it has sabdfl's question mark
[07:06] <sabdfl> i won't commit to having a gui installer for hoary
[07:06] <sabdfl> it will back us into a corner
[07:06] <mdz> ok
[07:06] <sabdfl> i've no problem with starting work on it
[07:07] <mdz> I propose that we not attempt ppc64 for hoary
[07:07] <mdz> there is currently no real vacuum for it to fill
[07:07] <sabdfl> mdz: won't attempt any further arch's unless a community team steps up
[07:07] <mdz> and it is a multiarch-wanting arch too
[07:07] <sabdfl> if one does, we'll provide h/w
[07:07] <doko> yes, that would need a toolchain update
[07:07] <mdz> ok, consider it moved
[07:08] <mdz> " LSB compliant i386 libraries on amd64"
[07:08] <mdz> doko: this is 32-bit compatibility?
[07:08] <doko> yes
[07:08] <mdz> what does it entail?
[07:08] <elmo> we'll need to do enough of ppc64 for G5 support, tho, right?
[07:08] <elmo> [sorry, I'm late]
[07:08] <mdz> elmo: I expect we'll build a ppc64 kernel for the powerpc arch
[07:08] <elmo> ok, cool
[07:09] <mdz> noted in bugzilla and discussed with herbert
[07:09] <elmo> it'd suck to not support our own buildds ;-)
[07:09] <mdz> hey, we have our own h4x0red kernel for that
[07:09] <Kamion> yeah, ppc64 kernel != ppc64 userspace
[07:09] <mdz> elmo: you love custom kernels :-P
[07:09] <sabdfl> nonetheless, elmo has a point
[07:09] <mdz> doko: so what exactly would be involved in implementing this feature?
[07:10] <mdz> I assume this would only provide basic support for compiling and running 32-bit apps
[07:11] <mdz> since we are not going to do multiarch in the packaging system for hoary
[07:11] <sabdfl> do they get a limited set of 32-bit libs to work with?
[07:11] <sabdfl> is this how we currently do mozilla and oo.o?
[07:11] <mdz> so that means a bi-arch gcc, and ia32-libs
[07:11] <mdz> sabdfl: yes, that's ia32-libs
[07:11] <dieman> heh, ubuntu is on /. again
[07:12] <doko> hmm, thought that this is Tollef's domain? See #277852 for a current discussion, if/what is needed for proper i386 support. needed: a working biarch toolchain, agreement where to put the ia32 libraries
[07:12] <mdz> if there is not yet agreement, then this is not something we should push for hoary
[07:12] <mdz> the mention of LSB seems to imply that there is a standard
[07:12] <mdz> Mithrandir is not here
[07:13] <mdz> let's skip this item for now
[07:13] <doko> wether ia32-libs is a good idea? some libs already have biarch support like ncurses, readline, etc. so maybe just add to these libraries the 32bit things.
[07:13] <mdz> doko: sabdfl would like an essential python package
[07:14] <ogra> regarding the support side on amd64 , there should be a home for things like flash......
[07:14] <mdz> doko: is there anything in the current python2.3 package which could be split in order to simplify it?
[07:14] <mdz> ogra: I think the only way to support i386 flash is to have an i386 firefox, which we don't want to do
[07:14] <doko> yes, I looked back at the point where we had split it.
[07:14] <ogra> mdz: oh..... the peole are crying a lot about flash...
[07:15] <mdz> doko: there seems to be a fundamental conflict between providing the full python standard library, and having it be essential
[07:15] <doko> codecs maybe make up a bit of code size, standard libraries which you don't need at a point of time... I'd prefer to have some use case for what we want with python at that point and then define the split.
[07:15] <doko> should this essential python work without /usr?
[07:15] <mdz> doko: perhaps we could provide all of the pure python stuff
[07:16] <mdz> doko: good question
[07:16] <Keybuk> perl-base works without /usr
[07:16] <Keybuk> uh
[07:16] <Keybuk> sorry
[07:16] <mdz> no it doesn't :-)
[07:16] <Keybuk> perl-base DOESN'T work without /usr
[07:17] <sabdfl> doko, mdz, let's figure out the implementation separately
[07:17] <mdz> ok
[07:17] <doko> why stop at pure, and don't have the zlib module? this line is artificial.
[07:17] <doko> ok
[07:17] <mdz> " Raise default dpkg-reconfigure priority, adjust packages as necessary?"
[07:17] <mdz> we already did that for warty
[07:17] <sabdfl> :-)
[07:17] <Keybuk> yeah, isn't that High already?
[07:17] <Kamion> dpkg-reconfigure != debconf
[07:17] <Kamion> dpkg-reconfigure's default priority is low
[07:17] <mdz> ohh, right
[07:17] <sabdfl> ah
[07:17] <Kamion> what's the use case for raising it?
[07:17] <Kamion> dpkg-reconfigure asks all questions by design
[07:17] <mdz> Kamion: to make it more useful
[07:17] <sabdfl> yes that causes the "million spurioous questions on reconfigure" experience
[07:18] <Kamion> mdz: that would make it less useful, actually
[07:18] <mdz> "all questions" is too many questions
[07:18] <Kamion> sabdfl: reconfigure is a deliberate choice, though
[07:18] <sabdfl> Kamion: those who want the full question set can ask for it
[07:18] <Kamion> people WANT to see all questions :-)
[07:18] <Kamion> (if they run dpkg-reconfigure)
[07:18] <sabdfl> if they do, --priority=low
[07:18] <mdz> Kamion: when we tell an Ubuntu user to run dpkg-reconfigure, they don't want to see all questions
[07:18] <Keybuk> mdz: why would we tell a user to do that?
[07:18] <sabdfl> reconfigure says "give me the same set of questions again"
[07:18] <mdz> Keybuk: because it is often the simplest way to solve their proble
[07:18] <mdz> m
[07:19] <sabdfl> Keybuk: i think we will aim to provide a high level UI for that
[07:19] <sabdfl> for example, inside aptitude, press a key to reconfigure a package
[07:19] <Kamion> ok, don't think it should be as high as --priority=high though, medium feels better
[07:19] <doko> sorry, a bit late: is python2.4 default for hoary?
[07:19] <sabdfl> and the questions should be the same as the questions on install
[07:19] <mdz> Kamion: yes, I think medium is appropriate
[07:19] <mdz> Kamion: the idea is to exclude the "control freak" questions
[07:19] <mdz> and just give them a basic level of configurability
[07:19] <Kamion> sabdfl: that just doesn't work with a lot of debconf scripts though
[07:19] <mdz> which is what medium should be
[07:19] <Kamion> mdz: right, agreed
[07:20] <sabdfl> Kamion: because they assume you've answered the question already?
[07:20] <mdz> reconfigure should ask more questions than at install
[07:20] <mvo_> sabdfl: synaptic support reconfigure via debconf (through the gnome debconf ui)
[07:20] <mdz> because install should exclude questions which have a reasonable default
[07:20] <Kamion> sabdfl: varies; they'll certainly often have different behaviour. debconf's arbitrarily scriptable
[07:20] <sivang> what's the profile of an average Ubuntu user anyway? what can we expect of them?
[07:20] <sabdfl> i think we are asking for users to go from b0rked to v87686ked
[07:20] <mdz> but reconfigure should ask questions which have a reasonable default, and give the user the opportunity to change them
[07:20] <Kamion> mdz: YES :-)
[07:20] <Keybuk> sivang: ideally we don't have one; Ubuntu works for all users, not just the average one
[07:21] <sabdfl> hold on
[07:21] <sabdfl> how do you tell a user "you answered the wrong way at install, do this, and answer it differently"
[07:21] <mdz> sabdfl: Kamion and I seem to be in agreement that what we want here is a default dpkg-reconfigure priority of 'medium'
[07:21] <sabdfl> that's fine, if i can see a list of new questions that introduces :-)
[07:21] <sivang> wouldn't it be wise to think up one, and then target it, and decide priorites by it (debconf)? surely we cannot target each and every user profile which might arise..
[07:21] <Kamion> if we made it 'high', it would often end up asking fewer questions, which I think would be worse
[07:22] <mdz> sabdfl: that is a problem of unsolvable complexity, I fear :-)
[07:22] <jdub> sivang: (this is slightly more abstract than that)
[07:22] <Kamion> we can attempt to produce one for base+desktop, probably
[07:22] <sabdfl> kamion: i'd like to really define the set of questions that a user is ever likely to see
[07:22] <mdz> it varies depending on arbitrary criteria
[07:22] <fabbione> mdz: i don't have a very strong opinion on raising to medium, but i think changing it will create some kind of extra debugging work for the users when we have to ask to reconfigure with --priority=low
[07:22] <sivang> or maybe let them choose the profile, and configure debconf accordingly ? (please excuse me if this is all babble)
[07:23] <mdz> sabdfl: do you agree that reconfiguration should ask a different set of questions than at initial install, given that our goal for many packages (all of deskop) is that they not ask any questions at initial intsall?
[07:23] <sabdfl> in fact, i don't mind if we do this, but it means i'm going to have to review every single "medium" question
[07:23] <Keybuk> to be honest, I think I tend towards defaulting to --default-priority; as that's generally unsurprising
[07:23] <Kamion> Keybuk: but will generally mean dpkg-reconfigure does absolutely nothing
[07:23] <mdz> Keybuk: that does nothing in most cases
[07:23] <Kamion> I don't think taking a useful command and turning it into a no-op is good
[07:24] <sivang> why not having it low priority install time, and raise it automatically on reconfigure? (assuming this requests for more control)
[07:24] <Kamion> sabdfl: maybe we shouldn't be recommending dpkg-reconfigure in general ...
[07:24] <sabdfl> ok, let's go with medium, but then you guys are going to have to put up with a lot of bugs from me in that regard :-)
[07:24] <Keybuk> it still does the effect of the settings, as in postinst?
[07:24] <mdz> this change falls under the heading of stuf that we should change early
[07:24] <sabdfl> Kamion: need some tool to do it
[07:24] <mdz> so that we can catch as much of the fallout as possible through routine testing
[07:24] <sabdfl> yes
[07:24] <sabdfl> sigh
[07:24] <Keybuk> mdz: yeah, first thing type change
[07:25] <Kamion> sabdfl: or, at least, for a very limited set of packages, like xserver-xfree86
[07:25] <mdz> sabdfl: I think most of those bugs will be trivial ones
[07:25] <sabdfl> Kamion: could you produce a script to mail me all of the questions in debconf, for main/restricted packages, that would be visible at medium or higher priority
[07:25] <mdz> sabdfl: things which are medium and should be low
[07:25] <mdz> sabdfl: the worst of it will be that we need to rewrite some text for the questions
[07:25] <sabdfl> mdz: yes, we will need to, guaranteed
[07:25] <Kamion> sabdfl: ok, will try
[07:25] <sabdfl> Kamion: tvm
[07:25] <mdz> Kamion: as long as you're taking on work, will you be the one to upload debconf with the default priority change for dpkg-reconfigure?
[07:26] <Kamion> (sometimes priorities are programmatically determined, so it may be fun)
[07:26] <Kamion> mdz: yeah, that's easy
[07:26] <mdz> Kamion: it'll be on the list of things to break early, with your name next to it
[07:27] <mdz> moving on
[07:27] <mdz> SE Linux
[07:27] <jdub> let's dump it
[07:27] <mdz> this is a highly specialized project
[07:27] <pitti> I would really like to see some easy support for MAC
[07:27] <mdz> I don't think we need to do it in-house, but I would love to see a proof of concept from a third party
[07:27] <Keybuk> if we want SE Linux, we need someone who knows all about it
[07:27] <pitti> grsecurity/SELInux/RSBAC/Whatever
[07:27] <sivang> Kamion : any example ?
[07:27] <mdz> Keybuk: agreed
[07:27] <jdub> yeah
[07:27] <Keybuk> from what I can tell with my chats with them, there's an arch-like learning curve to it
[07:27] <doko> pitti: MAC?
[07:27] <pitti> Do we really want SELInux support?
[07:28] <sabdfl> it's going to be a user nightmare if we fiddle with selinux
[07:28] <pitti> doko: Mandatory Access Control
[07:28] <thom> doko: mandatory access control
[07:28] <mdz> sabdfl: it strikes me as something to do as a derivative
[07:28] <pitti> Apart from the fact that SELInux is in upstream kernel, it is very complicated
[07:28] <jdub> we just won't have the cycles to do it propery for hoary
[07:28] <mdz> sabdfl: and then fold in once it is shown to work
[07:28] <sabdfl> mdz: good call
[07:28] <jdub> mdz: agree
[07:28] <jdub> seubuntu
[07:28] <Keybuk> and there's probably at least 6 months work on dpkg before it can even support it as well
[07:28] <pitti> We should develop it in Hoary time and publish it in grumpy
[07:28] <thom> yeah. fedora seem to be having a lot of problems getting it usable
[07:28] <sabdfl> subuntu :-)
[07:28] <mdz> next up is fresher and juicier glibc
[07:28] <mjg59> Did Fedora go with SELinux in the end?
[07:29] <daniels> sabdfl: is subuntu the distro with a root account per default?
[07:29] <mdz> apparently, Debian's glibc is ages old
[07:29] <jdub> mjg59: FC3 has a very very basic default configuration
[07:29] <Keybuk> mjg59: backed most of it out to a policy just for things like ssh
[07:29] <pitti> Can't we pick up something easier, like grsecurity or RSBAC?
[07:29] <Keybuk> mdz: it isn't
[07:29] <Kamion> mdz: it'll be updated right after sarge
[07:29] <daniels> mjg59: yes, although far more toned down from fc2's aggressive policies
[07:29] <azeem> mdz: jbailey was working on updating glibc, AFAIK
[07:29] <Keybuk> mdz: it's one minor release behind
[07:29] <Keybuk> unless I'm missing something entirely
[07:29] <Kamion> mdz: it's only been frozen because we (Debian RMs) are bastards :)
[07:29] <sabdfl> pitti: any of those things immediately takes us way out on a limb
[07:29] <mdz> is BenHerrenschmidt here?
[07:29] <doko> afaik, newer glibc is tightly coupled with newer gcc ... :(
[07:29] <mdz> he proposed this, and might have some details about what it means
[07:29] <elmo> mdz: no
[07:29] <Keybuk> ftp://ftp.gnu.org/gnu/glibc/
[07:29] <azeem> but he stopped a bit when he noticed sarge wasn't about to get released soonish
[07:29] <thom> mdz: he's in .au, so most likely asleep
[07:29] <jdub> mdz: no, but we should get more details from him about it
[07:29] <Keybuk> ^ the latest there is 2.3.3
[07:29] <Kamion> Keybuk: glibc's stopped making releases, you have to pull CVS
[07:29] <jdub> mdz: happy to take an action
[07:29] <mdz> ok, so is this simply a "track Debian" sort of thing, then?
[07:30] <pitti> sabdfl: why? We shouldn't install it by default, but we could have apt-get install xxx-server-profile or xxx-desktop-profile
[07:30] <Keybuk> Kamion: oh, I didn't know that
[07:30] <elmo> mdz: I think so
[07:30] <Keybuk> that's kinda scary
[07:30] <doko> kamion: there is 2.3.3
[07:30] <jdub> mdz: i can clarify it from him
[07:30] <thom> (new glibc gets us NPTL on powerpc, amongst other things)
[07:30] <azeem> Keybuk: glibc stopped doing proper releases, 2.3.3 is a sort-of stable snapshot from last year, AFAIK
[07:30] <pitti> sabdfl: grsec/rsbac/lids only need kernel support and tiny userspace programs
[07:30] <mdz> if sarge doesn't happen soon enough to get it from Debian, is it worth moving ahead of Debian?
[07:30] <doko> thom: only with gcc-3.4
[07:30] <mdz> i.e., what do we get out of newer glibc?
[07:30] <Kamion> which basically means we need hard-core glibc experts on staff to make it work
[07:30] <Keybuk> changing libc smells like abandoning binary compatibility with Debian to me
[07:30] <mdz> 1. NPTL on powerpc
[07:30] <jdub> mdz: can we pass on this and get more feedback from benh?
[07:30] <mdz> jdub: ok, let's
[07:31] <daniels> benh was saying that most of the problems with glibc were !(i386|amd64|powerpc), i.e. mostly NOTWARTY
[07:31] <Kamion> since picking a working glibc out of CVS is generally experts' work
[07:31] <mdz> jdub: will you get that feedback?
[07:31] <daniels> (glibc -> CVS glibc)
[07:31] <jdub> mdz: happy to take the action
[07:31] <mdz> done
[07:31] <mdz> next up, usplash
[07:31] <sabdfl> no releases from glibc? nnaaaiiice
[07:31] <sabdfl> kernel, glibc, the yellow submarine
[07:31] <mdz> sladen: are you here?
[07:31] <Keybuk> no npmccallum either?
[07:31] <jdub> azeem: (benh raised the issue)
[07:31] <daniels> ah, mad phat startup
[07:31] <mdz> usplash, for those unfamiliar, is the proposed boot splash implementation
[07:32] <mdz> which works in userspace using the kernel framebuffer, rather than patching it
[07:32] <daniels> i don't believe there is any contention over what's on the wiki right now
[07:32] <sabdfl> ubusplash!
[07:32] <mdz> it also involves some dbus magic to provide a nice progress indicator
[07:32] <sabdfl> optional
[07:32] <jdub> can we bring these items back together?
[07:32] <mdz> jdub: which items?
[07:32] <jdub> usplash
[07:32] <daniels> mdz: not dbus until we can do some upstream hackery (libexpat in initrd, yuk)
[07:32] <Keybuk> usplash -> have it if it's finished
[07:33] <sabdfl> npmccallum won't be on the team for hoary
[07:33] <daniels> most of the bits of usplash are reasonably small
[07:33] <mdz> Keybuk: what we're here to decide is whether it will be done, and who will do it :-)
[07:33] <Keybuk> sabdfl: oh?
[07:33] <sabdfl> so we need to take this on internally or find a bounty candidate
[07:33] <azeem> jdub: fair enough, but jbailey is a glibc maintainer and was working on it for Debian anyway
[07:33] <daniels> sabdfl: it's almost certainly doable internally, IMO
[07:33] <mjg59> Are we sure about being framebuffer based?
[07:33] <daniels> mjg59: as opposed to ... ?
[07:33] <mdz> mjg59: no, that's just current thinking
[07:33] <sabdfl> Keybuk: grep -ir npmccallum ~scott/patches/warty
[07:34] <mdz> if the implementor wants to do X or aalib, I'll at least listen :-)
[07:34] <mjg59> I worry that using two different graphical mechanisms could result in weirdness
[07:34] <mjg59> There'll always be some hardware that'll work with one and not the other
[07:34] <sabdfl> is fedora using a newer glibc?
[07:34] <daniels> sabdfl: write small fb blitter; write small co-ordination daemon; write novtswitch (done); make gdm and lsb init lib usplash-aware
[07:34] <mdz> mjg59: we'll need to get framebuffer stuff into good shape eventually anyway
[07:34] <sabdfl> daniels: don't trivialise the issues, x-platform for a start
[07:34] <jdub> can we bountyise this to sladen?
[07:34] <mdz> jdub: depends on sladen
[07:34] <daniels> sabdfl: true
[07:34] <Keybuk> sabdfl: so, uh, can someone update StaffOverview when people leave <g>
[07:34] <thom> sabdfl: yes, fedora is pretty much running off head of CVS
[07:35] <mjg59> mdz: This is sort of related to later stuff, but suspend/resume is going to be easier without framebuffer
[07:35] <mjg59> Probably massively easier
[07:35] <sabdfl> Keybuk: yes, sorry, i should have
[07:35] <mjg59> (on x86, at least)
[07:35] <mdz> mjg59: are the framebuffer issues unsolvable?
[07:36] <mjg59> mdz: vesafb is never going to work across suspend/resume, because there's no way to reconfigure the mode
[07:36] <jdub> mdz: can we assign a 'project manager' to the goal, to sort out bounty, delivery, etc?
[07:36] <mjg59> vesafb-tng might be a better plan, but it's a big divergence from mainstream
[07:36] <mdz> jdub: we should decide whether one of us will do it, or bounty it out
[07:36] <mdz> it's looking like a bounty sort of thing so far
[07:36] <jdub> yes, i think it's a bounty
[07:36] <mdz> unless someone here has a very strong interest in it
[07:36] <mdz> ok, bounty
[07:36] <jdub> not sure it's critical enough to manage internally
[07:37] <mdz> " Do something smart with SMART?"
[07:37] <jdub> hold on
[07:37] <sabdfl> mjg59: give me a quick rundown of the alternative options to fb for ubusplash?
[07:37] <jdub> can we assign someone to manage the bounty?
[07:37] <mdz> sabdfl: X
[07:37] <mdz> jdub: I will
[07:37] <jdub> ok
[07:37] <mjg59> sabdfl: Most straightforward is to start X /very/ early
[07:37] <daniels> fb or x, and i personally think x is a very bad idea; i think what's on the wiki is current best practice
[07:37] <mjg59> Which is what Fedora do
[07:38] <mdz> the SMART proposition would involve getting the SMART tools installed by default, and having them do something useful by default
[07:38] <mdz> ideally the user should get some notification when their disk is failing, etc.
[07:38] <jdub> mdz: sounds underspecified
[07:38] <sabdfl> mdz: silbs and i have a PA starting in two weeks who can carry the load  of bounty state tracking
[07:38] <mdz> jdub: indeed
[07:38] <daniels> mjg59: yes
[07:38] <jdub> sabdfl: (that's good news)
[07:38] <mdz> sabdfl: administrative or technical?
[07:38] <LeeColleton> SMART tools don't work with SATA drives last time I checked
[07:38] <daniels> mjg59: but they also start kdrive to track init, which is just bong imo
[07:38] <sabdfl> mdz: purely admin
[07:38] <daniels> mjg59: note that the current plans involve starting x very early
[07:39] <Keybuk> daniels: like, putting X in initrd ?!
[07:39] <mdz> sabdfl: ok, so I'll expect to continue to track technical progress
[07:39] <Keybuk> loading ramdisk ......
[07:39] <sabdfl> daniels: but not THAT early
[07:39] <mdz> Keybuk: not as crazy as it sounds
[07:39] <Keybuk> still loading ramdisk .....
[07:39] <daniels> Keybuk: no
[07:39] <daniels> sabdfl: right.
[07:39] <sabdfl> mdz: i think we should have an internal contact for each bounty, clearly, but not always you
[07:40] <sabdfl> it will be good to develop a little management capacity in the rest of the team too
[07:40] <daniels> basically, start the system, kick in usplash, get a logo out to framebuffer early and drop in some icons and status text; after network init (the hostname *cannot* change under X in current implementations), start X in the background
[07:40] <mdz> sabdfl: less work for me is usually acceptable :-)
[07:40] <daniels> when gdm has a login screen ready for the displaying, switch over to that
[07:40] <mjg59> If we want framebuffer functionality and we want suspend/resume, we're going to have to modify every single framebuffer driver
[07:40] <sabdfl> mjg59: can you get rid of framebuffer post-boot?
[07:40] <daniels> sabdfl: framebuffer 4 lyf, i'm afraid
[07:40] <mdz> the SMART thing is underspecified; I'll put it on a list of vague stuff, and if someone wants to come along and propose something concrete, we'll revisit it
[07:40] <mjg59> sabdfl: Not trivially
[07:40] <sivang> sabdfl : could there be a more thorugh explenation for the bounties on the wary page? IMHO it should have already been moved to Hoary
[07:41] <jdub> sabdfl, mdz: a number of the goals with my name attached are ones i expect to manage, rather than do
[07:41] <Kamion> mjg59: that's kind of unavoidable on powerpc, mind ...
[07:41] <sivang> sabdfl : for example, what is doc-base registeration?
[07:41] <mdz> sivang: several of the goals assume a thorough working knowledge of Debian packaging
[07:41] <mdz> which would be necessary to complete them anyway
[07:42] <thom> sivang: every thing that ships documentation needs to register siad documentation with doc-base
[07:42] <mjg59> Kamion: PPC is less of a problem - people have already dealt with that
[07:42] <Kamion> mjg59: oh, the modifications aren't quite portable?
[07:42] <mdz> let's take the usplash design discussion offline
[07:43] <mdz> we have much more ground to cover
[07:43] <mjg59> Kamion: The current suspend/resume code relies on OF doing some reinitialisation
[07:43] <mdz> next up is the question of whether we should handle NTP differently for Hoary
[07:43] <mdz> using ntpd rather than just running ntpdate at boot
[07:43] <Keybuk> aren't we doing ntpdate+ntpd now?
[07:43] <mdz> no, we currently only do ntpdate
[07:43] <lamont> Keybuk: "No listening ports"
[07:43] <Keybuk> ahh, it's in the seed but doesn't do anything?
[07:43] <doko> that was basically the delay problem, when you don't have a network connection?
[07:44] <mdz> this proposal came from the fact that gnome-system-tools integrates with ntpd
[07:44] <mdz> and not ntpdate
[07:44] <lamont> it would be nice to have an ntpd listening on the port by default.
[07:44] <mdz> so it has a little checkbox which will install ntpd, and then let you configure which servers to sync with
[07:44] <lamont> then again, the current ntpd is pretty fat
[07:44] <ogra> the delay could easy be solved by a poing in the bootscript
[07:44] <Keybuk> lamont: it'd be nice to have cups listening, http listening, etc.
[07:44] <mdz> it'd be nice to get rooted
[07:44] <daniels> i think ntp would be much more doable if we were smart about miitool or iwtool or whatever for link beat
[07:44] <lamont> Keybuk: heh. yeah
[07:44] <Keybuk> but then we're security swiss-cheese
[07:44] <sabdfl> can ntpdate be run in the background?
[07:44] <mdz> sabdfl: yes, it can
[07:44] <jdub> daniels: (NetworkManager)
[07:44] <mdz> in fact, I think it ignores errors currently anyway
[07:44] <mdz> but the delay is a separate issue
[07:45] <mdz> ntpdate and ntpd do different things
[07:45] <sabdfl> let's not do ntpd unless we really have to
[07:45] <lamont> very different
[07:45] <Keybuk> you need both
[07:45] <sabdfl> i'd be much happier with a cron'd ntpdate
[07:45] <doko> the delay isn't ntp specific. needs a mod to /etc/nsswitch.conf
[07:45] <Keybuk> ntpd keeps the clock in sync, but will cowardly not sync it if it's too far away
[07:45] <Keybuk> ntpdate syncs it, and then leaves
[07:45] <mdz> right
[07:45] <sabdfl> yes, ntpdate is a one-timerr
[07:45] <Keybuk> sabdfl: that's what we used to do at Demon to avoid the port
[07:45] <elmo> the cowardly thing is actually a feature tho
[07:45] <mdz> we decided way back in london that we wanted ntpdate as a default
[07:45] <Keybuk> (well, you have the port, but only for a few seconds)
[07:45] <lamont> sabdfl: anyone relying on filesystem timestamps would be very unhappy with cron'ed ntpdate
[07:45] <sabdfl> but there's nthing stopping us from doing it regularly
[07:46] <mdz> so the obvious course would be to change g-s-t to integrate with our ntpdate package
[07:46] <mdz> rather than with ntpd
[07:46] <sabdfl> lamont: where would you rely on filesystem timestamps?
[07:46] <lamont> make
[07:46] <elmo> oh, btw, orthogonally, can we pretty please de-root ntpd, even if we don't install it by default
[07:46] <mdz> jdub: is that a reasonable proposition?
[07:46] <Keybuk> lamont: anyone relying on filesystem timestamps that much would have configured ntpd themselves
[07:46] <mdz> elmo: good call
[07:46] <sabdfl> ok
[07:46] <elmo> the ntpdate-regularly thing also breaks regular cron jobs
[07:46] <jdub> mdz: 'synchronise now' or 'set up regular cron job'? i'm kinda uncomfortable with the cron job too
[07:46] <mdz> jdub: 'synchronise now' button, and configure servers
[07:46] <elmo> as time just, err, doesn't behave like time.. whereas with ntp, it just speeds up or down :)
[07:47] <sabdfl> seems we have the same problem either way
[07:47] <mdz> I'm not particularly hot on cron either
[07:47] <lamont> Keybuk: make users don't particularly care that time is accurate to within hours, they just care that it's monotonically increassing
[07:47] <jdub> mdz: that'd be great
[07:47] <mdz> jdub: bounty?
[07:47] <jdub> mdz: yeah
[07:47] <Kamion> without regular ntpdate, time is at least approximately monotonic. :-)
[07:47] <mdz> jdub: someone from gnome?
[07:47] <pitti> sabdfl: rather than cron, wouldn't /etc/network/ifup.d/ make much more sense? I. e. for dialup users
[07:47] <jdub> mdz: yes
[07:47] <sabdfl> can we use ntpdate to nudge the clock syncing algorithms in the right direction?
[07:47] <Kamion> sabdfl: that's more what ntpd's for really
[07:47] <Keybuk> sabdfl: ntpd is the clock-syncing algorithms
[07:47] <jdub> mdz: have a candidate for quite a few of these
[07:47] <lamont> sabdfl: all ntpdate does is yank time to the current time
[07:48] <mdz> ok, so that's on the bounty list
[07:48] <lamont> ntpd slews the local clock to keep it there
[07:48] <elmo> if the problem is the open port, can't we just bounty someone to fix that?
[07:48] <mdz> next up is speeding up the boot process
[07:48] <elmo> or is it inherent to ntp's design?
[07:48] <Keybuk> elmo: that's because ntpd uses udp, isn't it?
[07:48] <mdz> Keybuk: yes, but it could still be improved
[07:48] <Keybuk> mdz: didn't you rewrite hotplug in Perl?
[07:48] <mjg59> ntpdate can make the clock run backwards and confuse everything
[07:48] <mdz> Keybuk: yes, and then reverted it because perl needs /usr
[07:48] <sabdfl> *cough* *splutter*
[07:48] <Keybuk> mdz: I'd be tempted with a little C parser for that
[07:48] <mdz> Keybuk: yes
[07:49] <mjg59> If you're running slow, ntpdate will make your screensaver come on
[07:49] <mdz> Keybuk: but ssshh, before sabdfl insists that it be rewritten in python :-)
[07:49] <enrico> Please reach me in the next days if you need anything
[07:49] <sabdfl> "faster"
[07:49] <mdz> mjg59: that seems like a bug in xscreensaver
[07:49] <mjg59> ntpd just makes your clock go faster or slower until it reaches the right time
[07:49] <Keybuk> speed is really critical for it, and the last thing you want is to haul Perl or Python into memory ... that's not going to be hugely faster than shell
[07:49] <mdz> Keybuk: hauling perl into memory was a big win
[07:49] <mjg59> mdz: The results from gettimeofday() suddenly change...
[07:50] <sabdfl> is hotplug very complex? why not bounty a C implementation?
[07:50] <Keybuk> sabdfl: *shrug* I could do it in a few hours
[07:50] <mjg59> I'm off home - back in 15 minutes or so
[07:50] <mdz> sabdfl: it's not very complex at all
[07:50] <Keybuk> I'm reasonably sure I wrote one and have it on my disk somewhere
[07:50] <sabdfl> Keybuk: go for it
[07:50] <mdz> but it's easier to maintain in shell
[07:50] <Keybuk> in fact, I *know* I wrote one
[07:51] <sabdfl> is it the shell that makes it slow?
[07:51] <mdz> it's the fact that it uses shell *exclusively* that makes it slow
[07:51] <sabdfl> or is it hardware delays?
[07:51] <Kamion> sabdfl: parsing in shell tends to be slow, you have to fork lots of processes
[07:51] <mdz> I suggest that we rewrite certain bits in C
[07:51] <mdz> and not the whole thing
[07:51] <sabdfl> i thought they put in a deliberate delay to avoid some race condition in specific kernel versions
[07:51] <Kamion> it's just the modules.pcimap parser isn't it?
[07:51] <Keybuk> mdz: I was thinking the pcimap etc. parsers
[07:51] <mdz> Kamion: that's most of it, yes
[07:51] <mdz> Keybuk: exactly
[07:51] <mdz> that's what I rewrote in perl
[07:52] <doko> we could use ash as /bin/sh to make things a bit faster.
[07:52] <mdz> and saved about 0.3 seconds per device
[07:52] <Keybuk> and I know I wrote one for i-d; so I've just got to find it
[07:52] <mdz> another item under the same heading is starting gdm earlier
[07:52] <daniels> mdz: as I mentioned before
[07:52] <mdz> that's a large perceived performance benefit
[07:53] <mdz> I think we were in agreement that we should just do it
[07:53] <mdz> early on, and fix whatever breaks
[07:53] <daniels> you can start gdm as soon as you know the hostname won't change from under you
[07:53] <Keybuk> mdz: stick the hotplug parser under me, it'll give me something to do during test case runs :p
[07:53] <daniels> if the hostname changes under X, you're totally screwed
[07:53] <mdz> Keybuk: ok
[07:54] <mdz> need someone to take responsibility for gdm
[07:54] <mdz> since that's on the early breakage list
[07:54] <Keybuk> do we know how early it *can* be started?
[07:54] <daniels> might as well take that one
[07:54] <daniels> Keybuk: i have a very good idea
[07:54] <mdz> Keybuk: I've started it as the first thing in runlevel 2
[07:54] <mdz> with on il leffects
[07:54] <Keybuk> it probably needs all the Utopia stuff for when the user logs in
[07:54] <mdz> no ill effects
[07:54] <mdz> daniels: ok, yours
[07:55] <mdz> next up, we have some kernel stuff
[07:55] <mdz> which I think is probably bounty-oriented
[07:55] <pitti> Keybuk: hal must be running, the other stuff is gnome session
[07:55] <Keybuk> mdz: I have it at 21 ... I needed alsa, dbus and fam loaded first
[07:55] <mdz> oh, speaking of dbus
[07:56] <mdz> the other side of the start-gdm-early coin is displaying startup notifications for the things that start after it
[07:56] <mdz> with a little dbus magic
[07:56] <daniels> mdz: usplash
[07:56] <mdz> overlap with usplash
[07:56] <mdz> yes
[07:56] <daniels> mdz: (the usplash daemon just either writes out to the fb or X as is appropriate)
[07:56] <mdz> anyway, the next few items on the agenda are fixing the various warts in how we load kernel modules
[07:56] <daniels> personally, i think that is wholly subsumed by usplash
[07:56] <mdz> the fact that IDE stuff doesn't Just Work is the big one
[07:57] <mdz> also figuring out the right strategy for drivers which are no longer autoloaded with udev
[07:57] <mdz> unless anyone here has a strong interest and the domain knowledge for it, I suggest it be a bounty
[07:57] <Kamion> having mount load loop when needed would clean up a lot of user questions
[07:57] <fabbione> mdz: bounty
[07:58] <thom> mdz: agree
[07:58] <Kamion> but yes, bounty
[07:58] <mdz> Kamion: having it autoloaded somehow, whether it's mount's job or something else's needs to be determined
[07:58] <seb128> bounty yes
[07:58] <mdz> " Go back to the LiveSeed? idea to provide a more demonstration-worthy LiveCD?"
[07:58] <lamont> mdz: that has a pre-req of "make liveCD seeed fit..."
[07:59] <jdub> that's probably a non-issue given the size of the livecd + winfoss bits
[07:59] <mdz> this seems to raise the question of whether we want to try to make the live CD snazzier than the default desktop
[07:59] <Kamion> if LiveSeed is a strict subset or superset of each of the other seeds, that's fine, otherwise tricky in germinate
[07:59] <jdub> i think we do
[07:59] <jdub> for instance, i'd like to have a package of demo files
[07:59] <mdz> as you say, I don't think we can add much due to space constraints
[07:59] <Kamion> desktop-plus-some-stuff-from-supported would work
[07:59] <daniels> live dvd?
[07:59] <Kamion> (or desktop-minus-some-stuff)
[07:59] <mdz> Kamion: yeah, that's what it'd be
[07:59] <jdub> Kamion: yeah, +/- would be good
[08:00] <jdub> but all within supported
[08:00] <lamont> jdub: but not both
[08:00] <ogra> daniels: wont work in cd roms
[08:00] <Keybuk> - ttf-baemuk! </lamont>
[08:00] <Kamion> but if we want to add some bits from supported and take away pieces, the germinate-fu gets complicated
[08:00] <sabdfl> do we have space?
[08:00] <lamont> sabdfl: after tossing celestia, I think we're at 650MB or so
[08:00] <jdub> sabdfl: winfoss makes it hard
[08:00] <mdz> sabdfl: it's very tight
[08:00] <sabdfl> then i vote for parity between livecd and installed
[08:00] <lamont> 643MB
[08:01] <jdub> anyway, this could be a derivative livecd
[08:01] <jdub> for demos
[08:01] <sabdfl> yes
[08:01] <jdub> and stuff
[08:01] <mdz> I think we should probably leave the package list alone for hoary
[08:01] <mdz> for the live CD
[08:01] <mdz> i.e., match desktop
[08:01] <jdub> sabdfl: parity for the official livecd, yeah
[08:01] <sabdfl> we could well have derivatives in place for hoary
[08:01] <lamont> jdub: maybe a demoCD which puts your cool hoary packages in insead of WinFOSS?
[08:01] <mdz> " Optionally encrypted home directories that work out of the box (MartinPitt?)"
[08:01] <jdub> lamont: yeah
[08:01] <mdz> pitti: would you like to say something about this?
[08:01] <Kamion> partman was designed with support for encrypted filesystems in mind
[08:02] <pitti> I played around a little today with several implementations
[08:02] <pitti> I won't discuss them here, I will mail
[08:02] <Kamion> but it's not been implemented in partman yet
[08:02] <pitti> I just wnat to ask if there is consensus that we want support for it
[08:02] <lamont> I would like my USB dongle to automount after asking me for a passphrase...
[08:02] <mdz> pitti: I'm not sure exactly what it is
[08:02] <mdz> pitti: would this be cryptoloop stuff?
[08:02] <pitti> IMHO it would be a great thing for laptops
[08:02] <mdz> I think it's a lot of complexity for the default install
[08:02] <fabbione> pitti: i would like it hounestly
[08:02] <pitti> not necessarily cryptoloop
[08:02] <pitti> from the user's view nothing changes
[08:02] <Kamion> pitti: are we talking about having /home be a cryptofs, created in the installer?
[08:03] <sabdfl> not by default
[08:03] <pitti> if he logs in, his homedir is transparently decrypted
[08:03] <pitti> Kamion: I think it needs installer support to have it from the beginning
[08:03] <Keybuk> crypto home sounds slow to me
[08:03] <Kamion> pitti: indeed
[08:03] <jdub> consider that people will go, "ooh! this smells like security!"
[08:03] <pitti> it should be optional
[08:03] <Kamion> sabdfl: right, I don't think it's a default thing
[08:03] <pitti> It does not make sense for desktops
[08:03] <pitti> the user should deliberately choose it
[08:03] <mdz> I don't see why /home should be special
[08:04] <jdub> pitti: can we support it sanely?
[08:04] <pitti> we don't need to encrypt the whole partition
[08:04] <Kamion> partman may grow this sort of stuff if we just wait for the Anton Zinoviev machine to grind out code :-)
[08:04] <mdz> if you want encryption, it should be across the board
[08:04] <pitti> encrypting just some files or directories is actually less hassle
[08:04] <sabdfl> mdz: you know a user is around when you want to access it
[08:04] <doko> pitti: why not, but you would have to mount separate ones for /home/*
[08:04] <pitti> but it does not make sense to encrypt e. g. /us
[08:04] <pitti> I mean /usr
[08:04] <pitti> doko: not mount, just encrypt the directories separately
[08:04] <pitti> cryptoloop is not the only (and not the best) implementation
[08:05] <mdz> ok, let's discuss this on ubuntu-devel and hash it out
[08:05] <sabdfl> so to speak
[08:05] <pitti> so is there general interest?
[08:05] <mdz> sabdfl: har har
[08:05] <amu> Kamion: you cannot feeC[Cl the differents between a crypred dev and a normal. Computeres are too fast.
[08:05] <jdub> pitti: i'm concerned about supportability
[08:05] <pitti> That was the only question, I will work out details and bring it to the list
[08:05] <mdz> pitti: it's interesting, yes
[08:05] <mdz> whether we can and will do it depends on the details
[08:05] <pitti> jdub: I will work that out
[08:05] <ogra> waht about repairing a broken FS pitti ?
[08:05] <sabdfl> pitti: it may be something i prefer a bounty / contractor to do, rather than internal resources
[08:06] <pitti> ogra: I don't see what's different. e2fsck does not care whether the data looks like garbage
[08:06] <pitti> sabdfl: your choice :-)
[08:06] <ogra> pitti im ean dd rescue on a broken disk i.e.
[08:06] <LeeColleton> WRT encryption.. will there be a GUI key manager for hoary?  The new seahorse goes a long way towards integration with the desktop.
[08:06] <pitti> If we want to do it inhouse, I would like to deal with it
[08:06] <pitti> ogra: of course the rescue copy will still be encrypted
[08:06] <mdz> LeeColleton: doesn't gnome-keyring-manager handle that stuff?
[08:06] <pitti> ogra: you need the same password to decrypt it
[08:06] <jdub> LeeColleton: (new seahorse will be considered)
[08:06] <jdub> mdz: no
[08:06] <ogra> but can i decrypt easily
[08:07] <jdub> mdz: that's for gnome-keyring (not gpg related)
[08:07] <bob2> mithrandir was working on some dm-crypt gui stuff, iirc
[08:07] <pitti> ogra: it is transparent
[08:07] <ogra> pitti: k
[08:07] <Keybuk> my god, we're nearly a quarter of the way though
[08:07] <pitti> ogra: it could be encrypted with your login password
[08:07] <pitti> ogra: and we need a PAM module for this, but there are solutions
[08:07] <ficusplanet> What are you guys thinking in regards to mono for hoary?
[08:07] <mdz> right, moving on
[08:07] <jdub> LeeColleton: (can you put it on the HoaryHedgehog/SupportedSeed proposals list please?)
[08:07] <mdz> if anyone has suggestions that are not already on the list, please discuss them on the ubuntu-devel mailing list after the meeting
[08:07] <jdub> ficusplanet: (we're working to an agenda, see HH feature goals)
[08:07] <ogra> pitti: as long as i can repair it with, say knoppix ....if nothing else is handy
[08:08] <ficusplanet> jdub, thanks
[08:08] <mdz> we have enough to discuss with what is on the list; the page has been open for suggestions for a long time now
[08:08] <pitti> ogra: depends on the concrete implementation. Repairing an fs is always possible, though
[08:08] <mdz> next up, kernel unification
[08:08] <mdz> this is herbert's domain
[08:08] <ogra> pitti: :)
[08:08] <mdz> I think we know exactly what needs to be done
[08:08] <jdub> mdz: (btw, are you modifying the page as we go?)
[08:08] <mdz> jdub: I'm making notes and will replace the page wholesale
[08:08] <LeeColleton> jdub: where is the proposals list?
[08:09] <jdub> mdz: ok
[08:09] <mdz> what about inotify?
[08:09] <jdub> LeeColleton: HoaryHedgehog/SupportedSeed
[08:09] <jdub> mdz: should definitely go in, something for herbert
[08:09] <mdz> jdub: has it been submitted upstream?
[08:09] <jdub> yes
[08:09] <jdub> not accepted yet
[08:09] <mdz> ok
[08:09] <Keybuk> inotify seems to be the way forward
[08:09] <mdz> framebuffer-based bootsplash is superseded by usplash
[08:09] <Keybuk> and it makes fam+portmap go away :)
[08:10] <jdub> (yay!)
[08:10] <Keybuk> (gamin does too, but it makes the whole problem easier)
[08:10] <Kamion> mdz: kernel unification> restricted-modules too
[08:10] <mdz> Kamion: hmm?
[08:10] <sabdfl> ANNOUNCEMENT: we got our first customer for a tech support contract today END ANNOUNCEMENT :-)
[08:10] <fabbione> cool!
[08:10] <lamont> WOOOHOOO!!!!!
[08:10] <seb128> yeah :)
[08:10] <ogra> congrats
[08:10] <mdz> sabdfl: EXCITEMENT wonderful! END EXCITEMENT
[08:10] <doko> canonical ltd? ;-)
[08:11] <sabdfl> keep going :-)
[08:11] <Kamion> mdz: linux-restricted-modules and the udebs of same
[08:11] <mdz> Kamion: yes, includes that
[08:11] <mdz> I'll make an explicit note
[08:11] <sabdfl> w.r.t. kernel, i've discussed creating a six-month release of 2.6 for broader use than ubuntu
[08:11] <sabdfl> with herbert
[08:12] <mdz> which I think is a fantastic idea
[08:12] <jdub> rocking
[08:12] <sabdfl> it would be timed to our release schedule, since it's our core funding, but the idea would be to build a small community around it
[08:12] <sabdfl> for the smaller distros
[08:12] <doko> sabdfl: what does this mean? two kernel upgrades per year?
[08:12] <sabdfl> doko: yes, in a predictable release schedule
[08:13] <sabdfl> because at the moment, we have crack from upstream
[08:13] <mdz> moving on, we have a bunch of installer stuff
[08:13] <mdz> tops of which is the controversial gui installer
[08:13] <doko> nice idea, that would include the binary tools needed for restricted modules?
[08:14] <mdz> sabdfl: gui installer decision?
[08:14] <sabdfl> not for hoary
[08:15] <mdz> ok, pushing it back
[08:15] <mdz> kickstart
[08:15] <sabdfl> no problem starting down the road, balanced against hoary priorities
[08:15] <Kamion> GUI installer status: boots with much hackery, nothing too fundamentally painful; need debconf protocol extensions to make it be a good UI; will need coordination with #debian-boot folks; recommend starting early even if we don't finish for hoary
[08:15] <pitti> what's kickstart?
[08:15] <sabdfl> yes please!
[08:15] <mdz> pitti: unattended semi-custom installs based on a config file
[08:15] <Kamion> pitti: Red Hat mass deployment thing
[08:15] <jdub> kickstart == RH compatible pre-seed format
[08:15] <pitti> thx
[08:15] <mjg59> The RH implementation was moderately sucky when I played with it
[08:15] <sabdfl> does it have to be RH-compatible? would that be the hard part?
[08:16] <mjg59> Making it similar to RH would ease transition
[08:16] <Kamion> kickstart's specification looks remarkably similar to d-i preseed when you look at it; it says things like "if you don't answer a question, the installer will ask the user"
[08:16] <jdub> sabdfl: the format, yes; the data, no
[08:16] <Kamion> sabdfl: sysadmins of my acquaintance would kill for it
[08:16] <Kamion> RH-compatibility
[08:16] <mdz> I think the useful subset of RH-compatibility would not be that hard
[08:16] <Kamion> however, I believe that it's "just" a format translation job
[08:17] <jdub> kickstart generation guis already exist, etc.
[08:17] <Kamion> for the bits that usually vary between distros, sysadmins are already used to having different fragments for RH/SuSE, etc.
[08:17] <mdz> anyway, kickstart is something we'll do for hoary, but needs spec work
[08:17] <mjg59> Kickstart would be a very good thing to push back into Debian
[08:17] <Kamion> mjg59: yep
[08:18] <mdz> next up, the fancy keyboard selector
[08:18] <mdz> smells like bounty to me
[08:18] <Kamion> there's localization-config in Debian
[08:18] <fabbione> mdz: i will be very glad to get rid of X keyboard management
[08:18] <mjg59> (Regardless of the reality of things, some people are feeling like http://unstable.buildd.net/index-i386.html - obviously useful chunks of infrastructure make life better)
[08:18] <Kamion> that's Konstantinos Margaritis' work (Skole)
[08:18] <mdz> localization-config is like what we do now for X
[08:18] <mdz> the fancy selector is something much fancier :-)
[08:18] <Keybuk> fabbione: will X.org still work with the GNOME Keyboard Preferences stuff?
[08:18] <Kamion> ah, I thought l-c was better, haven't looked in detail yet
[08:18] <mdz> this is the thing which deduces your layout by having you type things
[08:18] <daniels> Keybuk: yes
[08:18] <Kamion> aha
[08:18] <mdz> and uses that to seed everything which needs keyboard layout info
[08:18] <fabbione> Keybuk: i don't know yet
[08:18] <mdz> console and X
[08:19] <mdz> it requires some fairly broad knowledge about layouts and their differences
[08:19] <fabbione> mdz: we use the same code for X now and it doens't look that good considering the bugs we got
[08:19] <mdz> fabbione: this is not the same thing, it is a different project
[08:19] <fabbione> mdz: we need to involve the console-data maintainer to do the right thing
[08:19] <daniels> the problem is the zero-question assumption
[08:20] <daniels> some people in the czech republic have us-layout keyboards
[08:20] <mdz> we will not guess as we do not
[08:20] <mdz> now
[08:20] <mdz> we will ask once, and ask very thoroughly
[08:20] <daniels> right
[08:20] <mdz> ok, going on the bounty list
[08:20] <Keybuk> Language, Timezone and Keyboard are sensible questions to ask everybody
[08:20] <Keybuk> even MS ask them
[08:20] <mdz> hotplug installer we already covered as part of unifying hardware detection
[08:20] <Keybuk> though highlighting the most common answer is a win
[08:20] <fabbione> Keybuk: our problem is sync X and console
[08:20] <mdz> " support for multiple network devices of same type"
[08:20] <daniels> mdz: bountying out to someone with very good keyboard knowledge (of which there are very few) is recommended
[08:20] <mdz> Kamion: ?
[08:21] <Kamion> mdz: I don't know what that is?
[08:21] <mdz> neither do I
[08:21] <Kamion> mdz: maybe it's ISDN bonding or something
[08:21] <Keybuk> I thought hotplug solved that?
[08:21] <mdz> I certainly hope not
[08:21] <Keybuk> assuming he's talking about the 2.4-era of having to tell the module to create eth0 and eth1 type things
[08:21] <Kamion> mdz: whatever it is, it stinks of bounty or "wait for Debian to do it" to me :-)
[08:21] <jdub> might be refering to ifrename things
[08:21] <mdz> marking it as not-enough-info
[08:21] <mdz> " Option to set up proxy/authentication before attempting first apt-get update"
[08:22] <mdz> this one would require sabdfl approval to ask another question in every install
[08:22] <Kamion> the code's there, but it fell to the "fewer questions" axe
[08:22] <fabbione> mdz: we explicitly killed that question if we could reach archive.u.c
[08:22] <mdz> right
[08:22] <Keybuk> what's the loss with the way we do it now?  I thought we tested
[08:22] <mdz> but there has been user demand for it
[08:22] <Keybuk> fabbione: indeed, don't we test and then ask if it fails
[08:22] <Kamion> fabbione: but do we ever ask that question? I've never seen it
[08:22] <mdz> Keybuk: what we lose is caching proxies
[08:22] <lamont> just because I can reach a.u.c doesn't mean I want to go that path..
[08:22] <mdz> which is a big win for mass installs
[08:23] <mdz> sabdfl: ?
[08:23] <fabbione> Kamion: yes, we ask if we cannot reach archive
[08:23] <Keybuk> isn't that what custom is for?
[08:23] <Kamion> fabbione: I think that code might be buggy, because I would have seen that question.
[08:23] <fabbione> Kamion: but that happens with choose-mirror
[08:23] <lamont> fabbione: define "reach"
[08:23] <fabbione> lamont: wget a Package file or a Release.
[08:23] <fabbione> lamont: can't remember
[08:23] <lamont> ok
[08:23] <doko> tell the user to pull the plug if wants proxy support
[08:23] <mdz> ok, we'll leave this one as pending a decision, since the code is already there and just needs to be switched on
[08:23] <Kamion> let's file a bug on that and move on
[08:24] <mdz> " CD-based upgrade?"
[08:24] <lamont> doko: sadly, pulling the plug just means you don't get prompted for _any_ network source.
[08:24] <lamont> or does it....
[08:24] <mdz> the idea of that one would be to be able to insert a Hoary CD on a Warty machine and have an upgrade happen
[08:24] <Keybuk> mdz: would be nice if you could put the CD in and it do the right thing
[08:24] <Keybuk> should be pretty trivial too?
[08:24] <Kamion> is that apt-cdrom-style, or boot from CD (a.k.a. crack)?
[08:24] <lamont> as in auto-run?
[08:24] <mvo_> mdz: with some kind of auto-run?
[08:24] <mdz> Kamion: autorun type thing
[08:24] <mdz> Kamion: not boot from CD
[08:24] <Kamion> mmmkay
[08:24] <doko> lamont: anyway it would counter intuitive to pull the plug for configuring some network stuff ;)
[08:24] <mdz> we have no autorun in warty, but that'd be the general idea
[08:25] <jdub> autorun is off by default
[08:25] <fabbione> but do we have some sort of autorun in place that can take care of warty -> hoary?
[08:25] <mdz> double-click and have it run apt-cdrom, change sources.list and go
[08:25] <Kamion> right-click -> upgrade would be nice
[08:25] <lamont> mdz: sounds like something we'd add in hoary to take advantage of with grumpy, no?
[08:25] <fabbione> ok
[08:25] <mdz> lamont: we can do it for hoary, it's just a double-click rather than autorun
[08:25] <sabdfl> (re proxy conf, sounds useful in corporate setting, like kickstart, perhaps with a boot-time command)
[08:25] <Keybuk> lamont: make it an executable on the CD ... you put the CD in and run something on it
[08:25] <mdz> put something in the root of the CD called "DO THE UPGRADE PLEASE".sh
[08:25] <mvo_> mdz: I can take it
[08:25] <Kamion> sabdfl: you could easily preseed it
[08:26] <Kamion> sabdfl: (modulo tweaks to make sure preseeding works for that)
[08:26] <sabdfl> kamion: agreed, useful for those who need it, not necessary to ask otherwise
[08:26] <mvo_> fits with the upgrade-center idea that Mitario proposed
[08:26] <mdz> sabdfl: I don't think we talked about the CD-based upgrade; what's your opinion?
[08:26] <sabdfl> i like it
[08:27] <mdz> ok
[08:27] <mdz> I'm happy for mvo_ to work on it
[08:27] <sabdfl> "good to have"
[08:27] <mdz> it should be a fairly small project
[08:27] <sabdfl> not sure it has to be automatic
[08:27] <Keybuk> it should be pretty trivial ... the CD is an APT archive anyway
[08:27] <mdz> I think it would be very slick for it to be automatic, post-hoary
[08:27] <mdz> but anyway that's the easy part
[08:27] <sabdfl> not *too* automatic though :-)
[08:27] <mdz> as automatic as other autorun stuff, i.e. prompt for confirmation first
[08:28] <lamont> and sudo password
[08:28] <Keybuk> mdz: auto-run of binaries signed by a key in a keyring type thing?
[08:28] <Kamion> :-)
[08:28] <mdz> " Install libglide3 library when one of the supported 3dfx cards is detected"
[08:28] <lamont> Kamion: I was just going to burn one to carry around with me.. :-)
[08:28] <Keybuk> -> desktop seed suggestion
[08:28] <mdz> this has a question from Kamion next to it which doesn't seem to have been answered
[08:28] <mdz> daniels: do you know wha tit's about?
[08:28] <sabdfl> isn't libglide3 toxic^Wproprietary?
[08:28] <fabbione> mdz: it's not dangerous to install libglide3
[08:28] <mjg59> sabdfl: Not for years
[08:28] <fabbione> sabdfl: no
[08:28] <mjg59> 3DFX GPLed it before going under
[08:29] <mdz> libglide3 is dlopened when using some cards or something?
[08:29] <mjg59> It's needed for DRI on Voodoo3/4/5/6
[08:29] <sabdfl> so let's make it part of X
[08:29] <fabbione> mdz: X uses it if the driver is 3dfx and if there is a compatible board
[08:29] <mdz> ok
[08:29] <mdz> so, yes, desktop seed suggestion
[08:29] <fabbione> mdz: yes, it's dlopened
[08:29] <mjg59> Yeah, it's utterly harmless
[08:29] <mdz> " installer bootable from floppy (for older systems that don't boot from CD/network)"
[08:29] <daniels> libglide3 is fine for desktopseed
[08:29] <bob2> fabbione: can it emulate GL?
[08:29] <mjg59> Except for its crackful build system
[08:29] <mdz> Kamion: ?
[08:29] <daniels> (sorry, just trying to figure out why my laptop's /home got shut down)
[08:30] <Kamion> mdz: that's fairly trivial, I only disabled it for warty because we didn't have time to test it
[08:30] <Kamion> we've had a lot of requests for it
[08:30] <fabbione> bob2: it is for GL
[08:30] <bob2> fabbione: ah. thanks.
[08:30] <mdz> Kamion: ok, added to the list of stuff to switch on early and start testing
[08:30] <mdz> " installer bootable from USB drive (for laptops without CD drives)"
[08:30] <mdz> that would be extremely cool
[08:31] <pitti> d-i boots nicely from USB
[08:31] <daniels> should work fine
[08:31] <Keybuk> another Kamion plaything
[08:31] <Kamion> pretty much likewise; I propose putting the netboot kernel and initrd in a form conveniently ddable to USB
[08:31] <fabbione> .. to bad i didn't have any device that could boot from USB
[08:31] <doko> nice to have it for our shop: memory stick preloaded with warty/hoary :)
[08:31] <Kamion> Debian supports this, but they do it by telling you to put a businesscard ISO on the USB stick
[08:31] <Keybuk> doko: you can fit warty on a Laks watch at the moment :)
[08:32] <Kamion> since we don't have businesscard ISOs and Warty won't fit on most sticks we need to take a slightly different approach, but it won't take long
[08:32] <sivang> 500mb in it?
[08:32] <sivang> ?
[08:32] <pitti> it works without an image, just the initrd and the kernel (and syslinux)
[08:32] <mdz> ok, let's take a brief diversion and talk about the laptop goals
[08:32] <Keybuk> sivang: 512MB
[08:32] <sabdfl> hmm... think we can keep hoary under 512MB?
[08:32] <mdz> because mjg59 can't stay much longer
[08:32] <pitti> My usbstick just needs 4 MB for a network d-i
[08:32] <mjg59> Sorry - feeling miserably unwell
[08:32] <jdub> sabdfl: unlikely
[08:32] <Kamion> (I have to go in about 40 minutes, BTW)
[08:32] <mdz> the big laptop goal is going to be suspend support
[08:32] <mjg59> Let's make this quick then
[08:32] <mdz> mjg59: what's our strategy for that, regarding ACPI vs. swsusp etc.
[08:32] <sabdfl> software suspend?
[08:33] <mjg59> Suspend to disk is fairly easy, with the possible exception of nvidia
[08:33] <mjg59> There's some drivers that could do with fixups, but in most cases that's straightforward (and it's major community love)
[08:33] <mdz> this is definitely something we should break early
[08:33] <mdz> what changes do we need to make?
[08:33] <mjg59> SuSE are shipping with swsusp enabled by default in 9.2, so there's no strong reason not to include it
[08:33] <mjg59> It's a kernel patch plus some modifications to let it work with initrd
[08:34] <mdz> mjg59: and also changing acpi-support to enable it by default?
[08:34] <mjg59> Yeah
[08:34] <mdz> what about acpi S3? do we care at all?
[08:34] <jdub> swsusp requires swap >= ram?
[08:34] <mjg59> S3 is, in almost all cases, preferable to StD
[08:34] <fabbione> what about all the problems we have with "boot with acpi=off"?
[08:34] <mjg59> jdub: No
[08:34] <mjg59> jdub: Except in extremely pathological cases
[08:35] <mdz> mjg59: so what will the default action be, for sleep button, lid close, etc.?
[08:35] <daniels> mdz: s3 is nice but really, really hard to get right
[08:35] <daniels> mdz: needs lots of testing and brute-forcing as to which modules need to get removed
[08:35] <Keybuk> s4 is too heavy-weight for lid close, I'd say
[08:35] <mjg59> mdz: S3 has an outside chance of being useful early enough for Hoary
[08:35] <daniels> mdz: i'm making acpi-support-x40 more generic, so we can just slot in different module lists
[08:36] <mdz> mjg59: what's the change that we'll make in the next week or so in order to start testing it?
[08:36] <sabdfl> "outside chance" is not something we should aim for
[08:36] <mdz> mjg59: swsusp?
[08:36] <mjg59> mdz: swsusp is in 2.6.9 and works well, but needs patching to work with an initrd rather than a monolithic kernel
[08:36] <sivang> I couldn't not spot the "excellent documentation" feature. is this going to be discussed here?
[08:36] <sabdfl> that sounds doable
[08:36] <sivang> being a hoary feature goal.
[08:36] <amu> mdz: you need double sawp as ram
[08:36] <amu> swap
[08:36] <mdz> amu: ??
[08:36] <sabdfl> sivang: let mdz set the pace
[08:36] <mjg59> amu: No
[08:36] <jdub> sivang: (we're not there yet)
[08:37] <sivang> ok, sorry.
[08:37] <amu> mdz: sw susp
[08:37] <mdz> sivang: we've skipped ahead to accomodate mjg59 having the plague
[08:37] <mjg59> There are three main issues with S3
[08:37] <amu> mjg59: no?
[08:37] <mjg59> 1) hardware where it just doesn't work
[08:37] <mdz> ok, it sounds like swsusp is what we should start testing for hoary
[08:37] <sivang> mdz : ok, we can always dicuss this on CC meeting
[08:37] <mjg59> The VIA craptop is an example of this. I'm working on it, mildly in touch with someone in Intel
[08:37] <mdz> and if good things happen with s3, maybe we can enable it on a case-by-case basis for some laptops
[08:38] <mjg59> 2) hardware where it works but video doesn't come back
[08:38] <amu> mjg59: ok
[08:38] <thom> mdz: this kinda ties into the hardware db
[08:38] <mdz> " More flexible implementation of TRLS features (hal/dbus, etc.)?"
[08:38] <bob2> is swsusp the One True suspend-to-disk thing now?
[08:38] <mjg59> (2) is not easily solvable in the VESA case
[08:38] <mdz> what is that about?
[08:38] <bob2> ie will it support !i386 soon/now?
[08:38] <mjg59> 3) individual drivers that don't work
[08:38] <mjg59> (3) is easily fixed on a case by case basis
[08:38] <mdz> mjg59: TRLS?
[08:38] <Kamion> bob2: as I understand it powermac support is RSN
[08:38] <thom> mdz: it almost certainly is !hoary - moving power management infrastructure to use hal
[08:38] <mjg59> More hardware for testing would be good. If I can sort the craptop, I'll produce kernel images.
[08:39] <jdub> trls == Totally Rad Laptop Support
[08:39] <thom> and then doing all the TRLS stuff over dbus
[08:39] <mjg59> I think that's post-hoary
[08:39] <mdz> we really ought to fix that
[08:39] <mjg59> We need more hal support for platform devices first
[08:39] <mdz> as rad as it is, it's fairly hacktastic on the inside at the moment :-)
[08:39] <thom> mdz: yes.
[08:39] <mdz> what about the configuration side of it?
[08:40] <mdz> i.e., currently the user needs to hand-edit scripts in /etc to change the timeouts and such
[08:40] <mjg59> I'm inclined to go for suspend to disk on power or sleep button, and just try to blank the screen on lid close
[08:40] <mdz> especially that evil-cryptic hard drive timeout value
[08:40] <thom> mdz: well, that's the flipside - with a dbus/hal implementation, you could have a NetworkManager like implementation - user config frontend that talks to a backend daemon
[08:40] <mdz> mjg59: blank the screen and leave everything powered up?  that seems to cause lots of user surprises
[08:40] <amu> mjg59: there are some reports about swsusp.? i guess many brocken drivers, like cetrino wireless ;)
[08:41] <mjg59> mdz: Suspend to disk on lid close is hard
[08:41] <mdz> amu: they'll be fixed
[08:41] <amu> centrino even
[08:41] <mdz> mjg59: why harder than power button?
[08:41] <thom> so no need to mod stuff under /etc
[08:41] <Keybuk> mdz: stand up, shut lid, move to other table, open lid
[08:41] <mjg59> mdz: It's difficult to get most hardware to autoresume from swsusp on lid open at present
[08:41] <Keybuk> the time the lid is shut is often less than the time to actually suspend
[08:41] <mdz> mjg59: ah
[08:42] <Keybuk> (not to mention the technical reasons)
[08:42] <mdz> ok
[08:42] <mjg59> And we're still talking 20 seconds or so for resume
[08:42] <amu> mdz: something good for the liveCD
[08:42] <mdz> " Automatic /cpufreq module loading (possibly for desktop systems, too)"
[08:42] <mjg59> Sladen was working on that
[08:42] <mdz> I think the path forward for that is hotplug cpu support, is it not?
[08:42] <mjg59> It's straightforward - just need to map CPU to module, and then fall back to acpi
[08:42] <sabdfl> can we not do a delayed swsusp?
[08:42] <sabdfl> so if the lid stays closed for mor ethan 3 minutes, std?
[08:42] <mjg59> sabdfl: Yes - a timer on closed lid is practical
[08:43] <mdz> mjg59: what was he working on?  loading the right module based on /proc/cpuinfo?
[08:43] <mjg59> mdz: Yes
[08:43] <thom> mdz: yes
[08:43] <mdz> ok, sounds eminently doable for hoary
[08:43] <thom> can we bounty hotplug cpu support, and stay with sladen's script short term?
[08:43] <mdz> yes
[08:43] <thom> cool
[08:43] <mdz> " APM support selectable on install for laptops with missing/broken APCI support (BenjaminLong?)"
[08:43] <mjg59> Firstly, anything that doesn't support ACPI should have APM loaded
[08:44] <Keybuk> *shrug* that should be automatic
[08:44] <mjg59> At the moment, loads of people are having to add APM to /etc/modules by hand
[08:44] <mdz> sounds like early breakage to me
[08:44] <mjg59> There's no real downside to always trying to load APM
[08:44] <ogra> mjg59: i have a lap that has acpi but isnt supported
[08:44] <mdz> so we should start loading apm automatically whenever acpi is not active?
[08:44] <Keybuk> can't we load acpi, and then apm -- iirc apm will not load if acpi was loaded and worked
[08:44] <mdz> Keybuk: I think so
[08:44] <mjg59> mdz: If you try to load APM when acpi /is/ active, it'll just disable itself
[08:44] <mdz> what's the proper userland place to trigger apm loading?
[08:44] <mdz> oh, we have apmd in desktop
[08:45] <mdz> so apmd should start loading apm, it sounds like
[08:45] <mjg59> The apm init script could check for a /proc/acpi, and load apm if it's not there
[08:45] <mjg59> That's probably the easiest solution
[08:45] <mdz> ok
[08:45] <mdz> who will make the changes?
[08:45] <mjg59> Passing acpi=off then results in the right thing happening
[08:45] <mdz> to the apm package?
[08:45] <Keybuk> mjg59: why do you need the acpi=off ?
[08:45] <thom> i'll take
[08:45] <mdz> thom: yours
[08:45] <mjg59> Keybuk: If you have working APM suspend but no working ACPI suspend, for instance
[08:45] <mdz> mjg59: that's it for the laptop stuff
[08:46] <mjg59> mdz: Yup
[08:46] <mjg59> Rock
[08:46] <Keybuk> ok, I assume you don't need that for an APM-only laptop
[08:46] <thom> mdz: NetworkManager
[08:46] <mjg59> Oh, one thing - I have a limited range of hardware for this. Another test machine would be handy
[08:46] <mdz> thom: that's under a separate heading
[08:46] <thom> do we want to talk about this in relation to laptops, or seperately? (mjg59 has been looking at it, as have I)
[08:47] <jdub> separate, there's a big chunk of bullet points about it
[08:47] <mdz> only if there's a specific feature goal in it other than "package networkmanager and add it to desktop"
[08:47] <mjg59> Yeah, it's more useful on laptops than elsewhere but I think it's part of the big network autoconfiguration love thing
[08:47] <thom> k
[08:47] <mjg59> mdz: Thanks
[08:47] <mdz> I'm already thinking that we may need to adjourn and finish tomorrow
[08:47] <mdz> we have another couple of hours, easily
[08:47] <mdz> but let's blaze through as much as we can
[08:48] <mdz> language support
[08:48] <jdub> oh man, another 2am meeting tomorrow would kill me :)
[08:48] <daniels> mdz: one hit is good for me and the others at 2am
[08:48] <jdub> (it's 5am)
[08:48] <Keybuk> jdub: interfering with breakfast? :p
[08:48] <fabbione> mdz: i won't be able to be here tomorrow at this time
[08:48] <jdub> Keybuk: (i got up at 4am yesterday)
[08:48] <mdz> the big part of this bit is the backend infrastructure to pull things out of packages during the build cycle
[08:48] <mdz> which is a generic facility we may use for several things
[08:49] <doko> during build, not install?
[08:49] <mdz> this is high priority, so someone will be assigned to implement it
[08:49] <mdz> doko: right, during build
[08:49] <mdz> for example
[08:49] <lamont> mdz: 2400UTC?
[08:50] <jdub> part of it is just pulling stuff out
[08:50] <mdz> the basic idea is to create language packs
[08:50] <mdz> by extracting locale-specific data from packages
[08:50] <jdub> the tricky bit is pulling stuff out entirely, and making new packages based on it
[08:50] <pitti> even more trickier is that the stuff must not be put into the original packages any more, right?
[08:50] <mdz> so probably a debhelper component to do the acquisition of the data, a repository of some sort to hold it, and a system to make packages out of it
[08:50] <ogra> the printing system tied to the locale would be nice
[08:50] <Keybuk> you'd have to do it somewhere between binary and signing the changes
[08:51] <doko> detect thing in /usr/share/locale and build new packages from that, add to the control file the new packages and add conflicts to the old package?
[08:51] <mdz> Keybuk: you'd do it before even creating the .deb
[08:51] <jdub> mdz: debhelper means lots of patches
[08:51] <mdz> jdub: why?
[08:51] <Kamion> jdub: good
[08:51] <Kamion> :-)
[08:51] <jdub> hrm, unless it was built in to an existing debhelper module
[08:51] <mdz> jdub: it would be a separate module
[08:51] <Kamion> I don't think that something this invasive should be silent as far as the source package is concerned
[08:51] <fabbione> dh_builddeb could call it
[08:51] <jdub> mdz: so surely that means lots of patches against modules
[08:51] <mdz> it wouldn't even necessarily have to be debhelper-compatible, but it would be used in the same way
[08:51] <lamont> mdz: and many things don't build-dep debhelper...
[08:52] <Kamion> otherwise users will have a hell of a time building packages
[08:52] <mdz> jdub: why does a separate module imply patches to existing modules?
[08:52] <lamont> Keybuk: trivial to automate, no? :-)
[08:52] <Keybuk> mdz: to change debian/rules ?
[08:52] <jdub> mdz: patches to packages
[08:52] <mdz> lamont: packages which use this facility should probably do so explicitly and build-dep
[08:52] <mdz> trying to intrusively hook into the process this way sounds rather insane
[08:52] <jdub> mdz: debian/{rules,control}
[08:52] <mdz> jdub: yes, right
[08:52] <lamont> mdz: so you don't mean _all_ packages, just those with locale compoinets?
[08:52] <mdz> jdub: I was talking debhelper modules
[08:52] <mdz> dunno
[08:53] <mdz> I think this needs a real design discussion
[08:53] <lamont> definitely
[08:53] <mdz> but it also needs someone to take the lead
[08:53] <jdub> lamont: it gets pretty close to all, given gnome (locales separation and .desktop extraction)
[08:53] <pitti> sounds interesting
[08:53] <Kamion> jdub: there are lots of unlocalised and don't-need-to-be-localised packages below the desktop
[08:54] <Kamion> libraries instantly spring to mind
[08:54] <jdub> yeah
[08:54] <mdz> .desktop extraction is significantly easier
[08:54] <mdz> beacuse it's a tiny amount of data
[08:54] <mdz> we don't need to exclude it from the .deb at all
[08:54] <Kamion> wouldn't this be easier with arch-for-everything?
[08:54] <seb128> Kamion: most of gnome libs are localised
[08:54] <mdz> Kamion: not for locale data; it's generated at build time, no?
[08:54] <doko> are desktop extractions worth to put in an extra package?
[08:55] <jdub> Kamion: lots of this has to be done after build
[08:55] <Kamion> mdz: you could generate it from the .po files in the same way, I'd've thought
[08:55] <mdz> ok, I don't want to have the design discussion now
[08:55] <Keybuk> doko: not for an extra package, for a smart "Add/Remove Programs" app
[08:55] <pitti> mdz: well, if the stuff is extracted into an extra package, it shouldn't be in the original deb any more
[08:55] <Keybuk> mdz: it's a must-have from sabdfl isn't it?  so should be punted to design later
[08:55] <jdub> pitti: (.desktop stuff is a bit different, it'll go elsewhere)
[08:55] <mdz> the spec as it stands is that we want to have language packs which include the localisation data across the distribution, and exclude that data from the packages
[08:55] <mdz> the question in the table is who will implement it
[08:56] <Kamion> has anyone checked if all of these language packs will actually fit on the CD?
[08:56] <Kamion> they're going to be absolutely enormous
[08:56] <sabdfl> Kamion: won't ship all of them
[08:56] <Kamion> sabdfl: even one of them will be enormous :)
[08:56] <mdz> that, and they won't have any new data to start
[08:56] <mdz> we'll just be moving things from one package to another
[08:56] <pitti> mdz: I'd like to look at this
[08:56] <mdz> pitti: ok, yours
[08:56] <sabdfl> Kamion: don't we currently ship *all* translations?
[08:56] <lamont> this is all of french (say) for all desktop apps in one package?
[08:56] <jdub> mdz: (though it will include all of Supported translations too)
[08:56] <Kamion> sabdfl: no, see openoffice.org-l10n-*
[08:56] <Kamion> about 3MB per language
[08:56] <sabdfl> Kamion: right
[08:57] <mdz> jdub: I think we can separate supported from desktop
[08:57] <mdz> anyway, trying not to get into it
[08:57] <doko> sabfl: only for packages which don't have localization packages as extras
[08:57] <mdz> " excellent GDMLanguageIntegration? (selection of login language, selection of system languages)"
[08:57] <sabdfl> we'll only do this for the desktop package
[08:57] <sabdfl> s
[08:57] <mdz> we already can select the login language, no?
[08:57] <jdub> yeah
[08:57] <mdz> jdub: can you expand?
[08:57] <jdub> but not guiable
[08:57] <Kamion> if generated, yeah
[08:58] <Keybuk> all three of those sound like bounties
[08:58] <mdz> agreed
[08:58] <mdz> needs a spec, though
[08:58] <mdz> moving on
[08:58] <jdub> there's no way of configuring the GDM language
[08:58] <Sensebend> what is the target size of the next release?
[08:58] <Keybuk> Sensebend: single CD
[08:58] <mdz> Sensebend: one CD
[08:58] <Sensebend> so 650MB or 700MB?
[08:59] <Kamion> 650, I think
[08:59] <jdub> but there is a list of languages - if configured - to choose from for your session
[08:59] <jdub> we need a gui way of choosing available languages
[08:59] <mdz> next up, documentation
[08:59] <mdz> any documentation team folks here?
[08:59] <mdz> hornbeck: hi
[08:59] <Sensebend> agreed jdub
[08:59] <jdub> and add gdm language choice to gdmsetup
[09:00] <jdub> (this should probably be shifted to desktop)
[09:00] <sivang_away> me also
[09:00] <mdz> python port of yelp -> bounty
[09:00] <sivang_away> :)
[09:00] <ogra> jdub: and disable it if there is only one lang ?
[09:00] <jdub> mdz: python port of yelp can be dumped for hoary
[09:00] <mdz> even better
[09:00] <sivang> jdub : have you talked with shaunm ?
[09:00] <jdub> yes
[09:00] <mdz> " Network Administrator's Kick Arse Rollout Guide (Re: kickstart)"
[09:00] <jdub> extensively
[09:01] <jdub> mdz: bounty
[09:01] <mdz> " Devhelp for Python development documentation love"
[09:01] <jdub> mdz: bounty, have candidate
[09:01] <mdz> " Ubuntu in a nutshell style booklet (JeffWaugh?)"
[09:01] <jdub> mdz: bounty
[09:01] <doko> jdub: what should be done?
[09:02] <mdz> we should have more documentation goals
[09:02] <mdz> but we can discuss them later
[09:02] <doko> for the devhelp thing?
[09:02] <sivang> mdz : any connection to redhet's kickstart?
[09:02] <mdz> the doc team can bring that together
[09:02] <sivang> redhat
[09:02] <mdz> sivang: yes, scroll back about an hour
[09:02] <Sensebend> Ubutu in a netshell sounds good
[09:02] <jdub> doko: just making python docs appear in devhelp
[09:02] <mdz> moving on
[09:02] <mdz> X.org
[09:02] <fabbione> yes
[09:02] <mdz> you are on it already
[09:02] <Sensebend> yes! to Xorg!
[09:02] <fabbione> yes
[09:02] <Keybuk> Go Team Denmark! etc.
[09:02] <fabbione> we are progressing slower than expected
[09:02] <mdz> high priority, get it in as soon as possible, fix what breaks
[09:02] <daniels> fabio and I are both on it
[09:03] <doko> jdub: let's talk about it later please
[09:03] <fabbione> mdz: read above
[09:03] <mdz> fabbione: what's a reasonable target date?
[09:03] <fabbione> mdz: we are facing more problems than i expected
[09:03] <fabbione> mdz: possibly end of novemeber
[09:03] <sabdfl> that's late
[09:03] <mdz> yes it is
[09:03] <fabbione> mdz: i am working 15 hours/day on it but i can't sustain this rithm forever
[09:03] <mdz> fabbione: it doesn't need to be perfect
[09:03] <mdz> but it needs to be in
[09:04] <fabbione> mdz: it doens't even compile
[09:04] <fabbione> i have bigger issues than having it perfect
[09:04] <sabdfl> fabbione: can we provide help in any way?
[09:04] <mdz> what about the work that daniels did back in August?
[09:04] <mdz> are you working from that, or from scratch?
[09:04] <fabbione> mdz: we are using all the things we have
[09:04] <fabbione> sabdfl: i will soon need (root) access to amd64 and ppc to test portability
[09:05] <mdz> fabbione: you will have it
[09:05] <sabdfl> fabbione: we have porting boxes available
[09:05] <fabbione> sabdfl, mdz: perfect
[09:05] <fabbione> there are bits that goes in very fast
[09:05] <fabbione> others are a real pain
[09:05] <mdz> fabbione: can we do it in stages?
[09:05] <fabbione> there is not much i can do about it
[09:05] <fabbione> mdz: ?
[09:05] <mdz> e.g., first transition the X server, and then the libs?
[09:05] <fabbione> what you mean by stages?
[09:05] <elmo> fabbione: err, why root?
[09:05] <fabbione> mdz: no
[09:06] <fabbione> elmo: i need to be able to install packages i build on the fly
[09:06] <daniels> elmo: install stuff
[09:06] <daniels> elmo: no longer a single monolithic package, remember
[09:06] <fabbione> elmo: otherwise i need you and/or thom available when i am working on it
[09:06] <fabbione> i/we
[09:06] <jdub> current xorg isn't split out, is it?
[09:06] <daniels> mdz: stepping it in will be more work than just crashing the lot in
[09:06] <daniels> jdub: upstream, no.  packaging, yes.
[09:07] <jdub> daniels: why?
[09:07] <mdz> splitting it out is less important than getting it in early
[09:07] <daniels> jdub: (why ... ?)
[09:07] <mdz> it is perfectly OK to have a monolithic package
[09:07] <fabbione> mdz: it's like the python scripts.. either we get from the beginning or we don't
[09:07] <mdz> that does not make sense to me
[09:07] <fabbione> mdz: and we will still face the same problems later
[09:07] <mdz> it is entirely a bulid-time problem
[09:07] <doko> splitting up a package is much work
[09:07] <jdub> fabbione: but it can be tested in the mean time
[09:07] <mdz> moving binary packages between source packages is easy
[09:08] <jdub> fabbione: or it can be split for grumpy
[09:08] <mdz> once upstream is properly split, we can split along the same lines
[09:08] <fabbione> mdz: we need to upgrade from Xfree and it doesn't make it easier
[09:08] <fabbione> there are hell of dependencies already
[09:08] <mdz> fabbione: source package layout does not affect upgrades
[09:08] <jdub> there are two big issues here
[09:08] <jdub> - managing the upgrade from xfree
[09:08] <jdub> - testing the software itself
[09:09] <fabbione> mdz: till a certain point.
[09:09] <jdub> splitting the package (for the packaging's sake) doesn't assist either of those
[09:09] <mdz> trying to split the source packages early is introducing a lot of unnecessarily complexity
[09:09] <mdz> s/rily/ry/
[09:10] <fabbione> mdz: we will only postpone the problem
[09:10] <mdz> we can afford to postpone that problem
[09:10] <mdz> we cannot afford to postone testing X.org in Hoary
[09:10] <jdub> fabbione: postponing until upstream does the split sounds great :)
[09:10] <fabbione> ok
[09:10] <fabbione> it's your call
[09:10] <jdub> xorg should be one of the first things to hit hoary
[09:11] <mdz> ok, let's delay the split
[09:11] <sabdfl> agreed
[09:11] <fabbione> jdub: it's not like i haven't been working for it
[09:11] <mdz> get something which builds the right binary packages so we can get it in and test
[09:11] <Kamion> OK, I have to go to beat people up^W^W^Wpractice peaceful martial arts now
[09:11] <mdz> fabbione: I understand, and I really appreciate your work
[09:11] <Kamion> back in two hours or less, if you're still going
[09:12] <fabbione> only portion of the patch forwarding costed me 30 hours of work if not more
[09:12] <daniels> upstream split is april/may
[09:12] <mdz> fabbione: we just need to make sure that we focus on the right priorities to make the release
[09:12] <daniels> which will defer our split to grumpy
[09:12] <jdub> fabbione: i grok - the split is a lot of work, and important for different reasons; thank you
[09:12] <mdz> split for grumpy sounds fine
[09:12] <mdz> we have lived with monolithic X for many years
[09:12] <mdz> another 6 months will not kill us
[09:13] <mdz> so let's establish a target for getting X.org uploaded
[09:13] <fabbione> well ok..
[09:13] <fabbione> monolitich tree will be
[09:13] <fabbione> i am not happy about this decision
[09:14] <fabbione> because it will make X drops still complex and slow
[09:14] <fabbione> but i have to accept the fact that we have deadlines
[09:14] <fabbione> dates will be asap
[09:14] <mdz> fabbione: what are the dates of the X sprint?
[09:15] <fabbione> daniels is coming here the 1st of nov until the 14th
[09:15] <mdz> ok
[09:15] <mdz> let's target array CD 3
[09:15] <mdz> November 15
[09:15] <fabbione> so we should be able to upload something usable for that time
[09:15] <mdz> ok
[09:15] <jdub> awesome!
[09:15] <mdz> " Enhanced GDM"
[09:16] <jdub> mdz: bounty, have candidate
[09:16] <mdz> " Process bugs and feedback from the WartyWarthog? release"
[09:16] <jdub> impossible
[09:16] <mdz> not a feature goal :-)
[09:16] <mdz> " GNOME 2.10"
[09:16] <mdz> seb128: all you
[09:16] <seb128> yeah, no problem
[09:16] <mdz>  Easy package install GUI (JeffWaugh?, talking to RossBurton?)
[09:16] <jdub> mdz: bounty, have candidate, almost finished already :)
[09:17] <mdz>  Security update notification GUI (MichaelVogt?)
[09:17] <mdz> mvo_: ?
[09:17] <mvo_> yes
[09:17] <jdub> mdz: depends on splitting .desktop files
[09:17] <mvo_> no problem
[09:17] <jdub> (easy package)
[09:17] <mdz> jdub: right
[09:17] <mdz> not worried about the .desktop files
[09:17] <fabbione> sabdfl, mdz, jdub: if there is nothing more for me i would like to go and get some dinner
[09:17] <mvo_> with update manager application
[09:17] <mdz> " Fax support via efax or the new gfax?"
[09:18] <sabdfl> fabbione: thanks very much!
[09:18] <jdub> not really worth a 'goal'
[09:18] <mdz> fabbione: by all means, thank you
[09:18] <jdub> but george farris is getting gfax ready for inclusion in hoary
[09:18] <fabbione> sabdfl: no! thanks to you!
[09:18] <jdub> gtk/mono-based
[09:18] <jdub> integrates with print system, etc.
[09:18] <fabbione> cya tomorrow
[09:18] <mdz> " Bluetooth GUI, with EddDumbill?'s packages"
[09:18] <doko> jdub: does it support ISDN devices?
[09:18] <jdub> ends up just being a package inclusion
[09:18] <fabbione> sabdfl: also!
[09:18] <jdub> mdz: edd wants to do those, ends up being a seed change
[09:18] <fabbione> sabdfl: welcome to join
[09:19] <fabbione> sabdfl: but the new kitchen will be ready in 2 weeks now :-)
[09:19] <mdz>  Replace fam with gamin
[09:19] <jdub> mdz: seed change
[09:19] <fabbione> sabdfl: i am on microwave and sandwich
[09:19] <sabdfl> bluetooth will be important for the trls
[09:19] <mdz> jdub: does gamin exist?
[09:19] <jdub> mdz: already in universe
[09:19] <mdz> jdub: that's something we should get in as early as possible
[09:19] <mdz> ok
[09:19] <doko> so all the crowd is invited to cook pasta at your home? ;)
[09:19] <jdub> i have updated packages beyond warty ready to upload when i can
[09:19] <sabdfl> jdub: are edd's packages in a state to go in early and get user feedbackl?
[09:19] <jdub> sabdfl: they're in my repo
[09:19] <mdz> " Replace esd with polypaudio"
[09:20] <mdz> another early breakage item
[09:20] <jdub> mdz: seed change
[09:20] <mdz> jdub: oh?
[09:20] <jdub> already in universe
[09:20] <jdub> i would like you to review polypaudio
[09:20] <sabdfl> jdub: what's polyaudio's state in the gnome universe?
[09:20] <mdz> hmm, I thought we were going for dmix
[09:20] <mdz> rather than a replacement sound daemon
[09:20] <jdub> sabdfl: installable, replaces esound
[09:20] <jdub> mdz: this gives us a sane option
[09:20] <sabdfl> g2.10 standard?
[09:20] <jdub> sabdfl: oh, sorry
[09:20] <mdz> jdub: esd-compatible or no?
[09:20] <jdub> i'm hoping that it will replace esound in gnome land
[09:21] <jdub> mdz: protocol compatible
[09:21] <jdub> mdz: apps will still use libesd
[09:21] <mdz> jdub: apps linked with libesd?
[09:21] <mdz> ok
[09:21] <mdz> I thought the plan was to get rid of the sound daemon concept entirely
[09:21] <mdz> and let alsa handle it
[09:21] <Keybuk> mdz: then what multiplexes the sound card?
[09:21] <Keybuk> alsa specifically won't handle it, and are going the other way and saying you need a multiplexer
[09:21] <jdub> mdz: dmix may be rough to configure automagically, has no config tools, and mean syou have to use libalsa for everything
[09:22] <bob2> Keybuk: dmix handles it
[09:22] <bob2> Keybuk: for libasound apps, at least
[09:22] <Keybuk> dmix is a multiplexer daemon though?
[09:22] <mdz> libalsa for everything is doable for desktop
[09:22] <jdub> Keybuk: no, part of liba*
[09:22] <mdz> most of it is there already
[09:22] <jdub> mdz: that's lots of bugfixing, dude
[09:22] <jdub> with uuuuugly alsa
[09:22] <sabdfl> also, alsa api got carrots
[09:22] <mdz> jdub: why is polypaudioi better than esd?
[09:22] <Keybuk> sabdfl: and in en?
[09:23] <jdub> mdz: much, much saner structure, easier to configure, better for sync sound, latency, etc.
[09:23] <sabdfl> "the alsa api received less-than-glowing reivews from warty team members who looked at it"
[09:23] <mdz> sabdfl: true
[09:23] <sabdfl> jdub: as in click, wait, ping!
[09:24] <jdub> mdz: probably a longer discussion involve dhere
[09:24] <mdz> yes
[09:24] <jdub> mdz: but i'd like to start by replacing esound
[09:24] <mdz> if gnome 2.10 is going with polypaudio , we'll start there
[09:24] <sabdfl> if it's in universe let's get it in asap
[09:24] <mdz> and then look into other stuff
[09:24] <sabdfl> i think we should communicate very strongly that hoary will spend large amounts of time BROKEN
[09:24] <mdz> polyp is on the early breakage list
[09:24] <sabdfl> then not fear breaking it
[09:24] <mdz> we're going to break everything at once :-)
[09:24] <mdz>  dns-sd via howl (JeffWaugh?)
[09:24] <mdz> jdub: ?
[09:24] <jdub> mdz: gnome-vfs depends change
[09:24] <bob2> there's a huge number of basically newbies who want to move to hoary
[09:25] <jdub> mdz: brings howl into main
[09:25] <Keybuk> isn't that going to open a port?
[09:25] <bob2> you need to get that message out very very loud
[09:25] <Keybuk> deb http://break-my-computer-and-stamp-on-the-pieces.ubuntu.com/... :p
[09:25] <jdub> mdz: requires security analysis from you for mDNSResponder, and hopefully some configuration thingy to let mDNSResponder default to no-listen and switch to listen
[09:25] <mdz> this is going to be breakage of a scale never before seen :-)
[09:25] <mdz> debian has never broken this much at once
[09:25] <Keybuk> libc5 -> libc6 migration? :p
[09:25] <mdz> jdub: the listening switch sounds like a bounty sort of thing
[09:26] <jdub> mdz: (we could just not install mDNSResponder by default to start with)
[09:26] <mdz> Keybuk: that's one thing
[09:26] <jdub> mdz: agree
[09:26] <mdz> just happened to affect lots of pakcages :-)
[09:26] <jdub> mdz: in which case, have candidate
[09:26] <sivang> mdz : true, but sid's small , harder to notice breakages also stung :)