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)