2004-11-05
#Ubuntu-Meeting
Ubuntu-Meeting Log 2004-11-05
'''Agenda: HoaryKickoffMeeting'''
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
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
06:34 Keybuk <hoary> <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 MeetingLog/Ubuntu/2004-11-05 (last edited 2008-08-06 16:30:30 by localhost)