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)