| === lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-meeting | ||
| === asubedi [~asubedi@pcp04534808pcs.oakrdg01.tn.comcast.net] has joined #ubuntu-meeting | ||
| === asubedi [~asubedi@pcp04534808pcs.oakrdg01.tn.comcast.net] has left #ubuntu-meeting ["Leaving"] | ||
| === tseng [~tseng@thegrebs.com] has joined #ubuntu-meeting | ||
| === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting | ||
| === ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting: Monday, 2004-10-25, 1600UTC | ||
| === ficusplanet [~ficusplan@12-216-226-172.client.mchsi.com] has joined #ubuntu-meeting | ||
| === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting | ||
| === Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting | ||
| === Gmail [~Google@gnu-debian.user] has left #ubuntu-meeting ["Leaving"] | ||
| === Pizbit [~Pizbit@203-79-124-44.adsl.paradise.net.nz] has joined #ubuntu-meeting | ||
| === daniels [daniel@fooishbar.org] has joined #ubuntu-meeting | ||
| === cc [~byte@byte.fedora] has joined #ubuntu-meeting | ||
| === mvo_ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting | ||
| === azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting | ||
| === Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting | ||
| === Sensebend [~steve@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-meeting | ||
| === Gmail [~Google@gnu-debian.user] has left #ubuntu-meeting ["Leaving"] | ||
| === HauntedUnix [~hauntedun@HauntedUnix.student.supporter.pdpc] has joined #ubuntu-meeting | ||
| HauntedUnix | Morning | 03:07 |
|---|---|---|
| === Mitario [~michiel@62.58.176.206] has joined #ubuntu-meeting | ||
| === sivang [~dannyh@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting | ||
| === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting | ||
| === mvo_ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting | ||
| === ploum [~ploum@21-4.CampusNet.ucl.ac.be] has joined #ubuntu-meeting | ||
| sivang | can someone put the agenda link on the channel's topic? | 04:19 |
| === ..[topic/#ubuntu-meeting:bob2] : Hoary kickoff meeting: Monday, 2004-10-25, 1600UTC || Agenda: http://www.ubuntulinux.org/wiki/HoaryKickoffMeeting | ||
| === gruberman [~gruberman@h9n2fls35o294.telia.com] has joined #ubuntu-meeting | ||
| === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting | ||
| === sivang [~dannyh@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting | ||
| === vuntz [~vuntz@fennas.vuntz.net] has joined #ubuntu-meeting | ||
| === enrico [~enrico@81-174-12-206.f5.ngi.it] has joined #ubuntu-meeting | ||
| === Pizbit [~Pizbit@203-79-124-44.adsl.paradise.net.nz] has joined #ubuntu-meeting | ||
| === plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting | ||
| ploum | I put already a link about my opinion | 05:09 |
| ploum | http://ploum.frimouvy.org/?2004/10/25/6-i-dont-want-people-to-use-gnome-applications-anymore | 05:09 |
| === doko [doko@dsl-084-057-024-165.arcor-ip.net] has joined #ubuntu-meeting | ||
| === Keybuk [scott@descent.netsplit.com] has joined #ubuntu-meeting | ||
| doko | I know I am late ... are people already busy working? so quiet ... | 05:29 |
| Keybuk | half an hour early | 05:29 |
| doko | ahh still summertime in the UK? | 05:30 |
| Keybuk | meeting time is UTC, not BST/GMT | 05:31 |
| Keybuk | we're UTC+0100 at the moment | 05:31 |
| === Mitario [~michiel@sikkes.xs4all.nl] has joined #ubuntu-meeting | ||
| lamont | doko: so you're early. :-) | 05:38 |
| doko | lamont: at least that can't be wrong ;) | 05:38 |
| lamont | yeah | 05:39 |
| === tvon [~tvon@h-66-167-145-240.mclnva23.dynamic.covad.net] has joined #ubuntu-meeting | ||
| === jdub [~jdub@home.waugh.id.au] has joined #ubuntu-meeting | ||
| === johnlevin [~johnl@dsl-80-42-84-143.access.uk.tiscali.com] has joined #ubuntu-meeting | ||
| === minghua [~minghua@danube.mems.rice.edu] has joined #ubuntu-meeting | ||
| === bowes [~bowes@blk-215-69-91.eastlink.ca] has joined #ubuntu-meeting | ||
| === seb128 [~seb128@ANancy-151-1-8-118.w83-194.abo.wanadoo.fr] has joined #ubuntu-meeting | ||
| sivang | doko : early enough :) | 05:55 |
| mdz | jdub: are you here for the duration? thanks for staying up | 05:55 |
| 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:56 |
| 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:57 |
| jdub | mdz: no | 05:58 |
| bob2 | "little daniel, it's 4am, let's hack x.org!" | 05:58 |
| === tioui [~arthur@AReims-151-2-2-234.w83-192.abo.wanadoo.fr] has joined #ubuntu-meeting | ||
| === jdub goes to have a sprite recharge | ||
| mdz | ...daniels awakes as a bucket of ice water is emptied over his head | 05:58 |
| Keybuk | right, better get tea | 05:59 |
| === daniels calls ahead to the hotel and sends instructions that no visitors will be allowed. | ||
| daniels | mdz: 4am is generally when I go to sleep these days | 05:59 |
| 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:00 |
| sivang | lamont : good evening, it's 18:00pm here ;-) | 06:01 |
| === Kamion waves | ||
| === enrico says hi | ||
| mdz | me waits a moment for stragglers to arrive | 06:01 |
| === sivang sticks his head up | ||
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting | ||
| sabdfl | hi all | 06:01 |
| pitti | Hi fearless sabdfl! | 06:01 |
| 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:02 |
| mdz | I believe the schedule requires updating to reflect changes to the GNOME 2.10 schedule | 06:03 |
| 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 |
| === LeeColleton [~lc@dsl231-061-247.sea1.dsl.speakeasy.net] has joined #ubuntu-meeting | ||
| 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:04 |
| 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 |
| === rburton [~ross@84.12.22.159] has joined #ubuntu-meeting | ||
| === fabbione runs away screaming | ||
| mdz | elmo: what's the status of the sync infrastructure? | 06:05 |
| === Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting | ||
| 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:06 |
| 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:07 |
| 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 |
| === hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has joined #ubuntu-meeting | ||
| jdub | elmo: it was about hoary while warty was still in devel | 06:08 |
| 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:09 |
| === ogra [~ogra@p508EA4D2.dip.t-dialin.net] has joined #ubuntu-meeting | ||
| 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:10 |
| 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 |
| === inklingx [~inklingx@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting | ||
| fabbione | elmo: perfect | 06:11 |
| === stvn [~steven@82.197.192.33] has joined #ubuntu-meeting | ||
| mdz | so what elmo and I discussed was that his tool would automatically import unmodified packages | 06:11 |
| 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 |
| === Treenaks [martijn@facecrime.net] has joined #ubuntu-meeting | ||
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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 |
| === amu [~amu@195.71.9.198] has joined #ubuntu-meeting | ||
| 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:16 |
| === manuel_ [~manuel@deri-wg1.nuigalway.ie] has joined #ubuntu-meeting | ||
| === darkersatanic [~hugo@mina.ecs.soton.ac.uk] has joined #ubuntu-meeting | ||
| elmo | ok | 06:17 |
| mdz | elmo: what about accessing the morgue? | 06:17 |
| === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting | ||
| === Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has joined #ubuntu-meeting | ||
| 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 |
| === manuel_ [~manuel@deri-wg1.nuigalway.ie] has left #ubuntu-meeting ["Verlassend"] | ||
| 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:17 |
| 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:18 |
| 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 |
| === wulfy [~lorentz@2.wsvw1.xdsl.nauticom.net] has joined #ubuntu-meeting | ||
| mdz | Keybuk: what are the numbers like? | 06:19 |
| 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:20 |
| 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 |
| === vrln [~vrln@195.10.181.201] has joined #ubuntu-meeting | ||
| 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:21 |
| sabdfl | right | 06:22 |
| doko | sabdfl: but not for all of the installer packages (s/Debian/Ubuntu). | 06:22 |
| === Peltoilves [~peltis@tolu.edu.hel.fi] has joined #ubuntu-meeting | ||
| 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:22 |
| sabdfl | but wn't help maintain an effective long-lived branch | 06:23 |
| === helix [~helix@helix.user] has joined #ubuntu-meeting | ||
| 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 |
| === Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has left #ubuntu-meeting ["Leaving"] | ||
| 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:23 |
| 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:24 |
| 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:25 |
| === darkersatanic [~hugo@mina.ecs.soton.ac.uk] has left #ubuntu-meeting ["Client] | ||
| 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:26 |
| Keybuk | daf: "ubuntu changes" and "debian changes" | 06:27 |
| mdz | Keybuk: output/ is the result of applying debian/ to warty-current? | 06:27 |
| === nreid [~nreid@host81-139-0-78.in-addr.btopenworld.com] has joined #ubuntu-meeting | ||
| 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:27 |
| 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:28 |
| 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:29 |
| === MrTom [~thomas@84.97.17.128] has joined #ubuntu-meeting | ||
| 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:30 |
| 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 |
| === sivang agrees with pitti | ||
| 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:31 |
| 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:32 |
| === enrico agrees with sivang and pitti | ||
| 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 |
| === jono [~jono@82-37-194-90.cable.ubr05.wolv.blueyonder.co.uk] has joined #ubuntu-meeting | ||
| Keybuk | it's the debian changelog entries conflicting | 06:33 |
| 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:34 |
| 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:35 |
| 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 |
| === neuro|laptop [~neuro@neuro.me.uk] has joined #ubuntu-meeting | ||
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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 |
| === enrico was thinking filesystem charset, too | ||
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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 |
| === pollianicus [~lucy@82-68-75-30.dsl.in-addr.zen.co.uk] has joined #ubuntu-meeting | ||
| === pollianicus [~lucy@82-68-75-30.dsl.in-addr.zen.co.uk] has left #ubuntu-meeting [] | ||
| 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:54 |
| 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:55 |
| === sivang thought it was going to be for GTK/GNOME wise | ||
| 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:56 |
| 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:57 |
| === mdz ducks | ||
| 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:58 |
| 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 | 06:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| === maskie [~maskie@196-30-111-250.uudial.uunet.co.za] has joined #ubuntu-meeting | ||
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| === AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting | ||
| mdz | I assume this would only provide basic support for compiling and running 32-bit apps | 07:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| === Seveas [seveas@213-73-236-154.cable.quicknet.nl] has joined #ubuntu-meeting | ||
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| sabdfl | Keybuk: i think we will aim to provide a high level UI for that | 07:19 |
| === ogra agrees with mdz | ||
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| === mdz channels harder | ||
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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 |
| === azeem suggests talking to jbailey for glibc | ||
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| mjg59 | If you're running slow, ntpdate will make your screensaver come on | 07:49 |
| === enrico leaves the meeting | ||
| 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 |
| === enrico [~enrico@81-174-12-206.f5.ngi.it] has left #ubuntu-meeting [] | ||
| 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 |
| === martinald [~hm@martinalderson.plus.com] has joined #ubuntu-meeting | ||
| mdz | Keybuk: hauling perl into memory was a big win | 07:49 |
| mjg59 | mdz: The results from gettimeofday() suddenly change... | 07:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 |
| === oOpepinOo [~yann@lns-vlq-39f-81-56-131-220.adsl.proxad.net] has joined #ubuntu-meeting | ||
| 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 | 07:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| sabdfl | not by default | 08:03 |
| pitti | if he logs in, his homedir is transparently decrypted | 08:03 |
| === jdub likes the idea of crypto partition gui love, but not convinced about supporting crypto home stuf | ||
| === Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has joined #ubuntu-meeting | ||
| 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 |
| === Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has left #ubuntu-meeting ["Leaving"] | ||
| 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:03 |
| 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:04 |
| 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:05 |
| 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 |
| === mvo_ likes the idea of encrypted /home | ||
| ogra | but can i decrypt easily | 08:06 |
| 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 |
| === mjg59 is back | ||
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| === mvo_ is happy about that | ||
| 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:11 |
| 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:12 |
| 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:13 |
| === johnlevin [~johnl@dsl-80-42-84-143.access.uk.tiscali.com] has left #ubuntu-meeting ["Leaving"] | ||
| mdz | sabdfl: gui installer decision? | 08:14 |
| sabdfl | not for hoary | 08:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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 |
| === Peltoilves [~peltis@tolu.edu.hel.fi] has left #ubuntu-meeting [] | ||
| mdz | we will ask once, and ask very thoroughly | 08:20 |
| daniels | right | 08:20 |
| === siretart [siretart@meinungsverstaerker.de] has joined #ubuntu-meeting | ||
| 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:20 |
| 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:21 |
| 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:22 |
| 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 |
| === ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting | ||
| lamont | fabbione: define "reach" | 08:23 |
| === ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting || Agenda: http://www.ubuntulinux.org/wiki/HoaryKickoffMeeting | ||
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| lamont | and sudo password | 08:28 |
| Keybuk | mdz: auto-run of binaries signed by a key in a keyring type thing? | 08:28 |
| === Kamion mails sabdfl a batch of trojaned CDs, just for fun | ||
| === sabdfl installs everything Kamion sends me, just for fun | ||
| 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:28 |
| 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:29 |
| 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:30 |
| === fabbione did it once | ||
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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 |
| === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] | ||
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| Kamion | otherwise users will have a hell of a time building packages | 08:52 |
| === Keybuk makes a note to be on holiday at hoary->grumpy merge :p | ||
| 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:52 |
| 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:53 |
| 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 |
| === Keybuk tries to think of an unlocalised library | ||
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| doko | jdub: let's talk about it later please | 09:03 |
| fabbione | mdz: read above | 09:03 |
| mdz | fabbione: what's a reasonable target date? | 09:03 |
| fabbione | mdz: we are facing more problems than i expected | 09:03 |
| fabbione | mdz: possibly end of novemeber | 09:03 |
| sabdfl | that's late | 09:03 |
| mdz | yes it is | 09:03 |
| fabbione | mdz: i am working 15 hours/day on it but i can't sustain this rithm forever | 09:03 |
| mdz | fabbione: it doesn't need to be perfect | 09:03 |
| mdz | but it needs to be in | 09:03 |
| fabbione | mdz: it doens't even compile | 09:04 |
| fabbione | i have bigger issues than having it perfect | 09:04 |
| sabdfl | fabbione: can we provide help in any way? | 09:04 |
| mdz | what about the work that daniels did back in August? | 09:04 |
| mdz | are you working from that, or from scratch? | 09:04 |
| fabbione | mdz: we are using all the things we have | 09:04 |
| fabbione | sabdfl: i will soon need (root) access to amd64 and ppc to test portability | 09:04 |
| mdz | fabbione: you will have it | 09:05 |
| sabdfl | fabbione: we have porting boxes available | 09:05 |
| fabbione | sabdfl, mdz: perfect | 09:05 |
| fabbione | there are bits that goes in very fast | 09:05 |
| fabbione | others are a real pain | 09:05 |
| mdz | fabbione: can we do it in stages? | 09:05 |
| fabbione | there is not much i can do about it | 09:05 |
| fabbione | mdz: ? | 09:05 |
| mdz | e.g., first transition the X server, and then the libs? | 09:05 |
| fabbione | what you mean by stages? | 09:05 |
| elmo | fabbione: err, why root? | 09:05 |
| fabbione | mdz: no | 09:05 |
| fabbione | elmo: i need to be able to install packages i build on the fly | 09:06 |
| daniels | elmo: install stuff | 09:06 |
| daniels | elmo: no longer a single monolithic package, remember | 09:06 |
| fabbione | elmo: otherwise i need you and/or thom available when i am working on it | 09:06 |
| fabbione | i/we | 09:06 |
| jdub | current xorg isn't split out, is it? | 09:06 |
| daniels | mdz: stepping it in will be more work than just crashing the lot in | 09:06 |
| daniels | jdub: upstream, no. packaging, yes. | 09:06 |
| jdub | daniels: why? | 09:07 |
| mdz | splitting it out is less important than getting it in early | 09:07 |
| daniels | jdub: (why ... ?) | 09:07 |
| mdz | it is perfectly OK to have a monolithic package | 09:07 |
| fabbione | mdz: it's like the python scripts.. either we get from the beginning or we don't | 09:07 |
| mdz | that does not make sense to me | 09:07 |
| fabbione | mdz: and we will still face the same problems later | 09:07 |
| mdz | it is entirely a bulid-time problem | 09:07 |
| doko | splitting up a package is much work | 09:07 |
| jdub | fabbione: but it can be tested in the mean time | 09:07 |
| mdz | moving binary packages between source packages is easy | 09:07 |
| jdub | fabbione: or it can be split for grumpy | 09:08 |
| mdz | once upstream is properly split, we can split along the same lines | 09:08 |
| fabbione | mdz: we need to upgrade from Xfree and it doesn't make it easier | 09:08 |
| fabbione | there are hell of dependencies already | 09:08 |
| mdz | fabbione: source package layout does not affect upgrades | 09:08 |
| jdub | there are two big issues here | 09:08 |
| jdub | - managing the upgrade from xfree | 09:08 |
| jdub | - testing the software itself | 09:08 |
| === MrTom [~thomas@84.97.17.128] has joined #ubuntu-meeting | ||
| fabbione | mdz: till a certain point. | 09:09 |
| jdub | splitting the package (for the packaging's sake) doesn't assist either of those | 09:09 |
| mdz | trying to split the source packages early is introducing a lot of unnecessarily complexity | 09:09 |
| mdz | s/rily/ry/ | 09:09 |
| fabbione | mdz: we will only postpone the problem | 09:10 |
| mdz | we can afford to postpone that problem | 09:10 |
| mdz | we cannot afford to postone testing X.org in Hoary | 09:10 |
| jdub | fabbione: postponing until upstream does the split sounds great :) | 09:10 |
| fabbione | ok | 09:10 |
| fabbione | it's your call | 09:10 |
| jdub | xorg should be one of the first things to hit hoary | 09:10 |
| mdz | ok, let's delay the split | 09:11 |
| sabdfl | agreed | 09:11 |
| fabbione | jdub: it's not like i haven't been working for it | 09:11 |
| mdz | get something which builds the right binary packages so we can get it in and test | 09:11 |
| Kamion | OK, I have to go to beat people up^W^W^Wpractice peaceful martial arts now | 09:11 |
| mdz | fabbione: I understand, and I really appreciate your work | 09:11 |
| Kamion | back in two hours or less, if you're still going | 09:11 |
| fabbione | only portion of the patch forwarding costed me 30 hours of work if not more | 09:12 |
| daniels | upstream split is april/may | 09:12 |
| mdz | fabbione: we just need to make sure that we focus on the right priorities to make the release | 09:12 |
| daniels | which will defer our split to grumpy | 09:12 |
| jdub | fabbione: i grok - the split is a lot of work, and important for different reasons; thank you | 09:12 |
| mdz | split for grumpy sounds fine | 09:12 |
| mdz | we have lived with monolithic X for many years | 09:12 |
| mdz | another 6 months will not kill us | 09:12 |
| mdz | so let's establish a target for getting X.org uploaded | 09:13 |
| fabbione | well ok.. | 09:13 |
| fabbione | monolitich tree will be | 09:13 |
| fabbione | i am not happy about this decision | 09:13 |
| fabbione | because it will make X drops still complex and slow | 09:14 |
| fabbione | but i have to accept the fact that we have deadlines | 09:14 |
| fabbione | dates will be asap | 09:14 |
| mdz | fabbione: what are the dates of the X sprint? | 09:14 |
| fabbione | daniels is coming here the 1st of nov until the 14th | 09:15 |
| mdz | ok | 09:15 |
| mdz | let's target array CD 3 | 09:15 |
| mdz | November 15 | 09:15 |
| fabbione | so we should be able to upload something usable for that time | 09:15 |
| mdz | ok | 09:15 |
| jdub | awesome! | 09:15 |
| mdz | " Enhanced GDM" | 09:15 |
| jdub | mdz: bounty, have candidate | 09:16 |
| mdz | " Process bugs and feedback from the WartyWarthog? release" | 09:16 |
| jdub | impossible | 09:16 |
| mdz | not a feature goal :-) | 09:16 |
| mdz | " GNOME 2.10" | 09:16 |
| mdz | seb128: all you | 09:16 |
| seb128 | yeah, no problem | 09:16 |
| mdz | Easy package install GUI (JeffWaugh?, talking to RossBurton?) | 09:16 |
| jdub | mdz: bounty, have candidate, almost finished already :) | 09:16 |
| mdz | Security update notification GUI (MichaelVogt?) | 09:17 |
| mdz | mvo_: ? | 09:17 |
| mvo_ | yes | 09:17 |
| jdub | mdz: depends on splitting .desktop files | 09:17 |
| mvo_ | no problem | 09:17 |
| jdub | (easy package) | 09:17 |
| mdz | jdub: right | 09:17 |
| mdz | not worried about the .desktop files | 09:17 |
| fabbione | sabdfl, mdz, jdub: if there is nothing more for me i would like to go and get some dinner | 09:17 |
| mvo_ | with update manager application | 09:17 |
| mdz | " Fax support via efax or the new gfax?" | 09:17 |
| sabdfl | fabbione: thanks very much! | 09:18 |
| jdub | not really worth a 'goal' | 09:18 |
| mdz | fabbione: by all means, thank you | 09:18 |
| jdub | but george farris is getting gfax ready for inclusion in hoary | 09:18 |
| fabbione | sabdfl: no! thanks to you! | 09:18 |
| jdub | gtk/mono-based | 09:18 |
| jdub | integrates with print system, etc. | 09:18 |
| fabbione | cya tomorrow | 09:18 |
| mdz | " Bluetooth GUI, with EddDumbill?'s packages" | 09:18 |
| doko | jdub: does it support ISDN devices? | 09:18 |
| jdub | ends up just being a package inclusion | 09:18 |
| === sabdfl thought fabbione was offering to get me some dinner | ||
| fabbione | sabdfl: also! | 09:18 |
| jdub | mdz: edd wants to do those, ends up being a seed change | 09:18 |
| fabbione | sabdfl: welcome to join | 09:18 |
| fabbione | sabdfl: but the new kitchen will be ready in 2 weeks now :-) | 09:19 |
| mdz | Replace fam with gamin | 09:19 |
| jdub | mdz: seed change | 09:19 |
| fabbione | sabdfl: i am on microwave and sandwich | 09:19 |
| sabdfl | bluetooth will be important for the trls | 09:19 |
| mdz | jdub: does gamin exist? | 09:19 |
| jdub | mdz: already in universe | 09:19 |
| mdz | jdub: that's something we should get in as early as possible | 09:19 |
| mdz | ok | 09:19 |
| doko | so all the crowd is invited to cook pasta at your home? ;) | 09:19 |
| jdub | i have updated packages beyond warty ready to upload when i can | 09:19 |
| sabdfl | jdub: are edd's packages in a state to go in early and get user feedbackl? | 09:19 |
| jdub | sabdfl: they're in my repo | 09:19 |
| mdz | " Replace esd with polypaudio" | 09:19 |
| mdz | another early breakage item | 09:20 |
| jdub | mdz: seed change | 09:20 |
| mdz | jdub: oh? | 09:20 |
| jdub | already in universe | 09:20 |
| jdub | i would like you to review polypaudio | 09:20 |
| sabdfl | jdub: what's polyaudio's state in the gnome universe? | 09:20 |
| === MrTom is now known as MrTom-away | ||
| mdz | hmm, I thought we were going for dmix | 09:20 |
| mdz | rather than a replacement sound daemon | 09:20 |
| jdub | sabdfl: installable, replaces esound | 09:20 |
| jdub | mdz: this gives us a sane option | 09:20 |
| sabdfl | g2.10 standard? | 09:20 |
| jdub | sabdfl: oh, sorry | 09:20 |
| mdz | jdub: esd-compatible or no? | 09:20 |
| jdub | i'm hoping that it will replace esound in gnome land | 09:20 |
| jdub | mdz: protocol compatible | 09:21 |
| jdub | mdz: apps will still use libesd | 09:21 |
| mdz | jdub: apps linked with libesd? | 09:21 |
| mdz | ok | 09:21 |
| mdz | I thought the plan was to get rid of the sound daemon concept entirely | 09:21 |
| mdz | and let alsa handle it | 09:21 |
| Keybuk | mdz: then what multiplexes the sound card? | 09:21 |
| Keybuk | alsa specifically won't handle it, and are going the other way and saying you need a multiplexer | 09:21 |
| jdub | mdz: dmix may be rough to configure automagically, has no config tools, and mean syou have to use libalsa for everything | 09:21 |
| bob2 | Keybuk: dmix handles it | 09:22 |
| bob2 | Keybuk: for libasound apps, at least | 09:22 |
| Keybuk | dmix is a multiplexer daemon though? | 09:22 |
| mdz | libalsa for everything is doable for desktop | 09:22 |
| jdub | Keybuk: no, part of liba* | 09:22 |
| mdz | most of it is there already | 09:22 |
| jdub | mdz: that's lots of bugfixing, dude | 09:22 |
| jdub | with uuuuugly alsa | 09:22 |
| sabdfl | also, alsa api got carrots | 09:22 |
| mdz | jdub: why is polypaudioi better than esd? | 09:22 |
| Keybuk | sabdfl: and in en? | 09:22 |
| jdub | mdz: much, much saner structure, easier to configure, better for sync sound, latency, etc. | 09:23 |
| sabdfl | "the alsa api received less-than-glowing reivews from warty team members who looked at it" | 09:23 |
| mdz | sabdfl: true | 09:23 |
| sabdfl | jdub: as in click, wait, ping! | 09:23 |
| jdub | mdz: probably a longer discussion involve dhere | 09:24 |
| mdz | yes | 09:24 |
| jdub | mdz: but i'd like to start by replacing esound | 09:24 |
| mdz | if gnome 2.10 is going with polypaudio , we'll start there | 09:24 |
| sabdfl | if it's in universe let's get it in asap | 09:24 |
| mdz | and then look into other stuff | 09:24 |
| sabdfl | i think we should communicate very strongly that hoary will spend large amounts of time BROKEN | 09:24 |
| mdz | polyp is on the early breakage list | 09:24 |
| sabdfl | then not fear breaking it | 09:24 |
| mdz | we're going to break everything at once :-) | 09:24 |
| mdz | dns-sd via howl (JeffWaugh?) | 09:24 |
| mdz | jdub: ? | 09:24 |
| jdub | mdz: gnome-vfs depends change | 09:24 |
| bob2 | there's a huge number of basically newbies who want to move to hoary | 09:24 |
| jdub | mdz: brings howl into main | 09:25 |
| Keybuk | isn't that going to open a port? | 09:25 |
| bob2 | you need to get that message out very very loud | 09:25 |
| Keybuk | deb http://break-my-computer-and-stamp-on-the-pieces.ubuntu.com/... :p | 09:25 |
| jdub | mdz: requires security analysis from you for mDNSResponder, and hopefully some configuration thingy to let mDNSResponder default to no-listen and switch to listen | 09:25 |
| mdz | this is going to be breakage of a scale never before seen :-) | 09:25 |
| mdz | debian has never broken this much at once | 09:25 |
| Keybuk | libc5 -> libc6 migration? :p | 09:25 |
| mdz | jdub: the listening switch sounds like a bounty sort of thing | 09:25 |
| jdub | mdz: (we could just not install mDNSResponder by default to start with) | 09:26 |
| mdz | Keybuk: that's one thing | 09:26 |
| jdub | mdz: agree | 09:26 |
| mdz | just happened to affect lots of pakcages :-) | 09:26 |
| jdub | mdz: in which case, have candidate | 09:26 |
| sivang | mdz : true, but sid's small , harder to notice breakages also stung :) | 09:26 |
| Keybuk | mdz: in sufficiently incompatible ways that it wasn't *bootable* for long periods :p | 09:26 |
| sabdfl | jdub, mdz, how are we going to resolve the fundamental difference between "rendevous (howl) is awesome" and "don't listen by default"? | 09:26 |
| mdz | jdub: I'll mark it for further discussion, we'll break it down | 09:26 |
| mdz | sabdfl: require the user to check a box to turn it on | 09:26 |
| Keybuk | sabdfl: put them in a ring and let them fight it out? | 09:27 |
| jdub | sabdfl: by taking your clothes, tying you to a chair, and... oh, or providing a configuration item to turn it on | 09:27 |
| === sabdfl thinks this sounds just like boarding school | ||
| Keybuk | jdub: can we have a cups configuration next to that? | 09:27 |
| jdub | Keybuk: i think this ends up being part of our 'services configuration' thingy | 09:27 |
| jdub | Keybuk: bounty ;) | 09:27 |
| mdz | the CUPS configuration thing sounds simpler; it should just open up its port when you're looking to add a printer | 09:27 |
| jdub | Keybuk: plus discussion ;) | 09:27 |
| mdz | no point in sitting around listening all the time | 09:27 |
| mdz | improved panel: | 09:28 |
| mdz | jdub: ? | 09:28 |
| jdub | mdz: bounty, have candidate | 09:28 |
| sabdfl | how does cups know when someone else on the network wants to install a printer? | 09:28 |
| mdz | accessible by default + include a11y packages? (JeffWaugh?) | 09:28 |
| mdz | sabdfl: we're talking about the client end of it | 09:28 |
| mdz | the print server will have a port open all the time | 09:28 |
| Keybuk | mdz: I was talking about the server end | 09:28 |
| jdub | mdz: dump as official goal, leave to community and 'research and development' derivative | 09:28 |
| mdz | but the thing we disabled was that the client currently needs a port open all the time in order ot browse | 09:28 |
| sabdfl | right | 09:28 |
| mdz | Some kind of reasonable video playback support (Fluendo's DVD Player?) | 09:28 |
| sabdfl | so "share printer" makes you a print server, and slightly vulnerable, but it's your option | 09:29 |
| jdub | mdz: requires further discussion | 09:29 |
| mdz | User management (e.g., select whether new users should have local device access or not) | 09:29 |
| mdz | pitti: ? | 09:29 |
| pitti | mdz: yes :-) | 09:29 |
| mdz | this is a patch to g-s-t, right? | 09:29 |
| doko | that's a pam thing? | 09:29 |
| pitti | mdz: in gnome system tools? | 09:29 |
| mdz | pitti: yes | 09:30 |
| mdz | a small one, I think | 09:30 |
| mdz | pitti: will you do it? | 09:30 |
| pitti | mdz: yes | 09:30 |
| mdz | Remote desktop and rocking terminal support with NX? (TollefFogHeen?) | 09:30 |
| jdub | (we could bounty the author on that one, too) | 09:30 |
| mdz | Mithrandir is not here | 09:30 |
| mdz | anyone know what that's about? | 09:30 |
| jdub | integrating nomachine nx | 09:30 |
| jdub | definitely an attractive goal | 09:30 |
| ogra | in vino | 09:30 |
| jdub | no, just generally | 09:30 |
| jdub | not related to vino | 09:31 |
| mdz | which is some sort of vnc-ish thing? | 09:31 |
| sabdfl | low-bandwidth x | 09:31 |
| bob2 | super-low-bandwidth X | 09:31 |
| ogra | mdz: way faster | 09:31 |
| Keybuk | NX is "make my X go really really fast" | 09:31 |
| Keybuk | (over a network) | 09:31 |
| sabdfl | combined with ltsp, will rock | 09:31 |
| daniels | yes | 09:31 |
| jdub | usually used for terminals, rather than sharing current session | 09:31 |
| daniels | parts of it are free, parts are non-free | 09:31 |
| mdz | X extension? | 09:31 |
| daniels | freenx is a 500-line shell script to tie shit together | 09:31 |
| daniels | no | 09:31 |
| mdz | or separate protocol? | 09:31 |
| jdub | special server | 09:31 |
| daniels | runs a proxying, caching server | 09:31 |
| amu | mdz: ... woorks with a goof compression, working with a modem line is very very fast compared to vnc | 09:31 |
| mdz | what's involved in the feature for hoary? | 09:32 |
| daniels | separate protocol/server, also interoperates with os x and windows if you buy their product | 09:32 |
| mdz | packaging the thing? | 09:32 |
| jdub | yeah | 09:32 |
| daniels | packaging, yes | 09:32 |
| sabdfl | daniels: what parts are non-free, and can it be usefully used as entirely free config? | 09:32 |
| jdub | packaging + seed | 09:32 |
| mdz | who will do the work? | 09:33 |
| jdub | perhaps leave it for tollef to answer | 09:33 |
| doko | can do it | 09:33 |
| jdub | he has already done bits | 09:33 |
| daniels | sabdfl: i believe you can get an entire freenx setup with free licences | 09:33 |
| mdz | ok, will check with tollef | 09:33 |
| mdz | Attempt to standardise on process elevation method throughout GNOME | 09:33 |
| tseng | knoppix already includes bits of freen | 09:33 |
| tseng | x | 09:33 |
| sabdfl | and the non-free stuff is what? optimised? | 09:33 |
| jdub | mdz: not convinced it's a useful goal for hoary | 09:33 |
| mdz | punting | 09:33 |
| mdz | Thought: Replace Gnome's default palm only sync with MultiSync? for syncing with many more devices? (BenjaminLong?) | 09:34 |
| jdub | mdz: can do as bounty for grumpy, can think of potential candidate | 09:34 |
| Keybuk | whoever wrote that is on crack, multisync doesn't work with evo 2.0, only 1.4 | 09:34 |
| sabdfl | sounds like a gnome job, not a hoary job | 09:34 |
| daniels | sabdfl: i think most of their integration is non-free but there are hacks around that | 09:34 |
| jdub | multisync isn't ready for integration | 09:34 |
| sabdfl | "their"? | 09:34 |
| sabdfl | jdub: is it the platform to build on top of though? | 09:34 |
| mdz | we had proposed a bounty of getting it into shape | 09:34 |
| jdub | especially if intended as a replacement for current palm foo | 09:34 |
| jdub | sabdfl: potentially - needs a lot of work | 09:35 |
| Keybuk | I looked through multisync briefly and I wasn't impressed | 09:35 |
| sabdfl | is it actively maintained? | 09:35 |
| mdz | several apparently major bugs on the current palm-fu | 09:35 |
| jdub | the general idea is right, but lots of mess gui and implimentation wise | 09:35 |
| lamont | Keybuk: I played with evo sync briefly, was so impressed I went back to jpilot | 09:35 |
| mdz | if there isn't something there to build on, we can't do this for hoary | 09:35 |
| jdub | sabdfl: not in a very strongly directed fashion ;) | 09:35 |
| jdub | mdz: i'd say punt | 09:35 |
| jdub | mdz: people can love it in universe | 09:35 |
| sabdfl | ok, pass | 09:35 |
| mdz | " Better sounds: for example new mail sound, preconfigured correctly" | 09:35 |
| mdz | sounds like random criticism of the audio theme :-) | 09:36 |
| jdub | wouldn't want to commit to supporting it | 09:36 |
| sabdfl | pity, because PDA stuff is going to be very important | 09:36 |
| sabdfl | erm, that was me | 09:36 |
| tseng | evo sync to palm is an "almost works, sortof" | 09:36 |
| mdz | sabdfl: something we should do professionally? | 09:36 |
| doko | hmm, turning off single sounds in sound themes would be nice | 09:36 |
| sabdfl | we need to review every desktop app for sound integration so it all works well together | 09:36 |
| mdz | sabdfl: I know people who could do very slick sounds for us | 09:36 |
| sabdfl | like, thunderbird's new mail sound was just a beep post-install | 09:37 |
| sabdfl | mdz: great, ping me separately/ | 09:37 |
| elmo | yay, someone do a slick sound that sabdfl can use on his damn jabber client ;-P | 09:37 |
| sivang | xchat's too | 09:37 |
| Keybuk | and gaim could do with something a little cuter than the fingers-on-blackboard ring | 09:37 |
| sabdfl | "hassole" | 09:37 |
| Keybuk | and gossip could do with something louder than its shy little peep | 09:37 |
| mdz | so this particular item is just about making sound events more integrated and consistent? | 09:37 |
| Keybuk | elmo: AWOOGA! | 09:37 |
| jdub | DIVE! DIVE! | 09:37 |
| thom | elmo: "WOO WOO" | 09:37 |
| sabdfl | can we do "sounds froma nudist colony"? | 09:38 |
| ogra | lol | 09:38 |
| jdub | sabdfl: 'slap!' 'squish!' etc? | 09:38 |
| mdz | what's the hoary piece of this? | 09:38 |
| thom | sabdfl: the "you can't show tits on the radio" theme | 09:38 |
| mdz | review all desktop apps and make them use sound consistently? | 09:38 |
| sabdfl | mdz: yes | 09:38 |
| jdub | mdz: bounty for sounds, fix badly chosen sound bugs in packages | 09:38 |
| mdz | sabdfl: just using a consistent set of sounds, or adding sound stuff where it isn't currently present? | 09:39 |
| sabdfl | (a) creating a good sound theme | 09:39 |
| mdz | e.g., stuff which just beeps | 09:39 |
| sabdfl | (b) making sure all apps which use sound are correctly integrated to the theme | 09:39 |
| sabdfl | so gossip and gaim could use the same sounds | 09:39 |
| sabdfl | thunderbird and evo | 09:39 |
| sabdfl | for new mail, new im, etc | 09:39 |
| mdz | ok | 09:39 |
| mdz | but if an app only supports the console bell, or no sounds at all, we leave it alone? | 09:40 |
| sabdfl | basically, file bugs on packages where there are sound theme inconsistencies or unusabilities | 09:40 |
| sabdfl | yes | 09:40 |
| mdz | ok | 09:40 |
| sabdfl | no bash sound theme needed | 09:40 |
| mdz | bounty? | 09:40 |
| mdz | (a) I have bounty leads | 09:40 |
| Keybuk | sabdfl: Gentoo ... it's only a matter of time | 09:40 |
| sabdfl | contract for the overall theme, bugs for apps that don't integrate | 09:40 |
| doko | "command not found" sound ... | 09:40 |
| mdz | (b) we need someone to do the review and file bugs | 09:40 |
| mdz | jdub: ? | 09:40 |
| sabdfl | i think once the team knows this is important they will file bugs | 09:41 |
| Keybuk | doko: "D'oh!" | 09:41 |
| jdub | mdz: hrm? | 09:41 |
| azeem | (about multisync, I read the people behind it work on a sane replacement called opensync, which is supposed to by a fd.org standard) | 09:41 |
| Keybuk | azeem: what isn't these days? | 09:41 |
| daniels | hosted at fd.o, don't know how much movement there's been. | 09:41 |
| jdub | azeem: yeah, opensync is pretty far from ready | 09:41 |
| daniels | hosted != standard | 09:41 |
| mdz | ok, so we won't make this an official goal, and just file bugs | 09:41 |
| sabdfl | sync punted -> grumpy | 09:41 |
| mdz | Improved network integration? | 09:42 |
| mdz | NetworkManager | 09:42 |
| Keybuk | thom? | 09:42 |
| mdz | thom: you're packaging it? | 09:42 |
| azeem | daniels: I asked about multisync for an unrelated matter, and found a post by one of the guys saying a first opensync preview release was imminent | 09:42 |
| mdz | assuming thom will take that one | 09:42 |
| sabdfl | thom was showing it off here last week | 09:42 |
| sabdfl | looking pretty good | 09:42 |
| sabdfl | needs to be integrated with the broader picture of ifup ifdown | 09:42 |
| thom | sorry | 09:42 |
| thom | yes | 09:42 |
| jdub | lots of opportunities for NM integration in various programs | 09:42 |
| jdub | like evolution, etc. | 09:43 |
| mdz | thom: all of the sub-goals under that heading have been moved under networkmanager | 09:43 |
| mdz | thom: is that accurate? | 09:43 |
| mdz | we don't need anything else? | 09:43 |
| jdub | some patches have already been written by RH dudes | 09:43 |
| mdz | what about, e.g., not bringing the interface up at boot? | 09:43 |
| thom | mdz: checking, but i think so | 09:43 |
| mdz | does networkmanager integrate with ifupdow? | 09:43 |
| mdz | ifupdown? | 09:43 |
| Keybuk | jdub: Colin's crusade against the "Network Error" dialog? | 09:43 |
| sivang | jdub : i.e ? | 09:43 |
| jdub | Keybuk: yeah (and clark's) | 09:43 |
| thom | mdz: not as yet, intend for it to do so soon | 09:43 |
| jdub | so beyond packaging, there's integration work to do | 09:43 |
| mdz | thom: will you take that on as well? | 09:44 |
| thom | not sure about zeroconf | 09:44 |
| sivang | mdz : and there's the trashing interfaces file when starting from skreatch no conffiles | 09:44 |
| Keybuk | is a good hoary goal | 09:44 |
| thom | mdz: yes | 09:44 |
| tseng | there is fixing to do in networkmanager itself before its ripe to be a core component | 09:44 |
| jdub | TRLS! Yeah! | 09:44 |
| mdz | hmm, there's stuff under there that is clearly no tnetworkmanager stuff | 09:44 |
| mdz | so, zeroconf -> hoary | 09:44 |
| mdz | Kamion: what about the wireless/installer bit? | 09:44 |
| mdz | oh, he went away | 09:44 |
| mdz | Don't ask for WEP / ESSID details during install if they are not really needed | 09:44 |
| mdz | probably just file a bug about that | 09:44 |
| thom | yep | 09:45 |
| sabdfl | plus, try the various essid's in of signal strength | 09:45 |
| mdz | IrDA | 09:45 |
| jdub | you're skipping the zeroconf bits? | 09:45 |
| mdz | does someone here care about IrDA? :-) | 09:45 |
| jdub | that sebastien added? | 09:45 |
| sabdfl | pass | 09:45 |
| mdz | jdub: I thought zeroconf was ->grumpy | 09:45 |
| sabdfl | what's the diff between zeroconf and howl? | 09:46 |
| mdz | I thought howl was an implementation of zeroconf | 09:46 |
| mdz | but surely there is lots of integration to do | 09:46 |
| jdub | sabdfl: howl provides implementations of the two sides of zeroconf | 09:46 |
| thom | sabdfl: howl is a zeroconf implementation | 09:46 |
| mdz | once we have howl, there are lots of things to hook it into | 09:46 |
| jdub | there is a NetworkManager/Howl integration possibility here, for local lan | 09:46 |
| sabdfl | is howl out there, and stable? | 09:47 |
| thom | you can get network details from zeroconf, which would need to tie into NM | 09:47 |
| jdub | plus there is the nss issue for .local | 09:47 |
| jdub | sabdfl: i package it | 09:47 |
| === lamont gets dragged out the door by his wife, back in ~2 hours or so | ||
| jdub | sabdfl: it is a dependency of gnome-vfs already | 09:47 |
| sabdfl | ok | 09:47 |
| thom | that's another reason for new glibc, by the way | 09:47 |
| jdub | sabdfl: (not in warty) | 09:47 |
| thom | useful nameservice reloading stuff | 09:47 |
| mdz | ok | 09:47 |
| mdz | so what can we reasonable do with howl/zeroconf for hoary? | 09:47 |
| jdub | mdz: perhaps we should just talk about zeroconf issues between you, thom and i | 09:47 |
| mdz | s/able/ably/ | 09:47 |
| mdz | -> further discussion | 09:47 |
| tseng | gnome-vfs support is as easy as a build | 09:48 |
| jdub | tseng: (already covered earlier) | 09:48 |
| mdz | Support users who don't want to use the restricted component | 09:48 |
| mdz | sounds like a couple of simple d-i changes | 09:48 |
| Keybuk | bug for kamion | 09:48 |
| mdz | will discuss with colin when he gets back | 09:48 |
| === mvo__ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting | ||
| mdz | ia64 | 09:48 |
| mdz | T-Bone is not here | 09:48 |
| jdub | mdz: there are some items under 'irda' that really shouldn't be there | 09:48 |
| mdz | jdub: good point | 09:49 |
| mdz | in fact nothing should be under irda | 09:49 |
| thom | hp are very kindly sending me an itanium workstation, so i can test d-i | 09:49 |
| === mvo__ is back after network problems | ||
| mdz | backing up | 09:49 |
| mdz | " More robust mechanism for consistently-named network interfaces" | 09:49 |
| sabdfl | thom: ? | 09:49 |
| mdz | that would be doing ifrename right | 09:49 |
| jdub | i think NM covers that to a certain extent | 09:49 |
| mdz | oh? | 09:49 |
| jdub | yeah, it unifies a lot of that stuff | 09:50 |
| thom | (not, "they're sending me it to test d-i", but "they're sending me one; thus i can test d-i as a side effect") | 09:50 |
| mdz | " Unified DNS configuration (resolvconf or similar)" | 09:50 |
| sabdfl | thom: aha | 09:50 |
| jdub | NM may have an impact on that | 09:50 |
| mdz | sabdfl: they sent me one as well, some time ago, so no worries there | 09:50 |
| === bob2 is totally on the wrong team | ||
| thom | that should happen through NM ideally | 09:50 |
| jdub | bob2: you get free trips to sydney for fish'n'chips! | 09:51 |
| mdz | we'll need to have a networkmanager meeting later | 09:51 |
| mdz | " Visual traffic indicators on panel network icons (so you can see when NIC or modem is busy)" | 09:51 |
| mdz | NetworkManager? | 09:51 |
| thom | new glibc can notify apps of nameservice changes AIUI | 09:51 |
| jdub | yeah ;) | 09:51 |
| Keybuk | and ugh | 09:51 |
| bob2 | jdub: hah, indeed | 09:51 |
| sabdfl | i put that in | 09:51 |
| jdub | thom: and TZ! :) | 09:51 |
| thom | yeah | 09:51 |
| Keybuk | network is always busy, evil, distracting flashy icons | 09:51 |
| sabdfl | two things: first, the network stuff (wifi etc) should only be visible when it's meaningful | 09:51 |
| mdz | was that a yeah, networkmanager will do the blinkenlights? | 09:51 |
| jdub | mdz: yes | 09:52 |
| mdz | ok | 09:52 |
| sabdfl | and second, it's good to have evil, distracting, flashing icons :-)_ | 09:52 |
| mdz | not by default, please | 09:52 |
| thom | NM will do wifi strength, not sure about traffic but it probably is trivial, will look | 09:52 |
| sabdfl | but seriously, often want to know if the network is busy or not, it's a common user perceptual reinforcement | 09:52 |
| Keybuk | sabdfl: but if you have a windows machine on the network, the light won't stop flashing | 09:52 |
| jdub | sabdfl: and common irritant ;) | 09:52 |
| sivang | isn't there already an applet for showing network traffic? I use one. | 09:52 |
| Keybuk | because they don't shut up broadcasting shit | 09:52 |
| jdub | sivang: there is, but NM centralises the configuration, etc. | 09:53 |
| sabdfl | jdub: i know which side i'm going to ask us to err on :-) | 09:53 |
| mvo__ | siretart: netspeed? | 09:53 |
| === Keybuk wonders what that wailing sound is | ||
| jdub | thom: i wouldn't be surprised if some of the gnome applets are fixed up to support NM | 09:53 |
| jdub | mvo__: ew, no ;) | 09:53 |
| sabdfl | thom: can nm appear as a notifier, rather than an applet? | 09:54 |
| mdz | what about sabdfl's network-applets-only-when-meaningful? | 09:54 |
| tseng | nm is a notifier | 09:54 |
| thom | sabdfl: it is a notification applet | 09:54 |
| sabdfl | perfect | 09:54 |
| Keybuk | mdz: requires massive, total, unrelenting overhaul of gnome-panel and gnome-applets | 09:54 |
| jdub | mdz: NM does that | 09:54 |
| sabdfl | we need the same for battery | 09:54 |
| mdz | hahaha | 09:54 |
| mdz | conflicting answers | 09:54 |
| amu | should we also add support for handicapped people? i got some request for the liveCD some time ago | 09:54 |
| === sivang is stunned to see mdz laughing :) | ||
| mdz | jdub: what's the right implementation overall? | 09:54 |
| thom | mdz: NM provides an API to find out whether you're connected to the network | 09:54 |
| mdz | should the applets run always, and not display anything unless appropriate? | 09:55 |
| thom | s/the/a | 09:55 |
| tseng | amu: we're followig the outline | 09:55 |
| jdub | mdz: can't answer that sanely | 09:55 |
| mdz | jdub: how do we implement what sabdfl proposed? | 09:55 |
| jdub | mdz: but NM has nicons that appear per-network-interface | 09:55 |
| jdub | mdz: NM | 09:55 |
| Keybuk | mdz: doesn't work ... the applets hook to the panel via bonobo so if they run they display stuff ... if they don't display stuff they aren't run | 09:55 |
| mdz | jdub: battery | 09:55 |
| mdz | sound | 09:55 |
| mdz | other stuff which is not network | 09:55 |
| jdub | mdz: well, there's battfink which did that to start with | 09:55 |
| tseng | there is battfink and another notification for batter | 09:56 |
| tseng | iirc nat did one | 09:56 |
| sabdfl | Keybuk: need to be able to run them, and have them display nothing if there's nothing to tell | 09:56 |
| sabdfl | can an applet be converted to a notifier easily? | 09:56 |
| Keybuk | sabdfl: have chatted about this upstream with the gnome people | 09:56 |
| Keybuk | our general feeling is to convert the entire panel to a notification area | 09:56 |
| jdub | mdz: but in this case, using existing battstat code to run a nicon would be a quick fix | 09:56 |
| Keybuk | and make all applets nicons instead of silly bonobo controls | 09:56 |
| Keybuk | though jdub wailed a bit, iirc :p | 09:56 |
| ogra | yay | 09:56 |
| jdub | Keybuk: no | 09:57 |
| sabdfl | the battstat icon is close to perfect for us at the moment | 09:57 |
| sabdfl | except that it shows on computers without a battery :-) | 09:57 |
| sabdfl | can we move on? | 09:57 |
| jdub | Keybuk: everyone wails at the idea of replacing applets with nicons, because it's the wrong thing to do (however, it is a simple way of moving toward what we want) | 09:57 |
| jdub | yes | 09:58 |
| sabdfl | i don't want to replace ALL the applets, just network and battery in our case | 09:58 |
| jdub | (was referring to upstream discussion) | 09:58 |
| sabdfl | mdz? next? | 09:58 |
| ogra | you shouldnt make gtik a nicon ;) | 09:58 |
| === mdz snuck off to nibble on some food | ||
| sabdfl | busted | 09:59 |
| mdz | next up is ia64 | 09:59 |
| mdz | but T-Bone isn't around | 09:59 |
| === MrTom-away is now known as MrTom | ||
| mdz | he's going to run that show, right? | 09:59 |
| sabdfl | yes, we're not going to make it an internal problem | 10:00 |
| mdz | ok | 10:00 |
| mdz | TestingInfrastructure | 10:00 |
| sabdfl | beyond buildd's and no doubt some lamont-lovin# | 10:00 |
| mdz | huge framework needed here | 10:00 |
| mdz | bounty material | 10:00 |
| mdz | needs a detailed spec and some candidates | 10:00 |
| sabdfl | this one i think is worth doing internally | 10:00 |
| sivang | QA ? | 10:01 |
| sabdfl | we'll be living with it for a long time | 10:01 |
| mdz | true, lots of ongoing maintenance probably | 10:01 |
| mdz | QA indeed | 10:01 |
| sabdfl | and it is not something we can just drop out if it doesn't show up | 10:01 |
| mdz | this could keep someone busy for most of the hoary cycle | 10:01 |
| sabdfl | yes | 10:01 |
| mdz | ok | 10:01 |
| mdz | " APT package authentication (signed releases, apt 0.6)" | 10:02 |
| mdz | not a big deal if we do it early | 10:02 |
| jdub | wish we had some apt hackers on board | 10:02 |
| mdz | needs answers to a few PKI type questions | 10:02 |
| mdz | how we'll manage keys, etc. | 10:02 |
| sabdfl | mdz: fire away, oo | 10:02 |
| sabdfl | b | 10:02 |
| mdz | I think sabdfl/elmo/I had it pretty much sorted the last time we talked | 10:02 |
| mvo__ | mdz: would like to help here | 10:02 |
| mdz | I'll put apt 0.6 on the early breakagae list | 10:03 |
| mdz | and get it uploaded ASAP | 10:03 |
| === gro [~gro@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting | ||
| mdz | mvo__: we'll need auth support in synaptic | 10:03 |
| mdz | and also in aptitude | 10:03 |
| mvo__ | yes, I can do this | 10:03 |
| mdz | mvo__: aptitude as well? | 10:04 |
| mvo__ | mdz: I'll contact daniel first, but I can do a patch if needed I think | 10:04 |
| mdz | ok | 10:04 |
| mdz | Splitting/removing files from binary packages we talked about already | 10:04 |
| mdz | bzip2'ed packages | 10:04 |
| mdz | Keybuk: ? | 10:04 |
| Keybuk | already on dpkg mainline | 10:04 |
| Keybuk | binary, anyway | 10:05 |
| mdz | Keybuk: early breakage | 10:05 |
| sabdfl | is it in warty dpkg? | 10:05 |
| mdz | no | 10:05 |
| Keybuk | sabdfl: no. | 10:05 |
| sabdfl | fuck | 10:05 |
| doko | is that decided? installation slowdown? | 10:05 |
| sabdfl | doko: not for all pacakges | 10:05 |
| mdz | doko: we will have the feature | 10:05 |
| Keybuk | bzip2 packages will need to Pre-Depend: dpkg (>= 1.10.24) | 10:05 |
| mdz | that much is decided | 10:05 |
| sabdfl | just stuff like languagepacks | 10:05 |
| mdz | Keybuk: when can you upload bzip2-enabled dpkg? | 10:05 |
| jdub | or we could defer bzip packages to grumpy, but get dpkg in | 10:05 |
| Keybuk | mdz: when can I upload? | 10:06 |
| jdub | (suppose it doesn't matter, really) | 10:06 |
| mdz | Keybuk: as soon as you're done with the merge? | 10:06 |
| mdz | dpkg seems to have 2 ubuntu revisions | 10:06 |
| mdz | afaik hoary is open for uploads now | 10:06 |
| Keybuk | mdz: yeah, one of those was amd64; the other hasn't been merged upstream | 10:06 |
| jdub | oh? | 10:07 |
| === jdub tries | ||
| Keybuk | elmo: is my key in the ring again yet? :p | 10:07 |
| mdz | elmo is importing packages anyway; real uploads should not be far behind | 10:07 |
| mdz | anyway, that one is Keybuk's | 10:07 |
| mdz | " Some facility for installation of meaningful package groups? (tasks)" | 10:07 |
| mdz | Kamion suggested that we resurrect tasksel or a similar feature | 10:08 |
| mvo__ | I would like to take this | 10:08 |
| jdub | some of that will be covered by app-install | 10:08 |
| mdz | yes, I think it makes sense to integrate the two into one | 10:08 |
| Keybuk | yeah, isn't this covered by Ross' gui | 10:08 |
| sabdfl | disagree | 10:08 |
| sabdfl | the nice slick app installer would likely look something like the win-foss gui | 10:08 |
| jdub | mdz: only some of the use cases are covered by app-install, not all | 10:08 |
| daniels | 0609, good night. | 10:08 |
| sabdfl | simple, click here to get this app | 10:09 |
| Keybuk | daniels: nite, dude | 10:09 |
| mdz | daniels: night | 10:09 |
| sabdfl | tasksel is a different thing | 10:09 |
| mdz | they wouldn't be presented together | 10:09 |
| mdz | but backend-wise, there is a lot of overlap | 10:09 |
| jdub | sabdfl: app-install can also install sets of packages, such as "OpenOffice.org" -> implies a bunch of packages | 10:09 |
| Keybuk | sabdfl: is it though? are click here to get "word processor" and "development environment" actually different? | 10:09 |
| === sabdfl reconsiders | ||
| jdub | sabdfl: possibly things like "Web Development Environment" -> bunch of things | 10:10 |
| mdz | Keybuk: "development environment" has never been a useful task :-P | 10:10 |
| sabdfl | i'd like to keep that gui tool very basic and simple | 10:10 |
| jdub | it is :) | 10:10 |
| jdub | i'll send you sshots | 10:10 |
| Keybuk | oh, it should be very basic and simple | 10:10 |
| Keybuk | for complex task selection, synaptic should do that | 10:10 |
| sabdfl | sorry, aimed at "basic and simple users" and i'm not sure web development environment counts | 10:10 |
| mdz | honestly, I think that the app-installer and the security update notifier and the simple upgrader should be one app | 10:10 |
| jdub | sabdfl: "File Server" | 10:11 |
| mdz | that doesn't mean a complex ui; it could be a few separate UIs | 10:11 |
| jdub | mdz: agree | 10:11 |
| sabdfl | jdub: nfs, samba, ftp??? | 10:11 |
| thom | agree with mdz; much simpler for users | 10:11 |
| jdub | sabdfl: there are lots of simple aggregate examples like these | 10:11 |
| jdub | sabdfl: but the only cover some of the use cases | 10:11 |
| sabdfl | hmm... security update notification will put a blinkenlight in the panel | 10:12 |
| sabdfl | that's all | 10:12 |
| mdz | and when you click on it... | 10:12 |
| Keybuk | sabdfl: something needs to happen when you click it :) | 10:12 |
| mvo__ | it opens the update maanager | 10:12 |
| mvo__ | :) | 10:12 |
| sabdfl | simple app installer is like our win-foss goodie, very simple, focused on end-user apps that are high quality but not general enough to be in the desktop install | 10:12 |
| sabdfl | like dia | 10:12 |
| Keybuk | this should all be effortless and obvious | 10:12 |
| sabdfl | and sodipodi (though i think inkscape might make it for hoary) | 10:13 |
| === MrTom is now known as MrTom-away | ||
| ogra | whats wrong with inkscape ? | 10:13 |
| sabdfl | what's simple upgrader? | 10:13 |
| jdub | sabdfl: app-install does that delightfully, per spec we talked about at oxford | 10:14 |
| mdz | sabdfl: one-click system upgrade | 10:14 |
| sabdfl | shouldn't that be a simple view on synaptic? | 10:14 |
| jdub | no | 10:14 |
| mdz | maybe | 10:14 |
| sabdfl | jdub why not/ | 10:14 |
| mvo__ | sabdfl: could be, but it's desinged as a python app with synaptic as backend for now | 10:14 |
| mdz | mvo__: until synaptic is rewritten in python :-) | 10:15 |
| Keybuk | sabdfl: it effectively is as I understand it | 10:15 |
| jdub | sabdfl: because it's so much simpler | 10:15 |
| jdub | sabdfl: it runs synaptic to do the work | 10:15 |
| mvo__ | so it only lists updates and gives you "proceed" | 10:15 |
| jdub | the frontend is pygtk | 10:15 |
| sabdfl | where is this beast? | 10:15 |
| mvo__ | mdz: we'll do this later :) | 10:15 |
| azeem | why not make synaptic simpler? | 10:15 |
| jdub | sabdfl: sent by mail | 10:15 |
| sabdfl | ok | 10:15 |
| sabdfl | next | 10:15 |
| mdz | azeem: because package management is complex; synaptic offers a lot of power | 10:15 |
| mdz | we should not remove that power, but provide a simpler interface for simpler things | 10:16 |
| mdz | lm-sensors in main for hardware monitoring | 10:16 |
| mdz | -> seed change | 10:16 |
| === MrTom-away is now known as MrTom | ||
| azeem | did you look at the red-carpet stuff from the ximian usability wizards? | 10:16 |
| mdz | hmm, and also fixing up the package | 10:16 |
| azeem | might be simpler | 10:16 |
| elmo | I thought we excluded lm-sensors 'cos the packaging was crackful? | 10:16 |
| mdz | to get rid of the 2.4 modules crap | 10:16 |
| jdub | azeem: it's about as complex as synaptic | 10:16 |
| mdz | I did a bunch of that for warty already | 10:17 |
| mdz | the source is in main | 10:17 |
| mdz | er | 10:17 |
| mdz | and yet it still build-depends on kernel-source-2.4.27 | 10:17 |
| mdz | oh, wrong version | 10:18 |
| mdz | Build-Depends: bison, flex, librrd0-dev, debhelper (>= 4.1.16) | 10:18 |
| mdz | elmo: yeah, I fixed lm-sensors in ubuntu already | 10:18 |
| mdz | Binary: sensord, libsensors3, lm-sensors, libsensors-dev | 10:18 |
| mdz | so it's just a seed change | 10:18 |
| mdz | " resolvconf in main for managing resolv.conf with multiple networks" | 10:18 |
| mdz | covered under network magic | 10:18 |
| mdz | HardwareDatabase | 10:18 |
| mdz | (cue ominous music) | 10:18 |
| sabdfl | another biggie | 10:19 |
| mdz | yes | 10:19 |
| mdz | fun though | 10:19 |
| thom | cue thom running away and hiding | 10:19 |
| === Keybuk is going to drop out now ... been a 14 hour day | ||
| mdz | sabdfl: bounty or no? | 10:19 |
| sabdfl | -cheers Keybuk | 10:19 |
| mdz | Keybuk: night | 10:19 |
| sabdfl | mdz: need to figure out who will use it | 10:19 |
| sabdfl | - fabbione | 10:19 |
| seb128 | later Keybuk | 10:19 |
| sabdfl | - mjg59 | 10:19 |
| mdz | - herbert | 10:20 |
| sabdfl | - sound config | 10:20 |
| thom | it should be interesting and doable - i've had some thoughts on the matter which i need to write up | 10:20 |
| sabdfl | kernel cant really adapt itself | 10:20 |
| mdz | that stuff will be very useful for the kernel | 10:20 |
| thom | sabdfl: which modules get loaded, acpi v apm, etc | 10:20 |
| sabdfl | right | 10:20 |
| mdz | which devices are present but unrecognized by hotplug | 10:20 |
| pitti | thom: do you think hal could be extended for such things? Or do you write another db? | 10:21 |
| thom | which modules to blacklist | 10:21 |
| mdz | I think using hal would make a huge project even huger | 10:21 |
| thom | pitti: different problem space, i think | 10:21 |
| elmo | oh, you mean that kind of DB | 10:21 |
| pitti | thom: hal 0.4.0 has a lot of extensions, though | 10:21 |
| elmo | I thought you meant ZDHW | 10:21 |
| mdz | elmo: ZDHW? | 10:21 |
| thom | elmo: it'd tie into zero day hardware, i think | 10:22 |
| jdub | ZeroDayHardWarez | 10:22 |
| mdz | isn't that the same as the hardware db we're talking about? | 10:22 |
| thom | pitti: a web DB? | 10:22 |
| elmo | mdz: ZDHW is user-orientated | 10:22 |
| elmo | (well it is in MY mind ;-) | 10:22 |
| === MrTom is now known as MrTom-away | ||
| elmo | tho, there's certainly overlap | 10:22 |
| thom | can we move ZDHW/this to a different meeting? (is it a hoary goal?) | 10:22 |
| mdz | I envisioned a client app which would scan the system and ask questions, and upload the information to a central db | 10:23 |
| mdz | which would also have a web frontend | 10:23 |
| mdz | but mostly we would trawl it for information | 10:23 |
| mdz | the web frontend of that = ZDHW? | 10:23 |
| thom | mdz: i think so | 10:23 |
| sabdfl | could be linked :-) | 10:23 |
| mdz | yes, let's treat that separately | 10:23 |
| mdz | same database, different app | 10:23 |
| sabdfl | so there are several challenges | 10:23 |
| bob2 | if you're going to ask people to send in info, the db results need to be open | 10:24 |
| sabdfl | (a) the design of the database (yay!) | 10:24 |
| mdz | I think the collection app is the first step | 10:24 |
| pitti | thom: ok, I think I misunderstood the purpose | 10:24 |
| sabdfl | (b) the app that collects the data | 10:24 |
| sabdfl | (c) figuring out what the data means | 10:24 |
| sabdfl | (d) integrating it with the scripts that autoconf the setup | 10:24 |
| sabdfl | like x, sound, network, etc | 10:24 |
| sabdfl | that's a lot of work | 10:25 |
| thom | yes. | 10:25 |
| mdz | yes, but we can do it in stages | 10:25 |
| mdz | first the db + app | 10:25 |
| sivang | wow, and auto bug reproduction system.... | 10:26 |
| sivang | and=an | 10:26 |
| ogra | reproduction ? | 10:26 |
| sivang | according to what sabdfl just outline, so it sound like. | 10:26 |
| mdz | I think he means the possibility of finding people with similar hardware to try to reporduce bugs | 10:26 |
| mdz | which I think is a good application of the system | 10:26 |
| mdz | the user could volunteer their contact info so that we could ask them for help in testing | 10:27 |
| sabdfl | that's an interesting idea | 10:27 |
| ogra | souds good | 10:27 |
| thom | eww, that means storing contact info | 10:27 |
| sabdfl | make it a two-way flow | 10:27 |
| thom | RUN AWAY | 10:27 |
| mdz | thom: link to Person :-) | 10:27 |
| bob2 | hahaha | 10:27 |
| jdub | hardware matchmaker! | 10:27 |
| sivang | each interested party would list his details on the bugdb, and when the need arise we politely ask him to test | 10:27 |
| sabdfl | thom, have you SEEN the database of DOOM recently? | 10:27 |
| mdz | jdub: your systems are compatible! | 10:27 |
| jdub | "i love matrox too! see you on friday!" | 10:27 |
| mdz | this stuff would be very interesting to summarize, too | 10:28 |
| sabdfl | "nice cpu's wanna ....'? | 10:28 |
| sivang | hahah | 10:28 |
| thom | sabdfl: no. but i do need to ask, have you looked into UK regs for personal data storage? | 10:28 |
| jdub | a/s/mhz?!?!?!! | 10:28 |
| mdz | hah | 10:28 |
| sabdfl | thom: hmmm... no | 10:28 |
| thom | (the legal stuff, i mean) | 10:28 |
| thom | you absolutely utterly need to | 10:28 |
| sabdfl | ok | 10:28 |
| sabdfl | not sure if we are technically in that part of the uk | 10:29 |
| mdz | we're going to store that stuff anyway, so that's not a problem specific to the hardware db | 10:29 |
| === jdub attempts to upload to hoary... | ||
| sabdfl | jdub: x.org? | 10:29 |
| jdub | pre-emptive strike! | 10:29 |
| sabdfl | ok, moving on... | 10:29 |
| mdz | so thom, you're going to take on the hardware db? | 10:30 |
| mdz | with support from the rest of us, of course | 10:30 |
| sabdfl | no, let's have a separate meeting for that | 10:30 |
| mdz | ok | 10:30 |
| thom | mdz: can we have a sep meeting? | 10:30 |
| mdz | done | 10:30 |
| thom | *phew* | 10:30 |
| mdz | moving on | 10:30 |
| mdz | Derivative Distributions | 10:30 |
| mdz | what can we do in the hoary timeframe? | 10:30 |
| sabdfl | should have a lot of plumbing in place for christmas | 10:31 |
| sabdfl | at least for more adventurous / skillful candidates | 10:31 |
| mdz | this isn't specifically ubuntu stuff | 10:31 |
| mdz | unless you want to do the branding crack | 10:31 |
| sabdfl | -yes, exctly | 10:31 |
| mdz | it shouldn't require changes to the distribution itself | 10:31 |
| mdz | yes to branding crack? or yes to not specifically ubuntu? | 10:31 |
| sabdfl | yes to brandability of derivatives | 10:32 |
| sabdfl | which touches hoary | 10:32 |
| mdz | eek | 10:32 |
| mdz | touches? molests | 10:32 |
| sabdfl | easy tiger | 10:32 |
| sabdfl | we only deal in mature packages | 10:32 |
| mdz | consenting? | 10:32 |
| sabdfl | able, certainly | 10:32 |
| mdz | ok, that needs a metting and a spec I think | 10:32 |
| === MrTom-away is now known as MrTom | ||
| sabdfl | yes | 10:33 |
| mdz | meeting, even | 10:33 |
| thom | sabdfl: http://www.informationcommissioner.gov.uk/ for DPA stuff | 10:33 |
| azeem | compenentized linux made branding possible some time ago, and people seemed to like it | 10:33 |
| jdub | i'm thinking of making ubuntu-artwork divert a bunch of other art-related branding things | 10:33 |
| jdub | so you can just replace u-a for all of that | 10:33 |
| mdz | " Enforce main/universe separation on buildds (LaMontJones?)" | 10:33 |
| mdz | lamont: all you | 10:33 |
| doko | he's still away | 10:34 |
| mdz | ok | 10:34 |
| mdz | that's the end of the list! | 10:34 |
| jdub | yayayay | 10:34 |
| sabdfl | well done | 10:34 |
| mdz | thanks for hanging in there | 10:34 |
| === jdub dances around like kermit | ||
| mdz | especially those of little sleep | 10:34 |
| jdub | 26hrs! | 10:34 |
| doko | left out the launchpad integration | 10:35 |
| mdz | mako: can we get a transcription and summary? | 10:35 |
| bob2 | jdub: V. | 10:35 |
| sivang | 26hrs in a row? | 10:35 |
| mdz | doko: that's another meeting | 10:35 |
| sivang | ?? | 10:35 |
| jdub | bob2: sprite recharge ;) | 10:35 |
| bob2 | jdub: hah | 10:35 |
| seb128 | 'night jdub :) | 10:35 |
| mdz | meeting adjourned, thanks everyone | 10:35 |
| === mdz ices his wrists | ||
| sivang | thank you | 10:36 |
| bob2 | 4:35, hard core | 10:36 |
| mvo__ | thanks mdz | 10:36 |
| === jdub goes to pay attention to pipka | ||
| thom | g'night | 10:36 |
| seb128 | 'night thom | 10:36 |
| sabdfl | cheers all, thanks mdz | 10:36 |
| pitti | night | 10:36 |
| doko | thanks for the moderation | 10:36 |
| seb128 | 'night everybody | 10:36 |
| mdz | I'll write up my notes for the wiki | 10:36 |
| jdub | thanks mdz | 10:36 |
| sivang | night thom | 10:37 |
| ogra | thanks for enabling us to participate :) | 10:37 |
| sivang | mdz : you're gonna do this on the new wiki? | 10:37 |
| mdz | sivang: yes | 10:37 |
| mdz | a bit later, need a break | 10:37 |
| sivang | ah ofcourse | 10:37 |
| sivang | :) | 10:37 |
| jdub | new wiki hurts my brain :| | 10:38 |
| sabdfl | jdub: i'm thinking we should keep moin format as recommended default | 10:38 |
| jdub | sabdfl: what about the tables? | 10:38 |
| jdub | inline html, or...? | 10:39 |
| sabdfl | jdub: we got tables in | 10:39 |
| sabdfl | i don't like the moin format but we can handle it now | 10:39 |
| sabdfl | (moing table format) | 10:39 |
| jdub | oh! | 10:39 |
| jdub | cool | 10:39 |
| sivang | sabdfl : would it be ok of you to discuss things like wiki integration and other doc related stuff on CC meeting? or do you prefer it to be a seperate one? | 10:39 |
| sabdfl | sivang yes please put it in the agenda | 10:40 |
| doko | mdz: please put my name to the TestingInfrastructure thing, at least as a co-worker | 10:40 |
| sivang | sabdfl : ok np. I've already added to it | 10:40 |
| mako | mdz: yes | 10:43 |
| === maskie [~maskie@196-30-111-250.uudial.uunet.co.za] has left #ubuntu-meeting ["Leaving"] | ||
| sivang | night all | 10:55 |
| Kamion | mdz: restricted/installer is trivial, it's a "file a bug and wait for Kamion to have a spare hour" routine | 11:00 |
| Kamion | mdz: TestingInfrastructure> have I already massively pimped joeyh's d-i autoinstall framework at you? it's awesome | 11:01 |
| Kamion | mdz: he's been doing full CD tests out of cron lately | 11:02 |
| Kamion | works with iLO, which IIRC we have on some of our boxes | 11:02 |
| === MrTom [~thomas@84.97.17.128] has left #ubuntu-meeting ["Leaving"] | ||
| mdz | doko: ok | 11:13 |
| mdz | mako: thanks | 11:13 |
| mdz | Kamion: sounds very interesting, where can we get more info/ | 11:13 |
| Kamion | mdz: svn://svn.debian.org/d-i/people/joeyh/autoinstall/ is probably the best place for now | 11:14 |
| === Sensebend [~steve@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-meeting | ||
| === hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has left #ubuntu-meeting ["Leaving"] | ||
| sabdfl | Kamion: we have iLO on the new itaniums, and please go ahead on the restricted-free option | 11:45 |
| elmo | nah, we don't, iLO is an x86 server only option | 11:47 |
| elmo | the Itaniums have something much less fun, called "MP" | 11:47 |
| Kamion | however joeyh also does have something going on ia64, may not be with iLO | 11:48 |
| Kamion | I think it's just netboot over serial console | 11:48 |
| === tseng [~tseng@thegrebs.com] has left #ubuntu-meeting [] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!