=== 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 [03:07] Morning === 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 [04:19] can someone put the agenda link on the channel's topic? === ..[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 [05:09] I put already a link about my opinion [05:09] http://ploum.frimouvy.org/?2004/10/25/6-i-dont-want-people-to-use-gnome-applications-anymore === doko [doko@dsl-084-057-024-165.arcor-ip.net] has joined #ubuntu-meeting === Keybuk [scott@descent.netsplit.com] has joined #ubuntu-meeting [05:29] I know I am late ... are people already busy working? so quiet ... [05:29] half an hour early [05:30] ahh still summertime in the UK? [05:31] meeting time is UTC, not BST/GMT [05:31] we're UTC+0100 at the moment === Mitario [~michiel@sikkes.xs4all.nl] has joined #ubuntu-meeting [05:38] doko: so you're early. :-) [05:38] lamont: at least that can't be wrong ;) [05:39] yeah === 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 [05:55] doko : early enough :) [05:55] jdub: are you here for the duration? thanks for staying up [05:56] probably [05:56] i'm hammered [05:56] got up at 4am [05:56] ouch [05:56] you're turning into fabio :\ [05:56] tsk :P [05:56] hey lamont [05:56] he should be honoured of that ;) [05:57] fabboine : still insomnic ? [05:57] fabbione: the word in english is "suicidal" ;-) [05:57] or terrified, either way [05:57] jdub: had a nap along the way, I hope [05:57] daniels: think how much fun you'll have over there! [05:58] mdz: no [05:58] "little daniel, it's 4am, let's hack x.org!" === tioui [~arthur@AReims-151-2-2-234.w83-192.abo.wanadoo.fr] has joined #ubuntu-meeting === jdub goes to have a sprite recharge [05:58] ...daniels awakes as a bucket of ice water is emptied over his head [05:59] right, better get tea === daniels calls ahead to the hotel and sends instructions that no visitors will be allowed. [05:59] mdz: 4am is generally when I go to sleep these days [06:00] ok [06:00] called to order, etc. [06:00] is everyone here who ought to be? [06:00] morning sivang [06:01] lamont : good evening, it's 18:00pm here ;-) === Kamion waves === enrico says hi [06:01] me waits a moment for stragglers to arrive === sivang sticks his head up === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [06:01] hi all [06:01] Hi fearless sabdfl! [06:02] Hi fearless leader! :) [06:02] hey all, mdz will be chairing this one [06:02] evening sabdfl [06:02] ok, we have a ton of ground to cover, so let's get started [06:02] evening all [06:02] 'lo [06:02] hi [06:02] fisrt agenda item is to review the release schedule, and probably make some adjustments. jdub, are you back with Sprite? [06:03] I believe the schedule requires updating to reflect changes to the GNOME 2.10 schedule [06:04] ok, let's skip ahead to the merge process for now [06:04] and we need to fiddle the CD milestone dates [06:04] it does [06:04] ok, let's not :-) === LeeColleton [~lc@dsl231-061-247.sea1.dsl.speakeasy.net] has joined #ubuntu-meeting [06:04] who wants some cute stats about warty? [06:04] jdub: any changes which we should talk about here? [06:04] http://www.gnome.org/start/2.9/ [06:04] mdz: not significant enough, no [06:04] ^ that's the gnome schedule, for the record [06:04] ours just needs tweaking [06:05] fwiw, the proposed gnome schedule: http://www.gnome.org/start/2.9/ [06:05] jdub: by how much? [06:05] days [06:05] 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] mdz: not in a hurry, just flaggint it [06:05] flagging [06:05] ok, nothing major in that department, then; we can move on [06:05] to THE MERGE === rburton [~ross@84.12.22.159] has joined #ubuntu-meeting === fabbione runs away screaming [06:05] elmo: what's the status of the sync infrastructure? === Gmail [~Google@gnu-debian.user] has joined #ubuntu-meeting [06:06] ...creepy organ music plays... [06:06] mdz: mostly ready - I need two things before I can go: [06:06] a) proper seed lists for hoary [06:06] b) a decision on what, if anything, we're doing about indices files for hoary? [06:06] am i allowed to say a few comments? [06:07] Gmail: we are talking about the huge merge with sid. if it is appropriate and on-topic, yes. [06:07] March 9th: 2.10.0 release! (wow, my birthday :-) ) [06:07] Gmail: yes, this is a public meeting, but please try to stay on topic, we have a great deal to discuss [06:07] Gmail: we're on an agenda here, let's stick to it and have any other business at the end. [06:07] elmo: what sort of indices? [06:07] mdz: Packages/Sources, etc. there was talk of pw-protecting and/or hiding them at one stage [06:07] elmo: until we have the initial merge sorted out? [06:08] elmo: that was about crack-o-the-day, not hoary [06:08] there may be something to be said for that [06:08] jdub: no, it really was hoary at one stage. [06:08] elmo: I thought that applied more to grumpy start (at hoary freeze...) [06:08] we really don't know how bad the breakage will be, though === hornbeck [~hornbeck@adsl-69-153-250-222.dsl.okcyok.swbell.net] has joined #ubuntu-meeting [06:08] elmo: it was about hoary while warty was still in devel [06:09] the only compelling justification is so that people don't dive into it when it's known to be severely broken [06:09] basic question, do we think people will expect hoary to be sane-if-there? [06:09] which I think it very well could be at the very beginning [06:09] sabdfl: we've been telling people not to, but I'm sure they will [06:09] sabdfl: perhaps not sane, but installable and not breaking their desktop [06:09] sabdfl: mostlikely [06:09] sabdfl: you can s/warty/hoary/ now, and apt-get update won't error our [06:09] those who have been warned deserve what they get, but there will be others who have not been warned [06:09] daniels: eh, you'll screw your system [06:09] but there's nothing in their system telling them to s/warty/hoary/ === ogra [~ogra@p508EA4D2.dip.t-dialin.net] has joined #ubuntu-meeting [06:10] it will take longer to get through the pain of merging if we try to keep hoary sane at all times [06:10] elmo: regarding the seed lists, let's use the Warty seed lists; we can update them later [06:10] 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] mdz: ok [06:10] mdz: are we going to duplicate them in the wiki, or do I not need to change Germinate yet? [06:10] 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] elmo, mdz: please kill anything X related in the seeds, we don't want to merge xfree86 from sid [06:11] fabbione: we won't merge it - it's ubuntu modified [06:11] gmail: msg me oob and i'll raise them at the end [06:11] Kamion, elmo: let's continue to use germinate pointing to the Warty seeds === inklingx [~inklingx@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting [06:11] elmo: perfect === stvn [~steven@82.197.192.33] has joined #ubuntu-meeting [06:11] so what elmo and I discussed was that his tool would automatically import unmodified packages [06:12] and for modified packages (those with an ubuntu version number), send out a notification [06:12] probably a simple email to start [06:12] notification to whom? [06:12] a mailing list seems appropriate === Treenaks [martijn@facecrime.net] has joined #ubuntu-meeting [06:12] notification of what? resync, or keep it? [06:12] doko: a notification of the fact that it needs review [06:12] and then we either merge, or sync new-debian [06:12] http://people.ubuntu.com/~scott/patches/warty/ [06:12] mdz and I discussed including the changelog from the debian version, to aid in prioritzation [06:13] 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] wouldn't be better to track it in bugzilla? [06:13] ^ that's the set of patches made to warty since Debian-freeze [06:13] http://people.ubuntu.com/~scott/patches/debian/ [06:13] elmo: yes, that would be great [06:13] so we are sure of what is done or not? [06:13] ^ that's the changes to those packages in Debian since the freeze [06:13] elmo: sweet [06:13] fabbione: we discussed it briefly, it is a possibility [06:13] http://people.ubuntu.com/~scott/output/ [06:13] I am concerned about generating a huge number of bugs that way [06:13] ^ result of merging the two together, with a bunch of rejects to review [06:13] fabbione: bugzilla feels extraordinarily heavyweight for this, to me [06:13] but we have the tools to do it [06:14] Kamion: i think it's easier since you go, pickup, kill and so on... [06:14] bugzilla does have the advantage of making it easy to track assignments, so we know if something is being done or not [06:14] Kamion: otherwise we might lose track of the list [06:14] we're talking about 248 bugs [06:14] just for main [06:14] mdz: and we could also sort out the "who does what" easily in bz [06:14] elmo: let's create bugs automatically for the initial batch at least [06:15] *shrug* k [06:15] we'll need to figure out what to do for the ongoing merges, based on that experience [06:15] could equally well be a single wiki page [06:15] sabdfl: where everybody marks the packages he will merge? [06:15] would work, too; maybe easier than bz [06:15] what do we want to do about universe? the majority of those changes were "make it build" fixes that should be irrelevant - I'm semi-tempted to overwrite, but that may just be me [06:16] 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] let's start with bugzilla, and if it becomes cumbersome, we can switch to something else [06:16] elmo: let's ignore universe for now === amu [~amu@195.71.9.198] has joined #ubuntu-meeting [06:16] mdz: err.. mmk [06:16] not even sync the unmodified stuff? [06:16] hmm [06:16] sure, why not [06:16] daniels: no need to. we will use chroots for that [06:16] daniels: let's discuss it tomorrow [06:16] but we don't want bugs or notifications about the rest of it until we've finished with the initial work for main === manuel_ [~manuel@deri-wg1.nuigalway.ie] has joined #ubuntu-meeting === darkersatanic [~hugo@mina.ecs.soton.ac.uk] has joined #ubuntu-meeting [06:17] ok [06:17] elmo: what about accessing the morgue? === 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 [06:17] mdz: what do you think Scott's been doing? [06:17] re universe, are there any changes other than "make it build" changes? === manuel_ [~manuel@deri-wg1.nuigalway.ie] has left #ubuntu-meeting ["Verlassend"] [06:17] if not, let's just throw open the doors [06:17] elmo: no idea [06:17] elmo: I'm convinced he has me on ignore these days [06:17] sabdfl: some resyncs [06:17] elmo: can you publish a list of changed packages in universe? [06:17] sabdfl: yes, we've done things like the libtiff transition [06:17] mdz: anyway, it's on rookery, I can make it via http, if you want [06:17] sabdfl: libtiff-- yeah [06:18] sabdfl: I added some RC bug fixes regarding file conflicts [06:18] elmo: what I expect we want for the merge tool is a Sources.gz [06:18] did the libtiff stuff not get take upstream? [06:18] elmo: or a bunch of them [06:18] sabdfl: not all of them are already fixed in sid [06:18] ok [06:18] mdz: what would this merge tool do? [06:18] Keybuk: :-) [06:18] Keybuk: a lower form of magic [06:18] mdz: sure, can create a sources.gz [06:18] just a simple 3-way merge from 1.0-1, 1.0-1ubuntu3 and 1.0-2 [06:18] pitti: I thought almost everything did, it was blocking britney for ages and isn't any more [06:18] might take a day or two, but ;P [06:18] if libtiff was a lamont-automated-patch then we can recreate it quickly enough [06:18] mdz: ah, yes. you get http://people.ubuntu.com/~scott/output/ when you do that [06:19] libtiff was [06:19] did that over the weekend because I was bored [06:19] sabdfl: (yeah) [06:19] Keybuk: is that from hct? [06:19] mdz: no, just low-level magic [06:19] i think sync-and-overwrite in universe is fairly sane [06:19] keybuk: hmm, that output is useful for new upstream versions as well? [06:19] tla was taking too long [06:19] Keybuk: it has lots of lovely rejects === wulfy [~lorentz@2.wsvw1.xdsl.nauticom.net] has joined #ubuntu-meeting [06:19] Keybuk: what are the numbers like? [06:20] mdz: 10,704 "rejects" [06:20] around 7,000 of those with same changes on each side [06:20] 3,596 left as different changes to both sides [06:20] Keybuk: that's number-of-hunks or number-of-files? [06:20] some 2,500 of those in .po files and debian/changelog or debian/control [06:20] mdz: number-of-files [06:20] Keybuk: sounds like you need to autodetect same-changes case, eh? [06:21] Keybuk: any magic you can bring to the next two weeks will make you friends for life :-) [06:21] warty has some 295,004 hunks [06:21] we can drop po === vrln [~vrln@195.10.181.201] has joined #ubuntu-meeting [06:21] sabdfl: uh, I think that's a really bad idea for d-i [06:21] Kamion: true [06:21] 42,680 patched files ... 1,320 patches in 387 packages [06:21] Keybuk: (you can safely exclude xfree86 from that list of number of hunks) [06:21] sabdfl: we put enormous amounts of effort into the .po branding [06:22] right [06:22] sabdfl: but not for all of the installer packages (s/Debian/Ubuntu). === Peltoilves [~peltis@tolu.edu.hel.fi] has joined #ubuntu-meeting [06:22] right again [06:22] yes, I'd like daf to teach us how we merge changes between .po files [06:22] because whoeever designed that file format is getting a beating if I ever meet them [06:22] use Rosetta? [06:22] rosetta gets you faster community translations [06:23] but wn't help maintain an effective long-lived branch === helix [~helix@helix.user] has joined #ubuntu-meeting [06:23] 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] real solution is to parameterise the branding === Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has left #ubuntu-meeting ["Leaving"] [06:23] hmm, I didn't send kamion the script I used for merging the translations ... [06:23] sabdfl: I spent quite a lot of thought on it and TBH I'm not very convinced that it's possible [06:23] parameterisation? [06:24] at least, not without FAR greater gettext-fu than I possess or have so far seen [06:24] right [06:24] i'll knock on daf's door [06:24] 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] better than def's door [06:24] daf: three-way merge. you have original .po and two sets of patches to it [06:24] daf: in this case it's a 3-way merge with both message ID and translations changed :-) [06:25] Kamion: I actually don't see any po/ failures in debian-installer [06:25] there will be a number of cases where we just have to re-brand, there's no choice [06:25] I think it was happy with most of them :o) [06:25] Keybuk: debian-installer is just the build system. [06:25] oh :'( [06:25] Keybuk: it doesn't HAVE any .po files :-) [06:25] bah [06:25] lol [06:25] I broke apart all the patches as well [06:25] Keybuk: so how much of this can we realistically automate? [06:25] http://people.ubuntu.com/~scott/patches/warty/ === darkersatanic [~hugo@mina.ecs.soton.ac.uk] has left #ubuntu-meeting ["Client] [06:26] that's each "change" to warty [06:26] 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] 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] that'd be ideal [06:26] Keybuk: the list isn't complete, is it? [06:26] fabbione: packages for which there is both a debian and ubuntu verison in the morgue and debian < ubuntu [06:26] (ie stuff we've changed) [06:26] though the gnome stuff we can probably ignore, because we *really* changed that [06:26] http://people.ubuntu.com/~scott/patches/debian/ [06:26] Keybuk: what are the two sets of patches? [06:26] that's the debian side of it [06:26] Keybuk: ok [06:27] daf: "ubuntu changes" and "debian changes" [06:27] Keybuk: output/ is the result of applying debian/ to warty-current? === nreid [~nreid@host81-139-0-78.in-addr.btopenworld.com] has joined #ubuntu-meeting [06:27] yes, gnome, x, we figure we take the lead [06:27] mdz: yup [06:27] daf: Ubuntu changes generally fall into two groups: branding, and minor translation updates from overenthusiastic people who thought we had a good process for translation updates in warty :-) [06:28] Keybuk: 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] Keybuk: doable? [06:28] if you simply have a patch that adds/changes translations, you simply apply the patch, regenerate the .pot file and use msgmerge [06:28] daf: Debian changes you know [06:28] s/read/ready/ [06:28] 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] daf: the patch typically doesn't apply [06:28] mdz: well, you still need a human to resolve the case where debian and ubuntu have gone in different directions [06:28] Keybuk: yes, but we have a lot of stuff which should be non-overlapping [06:29] 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] arg [06:29] s/Keybuk/Kamion/ [06:29] 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] mdz: yeah, need to figure out a trick for that one :) === MrTom [~thomas@84.97.17.128] has joined #ubuntu-meeting [06:30] daf: ah, so we unpack the branchpoint package for that [06:30] mdz: you could reasonably trivially write a changelog merge tool tho [06:30] mdz: the only problem is that patch doesn't understand changelog format [06:30] hm... changelog.ubuntu, which points into changelog.debian would be easier [06:30] separate ubuntu changelog would be really useful [06:30] sabdfl: urk, debian/changelog is something understood by all sorts of tools [06:31] i'm not sure what the tools would do with that [06:31] hoary's been seeded with woody, and sync's running for non-modified stuff now [06:31] 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] can we please resolve these technical details later and go on with the agenda? [06:31] elmo: did you really mean "woody"? :p [06:31] elmo: woody? [06:31] it's more useful to users not to have a separate Ubuntu changelog, I feel [06:31] pitti: the technical detail of the merge is significant because it will determine how the work progresses [06:31] the changelog problem is one of a general class of problems we'll have to solve for derivatives [06:31] yeah, I thought it'd give us a special old skool flavour === sivang agrees with pitti [06:31] Kamion: think about the general problem, debian->ubuntu->kubuntu [06:31] if we're going to fix up all of the conflicts by hand, we also need to do it consistently [06:31] and i don't think a single file can convey it [06:31] daf: you need to recode file if the encoding changed [06:32] 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] certainly not one in the current format [06:32] sabdfl: I know, but I still think it's actively more useful to users to have a single changelog [06:32] Keybuk: yeah, you'll need to do that anyway [06:32] doko: urgh, good point [06:32] sabdfl: I've considered this fairly carefully ... [06:32] Kamion: or a tool which presents it that way [06:32] Kamion: we'd need a changelog format which could represent branches meaningfully [06:32] i find it a pain to maintain ubuntu+debian packages [06:32] which would probably require version numbers which can represent branches meaningfully [06:32] there are disadvantages to using msgcat, though [06:32] which is a ways off :-) [06:32] mdz: nah, I have a suggestion I'll feed you offline === enrico agrees with sivang and pitti [06:33] sabdfl: changelog is used also to build the package itself. it's not a good idea to fiddle with it too much [06:33] 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] 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] Keybuk: apart from being out of order [06:33] Keybuk: better to merge changelogs in version order if possible ... [06:33] 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] This was quite a bunch of work, but it is very clean [06:33] 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] mdz, Kamion: I've applied debian to warty, not the other way around [06:33] pitti: yes, that works when the package is already using dpatch === jono [~jono@82-37-194-90.cable.ubr05.wolv.blueyonder.co.uk] has joined #ubuntu-meeting [06:33] it's the debian changelog entries conflicting [06:34] so putting those at the top *does* put them in order [06:34] [06:34] hi all [06:34] Keybuk: no, it doesn't [06:34] mdz: for dpatch/cdbs packages this is actually very nice [06:34] mdz: so we could do it for packages supporting it [06:34] moving warty to the top actually takes the changelog out of version order [06:34] Keybuk: the correct order could be something like [06:34] 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] mdz: that's the order we're going to get [06:35] Keybuk: ah, if you do the merges in version number order, yes [06:35] wait, no [06:35] mdz: *nods* :) [06:35] you'd need to do them in date order [06:35] Kamion: ok, sounds good [06:35] mdz: surely version order is more meaningful? [06:35] sabdfl: (this would also have benefits for things like BTS version tracking) [06:35] daniels: it gets weird [06:36] mdz: it more accurately represents the branches, though [06:36] daniels: but you cannot really sort 2.0-0ubuntu1 and 2.0-1 [06:36] version order leaves us with something that makes more sense in and of itself :-) [06:36] daniels: either one may happened sooner or later [06:36] 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] 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] each one will be accompanied by a "this fell out" patch which will need manual review === neuro|laptop [~neuro@neuro.me.uk] has joined #ubuntu-meeting [06:36] Keybuk: great [06:36] 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] ok, i think we can take this discussion out of band [06:37] ok [06:37] the total lines of "this fell out" are pretty tiny, around 3,000 in total [06:37] initial merge strategy is to let Keybuk lock himself in a room for a day [06:37] and then create bugs on the remainder [06:37] which given nearly a million lines of changes is pretty good [06:37] (ignoring .po files, which are evil, evil, evil) [06:37] if the remainder is small enough, we'll just do it by hand [06:37] great [06:37] eek, we do need to resolve that .po issue [06:37] this whole problems smells like an application for that conary package thingy, which reportedly handles branches, patches and merges pretty well [06:38] daf: not putting a changing line number right before the bit that changes would be swell [06:38] azeem: ssshhh, be wery, wery quiet. [06:38] ok, onward to feature goals [06:39] let's take it from top to bottom [06:39] and for each item, determine whether it makes most sense for one of us to do it, or see if someone else listening would like to volunteer [06:40] first item is UTF-8, which is a bit of amorphous [06:40] we'll set UTF-8 by default early in the release cycle, and just fix whatever breakage comes up [06:40] it's really a bunch of unclassified bugs at this point, rather than a feature [06:40] yeah, I've been running utf-8 for a couple of years now; zsh is about the only breakage I notice [06:40] I have UTF-8 running for very long now, works nice for most parts [06:40] what will we do about existing Ubuntu installations? [06:41] leave them at non-UTF8, send out an announcement asking them to change? [06:41] mdz: wiki -> utf8 howto ? [06:41] would make most sense [06:41] changing the default from ISO to UTF8 on upgrade? [06:41] Kamion: what does debconf do in this situation? [06:41] fabbione: we should supply a script I think [06:41] add something to ubuntu-desktop to do that? :) [06:41] changing ~/.profile files on upgrading would be hell [06:41] first install the question was too low a priority to get asked [06:41] which handles generating locales and setting the default [06:41] what happens if the value is different on the update [06:41] Keybuk: which? [06:41] does it keep the old or go with the new? [06:41] mdz: shouldn't we switch as part of the upgrade, so systems are consistent by default? [06:41] make an application to handle post-upgrade configuration issues? [06:41] jdub: changing the locale on the user sounds fairly evil [06:42] enrico: something more like that, yes [06:42] i wouldn't go for automatic changes of that level [06:42] mdz: we don't change the locale, but the encoding [06:42] Like one runs that and gets a TODO-list of things to check [06:42] Keybuk: it's got a value already, it keeps it unless told otherwise [06:42] doko: that is a locale setting [06:42] yeah, that's like spitting on the golden rule thing [06:42] Kamion: and a dpkg-reconfigure locales would change to the new value? [06:42] mdz: we can't change the encoding automatically; this would break _every_ text file the user created [06:42] jdub: golden rule [06:42] Keybuk: no [06:42] pitti: we are in agreement [06:42] or do you have to nuke out config.dat ? [06:42] Keybuk: EVIL EVIL EVIL [06:42] if we change the system locale, what will happen with filename ? [06:43] we will provide a tool which the user can run which will DTRT [06:43] pitti is right. why wasn't it set at UTF8 from first place? [06:43] who will write it? [06:43] sabdfl: not a user chosen setting :) [06:43] we need to convert the filesystem ? [06:43] sivang: because there are still some bugs [06:43] sivang: bugs [06:43] filenames even [06:43] oh === enrico was thinking filesystem charset, too [06:43] 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] i think this falls into the category of things that new installations get by default, upgrades get if they themselves do it [06:43] Kamion: agreed [06:43] yeah [06:43] sabdfl: agreed [06:43] enrico: GNOME does UTF-8 filenames whatever charset you're in, I think [06:43] Kamion: will you write the utf8-enabler tool? [06:44] Autodetecting the existing encoding of an ASCII file is practically impossible [06:44] we will have a good "release notes" and "upgrade notes" which can document this [06:44] mdz: can do, yeah [06:44] Keybuk: even on things like BIG5 VFATs? (it would create illegal names) [06:44] ok, great [06:44] and the bugs we'll fix as they come [06:44] next is a big one [06:44] pitti: autodetecting the existing encoding of an *ASCII* file is trivial ... :-) [06:44] unified hardware detection [06:44] will there be any iso support in the apps left ? [06:44] Keybuk: nautilus does, but a lot of files are created out of nautilus ... [06:44] Kamion: okay, but you don't need to change them anyway [06:44] mdz: i would kill to move off discover1 [06:44] ogra: yes, aiui [06:45] ogra: yes, we won't try to remove support for non-utf8 encodings [06:45] 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] by unified we mean: [06:45] - installer [06:45] - installed system [06:45] - live cd [06:45] right [06:45] pitti: (you said ASCII, not text) [06:45] sorry, my bad. [06:45] currently those use: discover1, hotplug and knoppix, respectively [06:45] Kamion: whoops [06:45] my position is that hotplug is the way forward for all three [06:46] yes [06:46] I guess hotplug is the target for unification [06:46] in addition there's the layer of intelligence above the detection tools [06:46] however, currently discover1-data has by far the most accurate hardware list, afaik [06:46] for example, x resolution and refresh [06:46] we might still need discover for X [06:46] ok, hotplug is one of the post-sarge goals for d-i [06:46] we can move forward on that ourselves, given udev-udeb and hotplug-udeb packages [06:46] fabbione: yes, I consider X a separate issue [06:46] mdz: ok [06:46] this one is purely kernel stuff [06:46] doesn't discover load a few drivers which hotplug doesn't? [06:46] hotplug doesn't do X stuff, so discover is still needed for that, but that's OK [06:47] mdz: but we'll still need to unify the live cd x detection with the installer [06:47] rburton: installed Ubuntu has been using hotplug exclusively for some time now [06:47] rburton : this is what I was once told by joeyh [06:47] sabdfl: yes, I think we should consider that separately as well [06:47] daniels: does hotplug have hw lists at all? I thought it just uses the modules file from the kernel [06:47] pitti: purely from the kernel [06:47] mdz, ah ok [06:47] pitti: yes, modules.pcimap [06:47] it's fundamental to the feature goal [06:47] rburton : experimenting with that backed up his statement. [06:47] isn't that generated from the kernel? [06:47] (on sid) [06:48] Keybuk: yeah, that would help [06:48] 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] and then for grumpy eliminate the "separate but equal" (X vs kernel)? [06:48] sound, video, webcam, modem, network [06:48] I'm happy to do the hotplug d-i integration, but does anyone know udev and hotplug well enough to produce udebs? [06:48] 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] i'd like to be using the same codepaths for all of them [06:48] Kamion: should be easy [06:48] (I don't; I looked briefly before warty released, and got lost) [06:48] hotplug is just a bunch of scripts [06:48] Kamion: I expect creating udeb's wouldn't be _that_ difficult, no? [06:48] Keybuk: right; at the time I typed this question I still thought we want to use it for X :-/ [06:48] udev isn't much more [06:48] Kamion: I'll lend a hand with that [06:48] lamont: it's not hard, just a question of knowing the package really [06:49] mdz: thanks [06:49] ah, ok [06:49] fabbione: I know you have some ideas about the way forward for X autodetection [06:49] Keybuk: that's not always true [06:49] fabbione: what is the right way to unify it between the live CD and the installed system? [06:49] mdz: yes [06:49] can I just flag up buses that aren't hotplug-enabled, too [06:49] the mac-io bus on powermacs is the big one [06:49] Kamion: I have a patch for that [06:49] isn't that enabled yet? [06:49] mdz: what, to the kernel? [06:49] I thought that was floating [06:49] Kamion: yes [06:49] mdz: cool [06:50] very [06:50] 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] we can stage it for upstream [06:50] we'll still have the installer's register-module facility available for corner cases [06:50] fabbione: so we would change morphix to invoke something which would trigger the debconf magic, rather than using the knoppix stuff [06:50] mdz: correct [06:50] fabbione: can we shift the x scripts to python please? [06:51] i think rewriting live-hwdesting using discover/hotplug is not such diffifult, timeuseage is very high [06:51] sabdfl: no [06:51] fabbione: why not? [06:51] amu: it should just be a matter of calling /etc/init.d/hotplug start, if we do our work correctly [06:51] mdz: plus the config layer [06:51] sabdfl: .config scripts can only use Essential: yes packages safely [06:51] sabdfl: config layer? for hotplug? [06:51] Kamion: see further down the list :-) [06:52] 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] mdz: for eg sound config [06:52] sabdfl: so i much rather keep what we can from Xfree86 [06:52] sabdfl: diverging from Debian on something as big as the X .config script is busy-work, surely? [06:52] sabdfl: we should use all of the stock Ubuntu stuff for that [06:52] mdz: with cdbackup it works [06:52] detecting the card is one thing, setting appropriate levels etc [06:52] sabdfl: also, upgrades [06:52] Kamion: i'm trying to standardise skill sets, which will pay off for us as a team later [06:52] sabdfl: I know, but Essential is a very hairy place [06:53] the other issue is that python is huge for an essential package [06:53] understood, having python there is not something i'm going to budge on [06:53] sabdfl: the issue comes where Python has to be installed, configured and completed before *any* package using it is installed [06:53] python-base [06:53] so it gets a bit hairy [06:53] sabdfl: the python guys will scream if we split up the standard library further :-) [06:53] the python guys will be thrilled that python has become Essential [06:53] ooof, which bits would you choose for python-base, too... [06:54] we had the split once in Debian. there are no clear lines where to split it. but that further down the list. [06:54] as for scchnnnaaakkee... [06:54] 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] will they? they weren't so thrilled about distutils not being there ... [06:54] fabbione: no, since we are creating these packages from scratch, i'd like to do it right the first time === 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 [] [06:54] I don't think they'd be happy unless the standard library's in one piece [06:54] Kamion: it will be, post install [06:54] sabdfl: in some configurations ... :) [06:55] sabdfl: but then you can't use any of the Python standard library in Python scripts in packages [06:55] sabdfl: and Python is pretty useless without its standard library :( [06:55] keybuk: depends which modules and extensions you compile in statically [06:55] ok, separate discussion, i dont mind really, just do mind that python is in essential for ubuntu [06:55] and that we use it for all system functions unless there's a bollocking good reason not to [06:55] (personally, I'd like to kick perl out of Essential :p) === sivang thought it was going to be for GTK/GNOME wise [06:56] sivang: Essential's a technical category [06:56] ok, the current unresolved item is the unification of hardware detection [06:56] we can either do this as one task, or break it down [06:56] Kamion said he would do the hotplugification of d-i [06:56] mdz: i think we're all agreed on hotplug for device detection [06:56] amu: live cd [06:56] so the remainder is live CD work [06:56] amu: ? [06:57] mdz: can we put someone in charge of that goal in general? [06:57] jdub: I will take responsibility for tracking the sub-tasks [06:57] that was easy ;) [06:57] fabbione: what is your opinion about dynamic X reconfiguration at boot, to detect hardware changes? [06:57] hmm good question, therorethically it should work === mdz ducks [06:58] mdz: i have some ideas already in that direction [06:58] fabbione: that would bring the live CD and the installed system in line with each other [06:58] mdz: and a possible solution [06:58] nd we will need it for a gui installer asa well [06:58] mdz: that will come after X.org is out [06:58] fabbione: hoary? [06:58] mdz: probably [06:58] mdz: we don't need that for a GUI installer [06:58] kernelfb? [06:58] right [06:58] gtk+directfb [06:58] ok [06:58] mdz: it's difficult to do that without crapping all over user changes [06:58] mdz: i am boiling the idea. i need to see with daniel if it's possible [06:58] well, in both cases we need _something_ which works at boot [06:58] yes, X is too heavy for a GUI installer and a bootsplash. [06:59] daniels: not for the installer [06:59] mdz: hold on a sec. we are confusing 2 things here [06:59] daniels: we could do it only if X fails to start [06:59] X is a good option for the installer [06:59] gui installer is directfb domain, imho, and bootsplash is mad phat splash's area [06:59] jdub: not convinced [06:59] one thing is configuring X at boot time for liveCD [06:59] ok, let's leave the gui installer discussion for another time [06:59] Kamion: easier to deal with than gtkfb or directfb [06:59] and one is autoconfiguring it for the normal installation [06:59] we're talking about unifying X config between the live CD and the installed system [07:00] mdz: ok. i have already a solution for that. and yes it will be hoary [07:00] I think there is overlap between that, and dealing with hardware changes in the desktop [07:00] jdub: directfb just comes up and just works, no effort whatsoever; I don't see how X could be easier [07:00] jdub: Kamion is right [07:00] jdub: X will only bring problems [07:00] (my parting shot: the framebuffer very rarely goes wrong -- like, ever; however, looking at the list, X autodetection is harder) [07:00] 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] anyway, yeah, unifying the config from livecd to ubuntu is hoaryable [07:00] fabbione: ok, so you will take care of moving the live CD X configuration over to use our config system rather than knoppix [07:01] i agree the gui installer is more directfb territory [07:01] mdz: if i get the resources yes. [07:01] daniels: (using fb doesn't rule out X...) [07:01] what about kdrive ? [07:01] 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] fabbione: you will, it's a priority, in python [07:01] mdz: when i offered my help for the livecd, my ping was lost [07:01] ogra: awful hardware support [07:01] mdz: yes, that's what i was suggesting [07:01] daniles: vesa ? [07:01] ogra: not an option [07:01] k [07:01] sabdfl: sorry.. i lost the contest... [07:02] have a tool that looks at a store of "what was previously detected" and sees if that has changed [07:02] fabbione: you will get the resources to unify live cd and installer x config in python [07:02] fabbione: contest? [07:02] sabdfl: ok [07:02] mdz: typo [07:03] sabdfl: but that will kill the plan to configure X at debian-installer time [07:03] sabdfl: that is something that we can probably do for hoary === maskie [~maskie@196-30-111-250.uudial.uunet.co.za] has joined #ubuntu-meeting [07:04] sabdfl: One issue with using directfb for the installer is that someone needs to write an accessibility interface for directfb/atk then [07:04] fabbione: we don't need to configure X at debian-installer time; the current timing is OK for hoary [07:04] mjg59: good call [07:04] X gives you already working a11y infrastructure [07:04] mjg59: text mode + speakup might make more sense for hoary [07:05] mjg59: hmm... can we run x on directfb? [07:05] however, using X in the installer would seem to be in conflict with Kamion's idea to support floppy installs :-) [07:05] mailq [07:05] sabdfl: yes [07:05] sabdfl: well, on fb [07:05] Kamion: Speakup requires extra hardware, doesn't it? [07:05] and we still have fall-back to text mode [07:05] mjg59: well, yeah, depends on the kind of a11y [07:05] at present, GUI installer is not on the hoary list [07:06] and we have many more items to review which are [07:06] um [07:06] so can we table that discussion for now? [07:06] yes [07:06] gui installer is on the hoary list, but it has sabdfl's question mark [07:06] i won't commit to having a gui installer for hoary [07:06] it will back us into a corner [07:06] ok [07:06] i've no problem with starting work on it [07:07] I propose that we not attempt ppc64 for hoary [07:07] there is currently no real vacuum for it to fill [07:07] mdz: won't attempt any further arch's unless a community team steps up [07:07] and it is a multiarch-wanting arch too [07:07] if one does, we'll provide h/w [07:07] yes, that would need a toolchain update [07:07] ok, consider it moved [07:08] " LSB compliant i386 libraries on amd64" [07:08] doko: this is 32-bit compatibility? [07:08] yes [07:08] what does it entail? [07:08] we'll need to do enough of ppc64 for G5 support, tho, right? [07:08] [sorry, I'm late] [07:08] elmo: I expect we'll build a ppc64 kernel for the powerpc arch [07:08] ok, cool [07:09] noted in bugzilla and discussed with herbert [07:09] it'd suck to not support our own buildds ;-) [07:09] hey, we have our own h4x0red kernel for that [07:09] yeah, ppc64 kernel != ppc64 userspace [07:09] elmo: you love custom kernels :-P [07:09] nonetheless, elmo has a point [07:09] doko: so what exactly would be involved in implementing this feature? === AberMatt [~cxv@clarlp1mrm04.clar.aber.ac.uk] has joined #ubuntu-meeting [07:10] I assume this would only provide basic support for compiling and running 32-bit apps [07:11] since we are not going to do multiarch in the packaging system for hoary [07:11] do they get a limited set of 32-bit libs to work with? [07:11] is this how we currently do mozilla and oo.o? [07:11] so that means a bi-arch gcc, and ia32-libs [07:11] sabdfl: yes, that's ia32-libs [07:11] heh, ubuntu is on /. again [07:12] 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] if there is not yet agreement, then this is not something we should push for hoary [07:12] the mention of LSB seems to imply that there is a standard [07:12] Mithrandir is not here [07:13] let's skip this item for now [07:13] 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] doko: sabdfl would like an essential python package [07:14] regarding the support side on amd64 , there should be a home for things like flash...... [07:14] doko: is there anything in the current python2.3 package which could be split in order to simplify it? [07:14] 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] yes, I looked back at the point where we had split it. [07:14] mdz: oh..... the peole are crying a lot about flash... === Seveas [seveas@213-73-236-154.cable.quicknet.nl] has joined #ubuntu-meeting [07:15] doko: there seems to be a fundamental conflict between providing the full python standard library, and having it be essential [07:15] 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] should this essential python work without /usr? [07:15] doko: perhaps we could provide all of the pure python stuff [07:16] doko: good question [07:16] perl-base works without /usr [07:16] uh [07:16] sorry [07:16] no it doesn't :-) [07:16] perl-base DOESN'T work without /usr [07:17] doko, mdz, let's figure out the implementation separately [07:17] ok [07:17] why stop at pure, and don't have the zlib module? this line is artificial. [07:17] ok [07:17] " Raise default dpkg-reconfigure priority, adjust packages as necessary?" [07:17] we already did that for warty [07:17] :-) [07:17] yeah, isn't that High already? [07:17] dpkg-reconfigure != debconf [07:17] dpkg-reconfigure's default priority is low [07:17] ohh, right [07:17] ah [07:17] what's the use case for raising it? [07:17] dpkg-reconfigure asks all questions by design [07:17] Kamion: to make it more useful [07:17] yes that causes the "million spurioous questions on reconfigure" experience [07:18] mdz: that would make it less useful, actually [07:18] "all questions" is too many questions [07:18] sabdfl: reconfigure is a deliberate choice, though [07:18] Kamion: those who want the full question set can ask for it [07:18] people WANT to see all questions :-) [07:18] (if they run dpkg-reconfigure) [07:18] if they do, --priority=low [07:18] Kamion: when we tell an Ubuntu user to run dpkg-reconfigure, they don't want to see all questions [07:18] mdz: why would we tell a user to do that? [07:18] reconfigure says "give me the same set of questions again" [07:18] Keybuk: because it is often the simplest way to solve their proble [07:18] m [07:19] Keybuk: i think we will aim to provide a high level UI for that === ogra agrees with mdz [07:19] for example, inside aptitude, press a key to reconfigure a package [07:19] ok, don't think it should be as high as --priority=high though, medium feels better [07:19] sorry, a bit late: is python2.4 default for hoary? [07:19] and the questions should be the same as the questions on install [07:19] Kamion: yes, I think medium is appropriate [07:19] Kamion: the idea is to exclude the "control freak" questions [07:19] and just give them a basic level of configurability [07:19] sabdfl: that just doesn't work with a lot of debconf scripts though [07:19] which is what medium should be [07:19] mdz: right, agreed [07:20] Kamion: because they assume you've answered the question already? [07:20] reconfigure should ask more questions than at install [07:20] sabdfl: synaptic support reconfigure via debconf (through the gnome debconf ui) [07:20] because install should exclude questions which have a reasonable default [07:20] sabdfl: varies; they'll certainly often have different behaviour. debconf's arbitrarily scriptable [07:20] what's the profile of an average Ubuntu user anyway? what can we expect of them? [07:20] i think we are asking for users to go from b0rked to v87686ked [07:20] but reconfigure should ask questions which have a reasonable default, and give the user the opportunity to change them [07:20] mdz: YES :-) [07:20] sivang: ideally we don't have one; Ubuntu works for all users, not just the average one [07:21] hold on [07:21] how do you tell a user "you answered the wrong way at install, do this, and answer it differently" [07:21] sabdfl: Kamion and I seem to be in agreement that what we want here is a default dpkg-reconfigure priority of 'medium' [07:21] that's fine, if i can see a list of new questions that introduces :-) [07:21] 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] if we made it 'high', it would often end up asking fewer questions, which I think would be worse [07:22] sabdfl: that is a problem of unsolvable complexity, I fear :-) [07:22] sivang: (this is slightly more abstract than that) [07:22] we can attempt to produce one for base+desktop, probably [07:22] kamion: i'd like to really define the set of questions that a user is ever likely to see [07:22] it varies depending on arbitrary criteria [07:22] 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] or maybe let them choose the profile, and configure debconf accordingly ? (please excuse me if this is all babble) [07:23] 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] 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] to be honest, I think I tend towards defaulting to --default-priority; as that's generally unsurprising [07:23] Keybuk: but will generally mean dpkg-reconfigure does absolutely nothing [07:23] Keybuk: that does nothing in most cases [07:23] I don't think taking a useful command and turning it into a no-op is good === mdz channels harder [07:24] why not having it low priority install time, and raise it automatically on reconfigure? (assuming this requests for more control) [07:24] sabdfl: maybe we shouldn't be recommending dpkg-reconfigure in general ... [07:24] 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] it still does the effect of the settings, as in postinst? [07:24] this change falls under the heading of stuf that we should change early [07:24] Kamion: need some tool to do it [07:24] so that we can catch as much of the fallout as possible through routine testing [07:24] yes [07:24] sigh [07:24] mdz: yeah, first thing type change [07:25] sabdfl: or, at least, for a very limited set of packages, like xserver-xfree86 [07:25] sabdfl: I think most of those bugs will be trivial ones [07:25] 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] sabdfl: things which are medium and should be low [07:25] sabdfl: the worst of it will be that we need to rewrite some text for the questions [07:25] mdz: yes, we will need to, guaranteed [07:25] sabdfl: ok, will try [07:25] Kamion: tvm [07:25] Kamion: as long as you're taking on work, will you be the one to upload debconf with the default priority change for dpkg-reconfigure? [07:26] (sometimes priorities are programmatically determined, so it may be fun) [07:26] mdz: yeah, that's easy [07:26] Kamion: it'll be on the list of things to break early, with your name next to it [07:27] moving on [07:27] SE Linux [07:27] let's dump it [07:27] this is a highly specialized project [07:27] I would really like to see some easy support for MAC [07:27] 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] if we want SE Linux, we need someone who knows all about it [07:27] grsecurity/SELInux/RSBAC/Whatever [07:27] Kamion : any example ? [07:27] Keybuk: agreed [07:27] yeah [07:27] from what I can tell with my chats with them, there's an arch-like learning curve to it [07:27] pitti: MAC? [07:27] Do we really want SELInux support? [07:28] it's going to be a user nightmare if we fiddle with selinux [07:28] doko: Mandatory Access Control [07:28] doko: mandatory access control [07:28] sabdfl: it strikes me as something to do as a derivative [07:28] Apart from the fact that SELInux is in upstream kernel, it is very complicated [07:28] we just won't have the cycles to do it propery for hoary [07:28] sabdfl: and then fold in once it is shown to work [07:28] mdz: good call [07:28] mdz: agree [07:28] seubuntu [07:28] and there's probably at least 6 months work on dpkg before it can even support it as well [07:28] We should develop it in Hoary time and publish it in grumpy [07:28] yeah. fedora seem to be having a lot of problems getting it usable [07:28] subuntu :-) [07:28] next up is fresher and juicier glibc [07:28] Did Fedora go with SELinux in the end? [07:29] sabdfl: is subuntu the distro with a root account per default? [07:29] apparently, Debian's glibc is ages old [07:29] mjg59: FC3 has a very very basic default configuration [07:29] mjg59: backed most of it out to a policy just for things like ssh [07:29] Can't we pick up something easier, like grsecurity or RSBAC? [07:29] mdz: it isn't [07:29] mdz: it'll be updated right after sarge [07:29] mjg59: yes, although far more toned down from fc2's aggressive policies [07:29] mdz: jbailey was working on updating glibc, AFAIK [07:29] mdz: it's one minor release behind [07:29] unless I'm missing something entirely [07:29] mdz: it's only been frozen because we (Debian RMs) are bastards :) [07:29] pitti: any of those things immediately takes us way out on a limb [07:29] is BenHerrenschmidt here? [07:29] afaik, newer glibc is tightly coupled with newer gcc ... :( [07:29] he proposed this, and might have some details about what it means [07:29] mdz: no [07:29] ftp://ftp.gnu.org/gnu/glibc/ [07:29] but he stopped a bit when he noticed sarge wasn't about to get released soonish [07:29] mdz: he's in .au, so most likely asleep [07:29] mdz: no, but we should get more details from him about it [07:29] ^ the latest there is 2.3.3 [07:29] Keybuk: glibc's stopped making releases, you have to pull CVS [07:29] mdz: happy to take an action [07:29] ok, so is this simply a "track Debian" sort of thing, then? [07:30] 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] Kamion: oh, I didn't know that [07:30] mdz: I think so [07:30] that's kinda scary [07:30] kamion: there is 2.3.3 [07:30] mdz: i can clarify it from him [07:30] (new glibc gets us NPTL on powerpc, amongst other things) [07:30] Keybuk: glibc stopped doing proper releases, 2.3.3 is a sort-of stable snapshot from last year, AFAIK [07:30] sabdfl: grsec/rsbac/lids only need kernel support and tiny userspace programs [07:30] if sarge doesn't happen soon enough to get it from Debian, is it worth moving ahead of Debian? [07:30] thom: only with gcc-3.4 [07:30] i.e., what do we get out of newer glibc? [07:30] which basically means we need hard-core glibc experts on staff to make it work [07:30] changing libc smells like abandoning binary compatibility with Debian to me [07:30] 1. NPTL on powerpc [07:30] mdz: can we pass on this and get more feedback from benh? [07:30] jdub: ok, let's [07:31] benh was saying that most of the problems with glibc were !(i386|amd64|powerpc), i.e. mostly NOTWARTY [07:31] since picking a working glibc out of CVS is generally experts' work [07:31] jdub: will you get that feedback? [07:31] (glibc -> CVS glibc) [07:31] mdz: happy to take the action [07:31] done [07:31] next up, usplash [07:31] no releases from glibc? nnaaaiiice [07:31] kernel, glibc, the yellow submarine === azeem suggests talking to jbailey for glibc [07:31] sladen: are you here? [07:31] no npmccallum either? [07:31] azeem: (benh raised the issue) [07:31] ah, mad phat startup [07:31] usplash, for those unfamiliar, is the proposed boot splash implementation [07:32] which works in userspace using the kernel framebuffer, rather than patching it [07:32] i don't believe there is any contention over what's on the wiki right now [07:32] ubusplash! [07:32] it also involves some dbus magic to provide a nice progress indicator [07:32] optional [07:32] can we bring these items back together? [07:32] jdub: which items? [07:32] usplash [07:32] mdz: not dbus until we can do some upstream hackery (libexpat in initrd, yuk) [07:32] usplash -> have it if it's finished [07:33] npmccallum won't be on the team for hoary [07:33] most of the bits of usplash are reasonably small [07:33] Keybuk: what we're here to decide is whether it will be done, and who will do it :-) [07:33] sabdfl: oh? [07:33] so we need to take this on internally or find a bounty candidate [07:33] jdub: fair enough, but jbailey is a glibc maintainer and was working on it for Debian anyway [07:33] sabdfl: it's almost certainly doable internally, IMO [07:33] Are we sure about being framebuffer based? [07:33] mjg59: as opposed to ... ? [07:33] mjg59: no, that's just current thinking [07:33] Keybuk: grep -ir npmccallum ~scott/patches/warty [07:34] if the implementor wants to do X or aalib, I'll at least listen :-) [07:34] I worry that using two different graphical mechanisms could result in weirdness [07:34] There'll always be some hardware that'll work with one and not the other [07:34] is fedora using a newer glibc? [07:34] sabdfl: write small fb blitter; write small co-ordination daemon; write novtswitch (done); make gdm and lsb init lib usplash-aware [07:34] mjg59: we'll need to get framebuffer stuff into good shape eventually anyway [07:34] daniels: don't trivialise the issues, x-platform for a start [07:34] can we bountyise this to sladen? [07:34] jdub: depends on sladen [07:34] sabdfl: true [07:34] sabdfl: so, uh, can someone update StaffOverview when people leave [07:34] sabdfl: yes, fedora is pretty much running off head of CVS [07:35] mdz: This is sort of related to later stuff, but suspend/resume is going to be easier without framebuffer [07:35] Probably massively easier [07:35] Keybuk: yes, sorry, i should have [07:35] (on x86, at least) [07:35] mjg59: are the framebuffer issues unsolvable? [07:36] mdz: vesafb is never going to work across suspend/resume, because there's no way to reconfigure the mode [07:36] mdz: can we assign a 'project manager' to the goal, to sort out bounty, delivery, etc? [07:36] vesafb-tng might be a better plan, but it's a big divergence from mainstream [07:36] jdub: we should decide whether one of us will do it, or bounty it out [07:36] it's looking like a bounty sort of thing so far [07:36] yes, i think it's a bounty [07:36] unless someone here has a very strong interest in it [07:36] ok, bounty [07:36] not sure it's critical enough to manage internally [07:37] " Do something smart with SMART?" [07:37] hold on [07:37] mjg59: give me a quick rundown of the alternative options to fb for ubusplash? [07:37] can we assign someone to manage the bounty? [07:37] sabdfl: X [07:37] jdub: I will [07:37] ok [07:37] sabdfl: Most straightforward is to start X /very/ early [07:37] 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] Which is what Fedora do [07:38] the SMART proposition would involve getting the SMART tools installed by default, and having them do something useful by default [07:38] ideally the user should get some notification when their disk is failing, etc. [07:38] mdz: sounds underspecified [07:38] mdz: silbs and i have a PA starting in two weeks who can carry the load of bounty state tracking [07:38] jdub: indeed [07:38] mjg59: yes [07:38] sabdfl: (that's good news) [07:38] sabdfl: administrative or technical? [07:38] SMART tools don't work with SATA drives last time I checked [07:38] mjg59: but they also start kdrive to track init, which is just bong imo [07:38] mdz: purely admin [07:38] mjg59: note that the current plans involve starting x very early [07:39] daniels: like, putting X in initrd ?! [07:39] sabdfl: ok, so I'll expect to continue to track technical progress [07:39] loading ramdisk ...... [07:39] daniels: but not THAT early [07:39] Keybuk: not as crazy as it sounds [07:39] still loading ramdisk ..... [07:39] Keybuk: no [07:39] sabdfl: right. [07:39] mdz: i think we should have an internal contact for each bounty, clearly, but not always you [07:40] it will be good to develop a little management capacity in the rest of the team too [07:40] 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] sabdfl: less work for me is usually acceptable :-) [07:40] when gdm has a login screen ready for the displaying, switch over to that [07:40] If we want framebuffer functionality and we want suspend/resume, we're going to have to modify every single framebuffer driver [07:40] mjg59: can you get rid of framebuffer post-boot? [07:40] sabdfl: framebuffer 4 lyf, i'm afraid [07:40] 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] sabdfl: Not trivially [07:40] sabdfl : could there be a more thorugh explenation for the bounties on the wary page? IMHO it should have already been moved to Hoary [07:41] sabdfl, mdz: a number of the goals with my name attached are ones i expect to manage, rather than do [07:41] mjg59: that's kind of unavoidable on powerpc, mind ... [07:41] sabdfl : for example, what is doc-base registeration? [07:41] sivang: several of the goals assume a thorough working knowledge of Debian packaging [07:41] which would be necessary to complete them anyway [07:42] sivang: every thing that ships documentation needs to register siad documentation with doc-base [07:42] Kamion: PPC is less of a problem - people have already dealt with that [07:42] mjg59: oh, the modifications aren't quite portable? [07:42] let's take the usplash design discussion offline [07:43] we have much more ground to cover [07:43] Kamion: The current suspend/resume code relies on OF doing some reinitialisation [07:43] next up is the question of whether we should handle NTP differently for Hoary [07:43] using ntpd rather than just running ntpdate at boot [07:43] aren't we doing ntpdate+ntpd now? [07:43] no, we currently only do ntpdate [07:43] Keybuk: "No listening ports" [07:43] ahh, it's in the seed but doesn't do anything? [07:43] that was basically the delay problem, when you don't have a network connection? [07:44] this proposal came from the fact that gnome-system-tools integrates with ntpd [07:44] and not ntpdate [07:44] it would be nice to have an ntpd listening on the port by default. [07:44] so it has a little checkbox which will install ntpd, and then let you configure which servers to sync with [07:44] then again, the current ntpd is pretty fat [07:44] the delay could easy be solved by a poing in the bootscript [07:44] lamont: it'd be nice to have cups listening, http listening, etc. [07:44] it'd be nice to get rooted [07:44] i think ntp would be much more doable if we were smart about miitool or iwtool or whatever for link beat [07:44] Keybuk: heh. yeah [07:44] but then we're security swiss-cheese [07:44] can ntpdate be run in the background? [07:44] sabdfl: yes, it can [07:44] daniels: (NetworkManager) [07:44] in fact, I think it ignores errors currently anyway [07:44] but the delay is a separate issue [07:45] ntpdate and ntpd do different things [07:45] let's not do ntpd unless we really have to [07:45] very different [07:45] you need both [07:45] i'd be much happier with a cron'd ntpdate [07:45] the delay isn't ntp specific. needs a mod to /etc/nsswitch.conf [07:45] ntpd keeps the clock in sync, but will cowardly not sync it if it's too far away [07:45] ntpdate syncs it, and then leaves [07:45] right [07:45] yes, ntpdate is a one-timerr [07:45] sabdfl: that's what we used to do at Demon to avoid the port [07:45] the cowardly thing is actually a feature tho [07:45] we decided way back in london that we wanted ntpdate as a default [07:45] (well, you have the port, but only for a few seconds) [07:45] sabdfl: anyone relying on filesystem timestamps would be very unhappy with cron'ed ntpdate [07:45] but there's nthing stopping us from doing it regularly [07:46] so the obvious course would be to change g-s-t to integrate with our ntpdate package [07:46] rather than with ntpd [07:46] lamont: where would you rely on filesystem timestamps? [07:46] make [07:46] oh, btw, orthogonally, can we pretty please de-root ntpd, even if we don't install it by default [07:46] jdub: is that a reasonable proposition? [07:46] lamont: anyone relying on filesystem timestamps that much would have configured ntpd themselves [07:46] elmo: good call [07:46] ok [07:46] the ntpdate-regularly thing also breaks regular cron jobs [07:46] mdz: 'synchronise now' or 'set up regular cron job'? i'm kinda uncomfortable with the cron job too [07:46] jdub: 'synchronise now' button, and configure servers [07:46] as time just, err, doesn't behave like time.. whereas with ntp, it just speeds up or down :) [07:47] seems we have the same problem either way [07:47] I'm not particularly hot on cron either [07:47] Keybuk: make users don't particularly care that time is accurate to within hours, they just care that it's monotonically increassing [07:47] mdz: that'd be great [07:47] jdub: bounty? [07:47] mdz: yeah [07:47] without regular ntpdate, time is at least approximately monotonic. :-) [07:47] jdub: someone from gnome? [07:47] sabdfl: rather than cron, wouldn't /etc/network/ifup.d/ make much more sense? I. e. for dialup users [07:47] mdz: yes [07:47] can we use ntpdate to nudge the clock syncing algorithms in the right direction? [07:47] sabdfl: that's more what ntpd's for really [07:47] sabdfl: ntpd is the clock-syncing algorithms [07:47] mdz: have a candidate for quite a few of these [07:47] sabdfl: all ntpdate does is yank time to the current time [07:48] ok, so that's on the bounty list [07:48] ntpd slews the local clock to keep it there [07:48] if the problem is the open port, can't we just bounty someone to fix that? [07:48] next up is speeding up the boot process [07:48] or is it inherent to ntp's design? [07:48] elmo: that's because ntpd uses udp, isn't it? [07:48] Keybuk: yes, but it could still be improved [07:48] mdz: didn't you rewrite hotplug in Perl? [07:48] ntpdate can make the clock run backwards and confuse everything [07:48] Keybuk: yes, and then reverted it because perl needs /usr [07:48] *cough* *splutter* [07:48] mdz: I'd be tempted with a little C parser for that [07:48] Keybuk: yes [07:49] If you're running slow, ntpdate will make your screensaver come on === enrico leaves the meeting [07:49] Keybuk: but ssshh, before sabdfl insists that it be rewritten in python :-) [07:49] Please reach me in the next days if you need anything [07:49] "faster" [07:49] mjg59: that seems like a bug in xscreensaver === enrico [~enrico@81-174-12-206.f5.ngi.it] has left #ubuntu-meeting [] [07:49] ntpd just makes your clock go faster or slower until it reaches the right time [07:49] 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 === martinald [~hm@martinalderson.plus.com] has joined #ubuntu-meeting [07:49] Keybuk: hauling perl into memory was a big win [07:49] mdz: The results from gettimeofday() suddenly change... [07:50] is hotplug very complex? why not bounty a C implementation? [07:50] sabdfl: *shrug* I could do it in a few hours [07:50] I'm off home - back in 15 minutes or so [07:50] sabdfl: it's not very complex at all [07:50] I'm reasonably sure I wrote one and have it on my disk somewhere [07:50] Keybuk: go for it [07:50] but it's easier to maintain in shell [07:50] in fact, I *know* I wrote one [07:51] is it the shell that makes it slow? [07:51] it's the fact that it uses shell *exclusively* that makes it slow [07:51] or is it hardware delays? [07:51] sabdfl: parsing in shell tends to be slow, you have to fork lots of processes [07:51] I suggest that we rewrite certain bits in C [07:51] and not the whole thing [07:51] i thought they put in a deliberate delay to avoid some race condition in specific kernel versions [07:51] it's just the modules.pcimap parser isn't it? [07:51] mdz: I was thinking the pcimap etc. parsers [07:51] Kamion: that's most of it, yes [07:51] Keybuk: exactly [07:51] that's what I rewrote in perl [07:52] we could use ash as /bin/sh to make things a bit faster. [07:52] and saved about 0.3 seconds per device [07:52] and I know I wrote one for i-d; so I've just got to find it [07:52] another item under the same heading is starting gdm earlier [07:52] mdz: as I mentioned before [07:52] that's a large perceived performance benefit [07:53] I think we were in agreement that we should just do it [07:53] early on, and fix whatever breaks [07:53] you can start gdm as soon as you know the hostname won't change from under you [07:53] mdz: stick the hotplug parser under me, it'll give me something to do during test case runs :p [07:53] if the hostname changes under X, you're totally screwed [07:53] Keybuk: ok [07:54] need someone to take responsibility for gdm [07:54] since that's on the early breakage list [07:54] do we know how early it *can* be started? [07:54] might as well take that one [07:54] Keybuk: i have a very good idea [07:54] Keybuk: I've started it as the first thing in runlevel 2 [07:54] with on il leffects [07:54] it probably needs all the Utopia stuff for when the user logs in [07:54] no ill effects [07:54] daniels: ok, yours [07:55] next up, we have some kernel stuff [07:55] which I think is probably bounty-oriented [07:55] Keybuk: hal must be running, the other stuff is gnome session [07:55] mdz: I have it at 21 ... I needed alsa, dbus and fam loaded first [07:55] oh, speaking of dbus [07:56] the other side of the start-gdm-early coin is displaying startup notifications for the things that start after it [07:56] with a little dbus magic [07:56] mdz: usplash [07:56] overlap with usplash [07:56] yes [07:56] mdz: (the usplash daemon just either writes out to the fb or X as is appropriate) [07:56] anyway, the next few items on the agenda are fixing the various warts in how we load kernel modules [07:56] personally, i think that is wholly subsumed by usplash [07:56] the fact that IDE stuff doesn't Just Work is the big one [07:57] also figuring out the right strategy for drivers which are no longer autoloaded with udev [07:57] unless anyone here has a strong interest and the domain knowledge for it, I suggest it be a bounty [07:57] having mount load loop when needed would clean up a lot of user questions [07:57] mdz: bounty [07:58] mdz: agree [07:58] but yes, bounty [07:58] Kamion: having it autoloaded somehow, whether it's mount's job or something else's needs to be determined [07:58] bounty yes [07:58] " Go back to the LiveSeed? idea to provide a more demonstration-worthy LiveCD?" [07:58] mdz: that has a pre-req of "make liveCD seeed fit..." [07:59] that's probably a non-issue given the size of the livecd + winfoss bits [07:59] this seems to raise the question of whether we want to try to make the live CD snazzier than the default desktop [07:59] if LiveSeed is a strict subset or superset of each of the other seeds, that's fine, otherwise tricky in germinate === oOpepinOo [~yann@lns-vlq-39f-81-56-131-220.adsl.proxad.net] has joined #ubuntu-meeting [07:59] i think we do [07:59] for instance, i'd like to have a package of demo files [07:59] as you say, I don't think we can add much due to space constraints [07:59] desktop-plus-some-stuff-from-supported would work [07:59] live dvd? [07:59] (or desktop-minus-some-stuff) [07:59] Kamion: yeah, that's what it'd be [07:59] Kamion: yeah, +/- would be good [08:00] but all within supported [08:00] jdub: but not both [08:00] daniels: wont work in cd roms [08:00] - ttf-baemuk! [08:00] but if we want to add some bits from supported and take away pieces, the germinate-fu gets complicated [08:00] do we have space? [08:00] sabdfl: after tossing celestia, I think we're at 650MB or so [08:00] sabdfl: winfoss makes it hard [08:00] sabdfl: it's very tight [08:00] then i vote for parity between livecd and installed [08:00] 643MB [08:01] anyway, this could be a derivative livecd [08:01] for demos [08:01] yes [08:01] and stuff [08:01] I think we should probably leave the package list alone for hoary [08:01] for the live CD [08:01] i.e., match desktop [08:01] sabdfl: parity for the official livecd, yeah [08:01] we could well have derivatives in place for hoary [08:01] jdub: maybe a demoCD which puts your cool hoary packages in insead of WinFOSS? [08:01] " Optionally encrypted home directories that work out of the box (MartinPitt?)" [08:01] lamont: yeah [08:01] pitti: would you like to say something about this? [08:01] partman was designed with support for encrypted filesystems in mind [08:02] I played around a little today with several implementations [08:02] I won't discuss them here, I will mail [08:02] but it's not been implemented in partman yet [08:02] I just wnat to ask if there is consensus that we want support for it [08:02] I would like my USB dongle to automount after asking me for a passphrase... [08:02] pitti: I'm not sure exactly what it is [08:02] pitti: would this be cryptoloop stuff? [08:02] IMHO it would be a great thing for laptops [08:02] I think it's a lot of complexity for the default install [08:02] pitti: i would like it hounestly [08:02] not necessarily cryptoloop [08:02] from the user's view nothing changes [08:02] pitti: are we talking about having /home be a cryptofs, created in the installer? [08:03] not by default [08:03] if he logs in, his homedir is transparently decrypted === 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 [08:03] Kamion: I think it needs installer support to have it from the beginning [08:03] crypto home sounds slow to me [08:03] pitti: indeed [08:03] consider that people will go, "ooh! this smells like security!" [08:03] it should be optional === Matt| [~Matt|@81-178-76-139.dsl.pipex.com] has left #ubuntu-meeting ["Leaving"] [08:03] sabdfl: right, I don't think it's a default thing [08:03] It does not make sense for desktops [08:03] the user should deliberately choose it [08:03] I don't see why /home should be special [08:04] pitti: can we support it sanely? [08:04] we don't need to encrypt the whole partition [08:04] partman may grow this sort of stuff if we just wait for the Anton Zinoviev machine to grind out code :-) [08:04] if you want encryption, it should be across the board [08:04] encrypting just some files or directories is actually less hassle [08:04] mdz: you know a user is around when you want to access it [08:04] pitti: why not, but you would have to mount separate ones for /home/* [08:04] but it does not make sense to encrypt e. g. /us [08:04] I mean /usr [08:04] doko: not mount, just encrypt the directories separately [08:04] cryptoloop is not the only (and not the best) implementation [08:05] ok, let's discuss this on ubuntu-devel and hash it out [08:05] so to speak [08:05] so is there general interest? [08:05] sabdfl: har har [08:05] Kamion: you cannot feeC[Cl the differents between a crypred dev and a normal. Computeres are too fast. [08:05] pitti: i'm concerned about supportability [08:05] That was the only question, I will work out details and bring it to the list [08:05] pitti: it's interesting, yes [08:05] whether we can and will do it depends on the details [08:05] jdub: I will work that out [08:05] waht about repairing a broken FS pitti ? [08:05] pitti: it may be something i prefer a bounty / contractor to do, rather than internal resources [08:06] ogra: I don't see what's different. e2fsck does not care whether the data looks like garbage [08:06] sabdfl: your choice :-) [08:06] pitti im ean dd rescue on a broken disk i.e. [08:06] 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] If we want to do it inhouse, I would like to deal with it [08:06] ogra: of course the rescue copy will still be encrypted [08:06] LeeColleton: doesn't gnome-keyring-manager handle that stuff? [08:06] ogra: you need the same password to decrypt it [08:06] LeeColleton: (new seahorse will be considered) [08:06] mdz: no === mvo_ likes the idea of encrypted /home [08:06] but can i decrypt easily [08:07] mdz: that's for gnome-keyring (not gpg related) [08:07] mithrandir was working on some dm-crypt gui stuff, iirc [08:07] ogra: it is transparent === mjg59 is back [08:07] pitti: k [08:07] my god, we're nearly a quarter of the way though [08:07] ogra: it could be encrypted with your login password [08:07] ogra: and we need a PAM module for this, but there are solutions [08:07] What are you guys thinking in regards to mono for hoary? [08:07] right, moving on [08:07] LeeColleton: (can you put it on the HoaryHedgehog/SupportedSeed proposals list please?) [08:07] 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] ficusplanet: (we're working to an agenda, see HH feature goals) [08:07] pitti: as long as i can repair it with, say knoppix ....if nothing else is handy [08:08] jdub, thanks [08:08] 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] ogra: depends on the concrete implementation. Repairing an fs is always possible, though [08:08] next up, kernel unification [08:08] this is herbert's domain [08:08] pitti: :) [08:08] I think we know exactly what needs to be done [08:08] mdz: (btw, are you modifying the page as we go?) [08:08] jdub: I'm making notes and will replace the page wholesale [08:08] jdub: where is the proposals list? [08:09] mdz: ok [08:09] what about inotify? [08:09] LeeColleton: HoaryHedgehog/SupportedSeed [08:09] mdz: should definitely go in, something for herbert [08:09] jdub: has it been submitted upstream? [08:09] yes [08:09] not accepted yet [08:09] ok [08:09] inotify seems to be the way forward [08:09] framebuffer-based bootsplash is superseded by usplash [08:09] and it makes fam+portmap go away :) [08:10] (yay!) [08:10] (gamin does too, but it makes the whole problem easier) [08:10] mdz: kernel unification> restricted-modules too [08:10] Kamion: hmm? [08:10] ANNOUNCEMENT: we got our first customer for a tech support contract today END ANNOUNCEMENT :-) [08:10] cool! [08:10] WOOOHOOO!!!!! [08:10] yeah :) [08:10] congrats [08:10] sabdfl: EXCITEMENT wonderful! END EXCITEMENT [08:10] canonical ltd? ;-) === mvo_ is happy about that [08:11] keep going :-) [08:11] mdz: linux-restricted-modules and the udebs of same [08:11] Kamion: yes, includes that [08:11] I'll make an explicit note [08:11] w.r.t. kernel, i've discussed creating a six-month release of 2.6 for broader use than ubuntu [08:11] with herbert [08:12] which I think is a fantastic idea [08:12] rocking [08:12] 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] for the smaller distros [08:12] sabdfl: what does this mean? two kernel upgrades per year? [08:12] doko: yes, in a predictable release schedule [08:13] because at the moment, we have crack from upstream [08:13] moving on, we have a bunch of installer stuff [08:13] tops of which is the controversial gui installer [08:13] nice idea, that would include the binary tools needed for restricted modules? === johnlevin [~johnl@dsl-80-42-84-143.access.uk.tiscali.com] has left #ubuntu-meeting ["Leaving"] [08:14] sabdfl: gui installer decision? [08:14] not for hoary [08:15] ok, pushing it back [08:15] kickstart [08:15] no problem starting down the road, balanced against hoary priorities [08:15] 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] what's kickstart? [08:15] yes please! [08:15] pitti: unattended semi-custom installs based on a config file [08:15] pitti: Red Hat mass deployment thing [08:15] kickstart == RH compatible pre-seed format [08:15] thx [08:15] The RH implementation was moderately sucky when I played with it [08:15] does it have to be RH-compatible? would that be the hard part? [08:16] Making it similar to RH would ease transition [08:16] 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] sabdfl: the format, yes; the data, no [08:16] sabdfl: sysadmins of my acquaintance would kill for it [08:16] RH-compatibility [08:16] I think the useful subset of RH-compatibility would not be that hard [08:16] however, I believe that it's "just" a format translation job [08:17] kickstart generation guis already exist, etc. [08:17] for the bits that usually vary between distros, sysadmins are already used to having different fragments for RH/SuSE, etc. [08:17] anyway, kickstart is something we'll do for hoary, but needs spec work [08:17] Kickstart would be a very good thing to push back into Debian [08:17] mjg59: yep [08:18] next up, the fancy keyboard selector [08:18] smells like bounty to me [08:18] there's localization-config in Debian [08:18] mdz: i will be very glad to get rid of X keyboard management [08:18] (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] that's Konstantinos Margaritis' work (Skole) [08:18] localization-config is like what we do now for X [08:18] the fancy selector is something much fancier :-) [08:18] fabbione: will X.org still work with the GNOME Keyboard Preferences stuff? [08:18] ah, I thought l-c was better, haven't looked in detail yet [08:18] this is the thing which deduces your layout by having you type things [08:18] Keybuk: yes [08:18] aha [08:18] and uses that to seed everything which needs keyboard layout info [08:18] Keybuk: i don't know yet [08:18] console and X [08:19] it requires some fairly broad knowledge about layouts and their differences [08:19] mdz: we use the same code for X now and it doens't look that good considering the bugs we got [08:19] fabbione: this is not the same thing, it is a different project [08:19] mdz: we need to involve the console-data maintainer to do the right thing [08:19] the problem is the zero-question assumption [08:20] some people in the czech republic have us-layout keyboards [08:20] we will not guess as we do not [08:20] now === Peltoilves [~peltis@tolu.edu.hel.fi] has left #ubuntu-meeting [] [08:20] we will ask once, and ask very thoroughly [08:20] right === siretart [siretart@meinungsverstaerker.de] has joined #ubuntu-meeting [08:20] ok, going on the bounty list [08:20] Language, Timezone and Keyboard are sensible questions to ask everybody [08:20] even MS ask them [08:20] hotplug installer we already covered as part of unifying hardware detection [08:20] though highlighting the most common answer is a win [08:20] Keybuk: our problem is sync X and console [08:20] " support for multiple network devices of same type" [08:20] mdz: bountying out to someone with very good keyboard knowledge (of which there are very few) is recommended [08:20] Kamion: ? [08:21] mdz: I don't know what that is? [08:21] neither do I [08:21] mdz: maybe it's ISDN bonding or something [08:21] I thought hotplug solved that? [08:21] I certainly hope not [08:21] assuming he's talking about the 2.4-era of having to tell the module to create eth0 and eth1 type things [08:21] mdz: whatever it is, it stinks of bounty or "wait for Debian to do it" to me :-) [08:21] might be refering to ifrename things [08:21] marking it as not-enough-info [08:21] " Option to set up proxy/authentication before attempting first apt-get update" [08:22] this one would require sabdfl approval to ask another question in every install [08:22] the code's there, but it fell to the "fewer questions" axe [08:22] mdz: we explicitly killed that question if we could reach archive.u.c [08:22] right [08:22] what's the loss with the way we do it now? I thought we tested [08:22] but there has been user demand for it [08:22] fabbione: indeed, don't we test and then ask if it fails [08:22] fabbione: but do we ever ask that question? I've never seen it [08:22] Keybuk: what we lose is caching proxies [08:22] just because I can reach a.u.c doesn't mean I want to go that path.. [08:22] which is a big win for mass installs [08:23] sabdfl: ? [08:23] Kamion: yes, we ask if we cannot reach archive [08:23] isn't that what custom is for? [08:23] fabbione: I think that code might be buggy, because I would have seen that question. [08:23] Kamion: but that happens with choose-mirror === ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting [08:23] fabbione: define "reach" === ..[topic/#ubuntu-meeting:mdz] : Hoary kickoff meeting || Agenda: http://www.ubuntulinux.org/wiki/HoaryKickoffMeeting [08:23] lamont: wget a Package file or a Release. [08:23] lamont: can't remember [08:23] ok [08:23] tell the user to pull the plug if wants proxy support [08:23] 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] let's file a bug on that and move on [08:24] " CD-based upgrade?" [08:24] doko: sadly, pulling the plug just means you don't get prompted for _any_ network source. [08:24] or does it.... [08:24] 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] mdz: would be nice if you could put the CD in and it do the right thing [08:24] should be pretty trivial too? [08:24] is that apt-cdrom-style, or boot from CD (a.k.a. crack)? [08:24] as in auto-run? [08:24] mdz: with some kind of auto-run? [08:24] Kamion: autorun type thing [08:24] Kamion: not boot from CD [08:24] mmmkay [08:24] lamont: anyway it would counter intuitive to pull the plug for configuring some network stuff ;) [08:24] we have no autorun in warty, but that'd be the general idea [08:25] autorun is off by default [08:25] but do we have some sort of autorun in place that can take care of warty -> hoary? [08:25] double-click and have it run apt-cdrom, change sources.list and go [08:25] right-click -> upgrade would be nice [08:25] mdz: sounds like something we'd add in hoary to take advantage of with grumpy, no? [08:25] ok [08:25] lamont: we can do it for hoary, it's just a double-click rather than autorun [08:25] (re proxy conf, sounds useful in corporate setting, like kickstart, perhaps with a boot-time command) [08:25] lamont: make it an executable on the CD ... you put the CD in and run something on it [08:25] put something in the root of the CD called "DO THE UPGRADE PLEASE".sh [08:25] mdz: I can take it [08:25] sabdfl: you could easily preseed it [08:26] sabdfl: (modulo tweaks to make sure preseeding works for that) [08:26] kamion: agreed, useful for those who need it, not necessary to ask otherwise [08:26] fits with the upgrade-center idea that Mitario proposed [08:26] sabdfl: I don't think we talked about the CD-based upgrade; what's your opinion? [08:26] i like it [08:27] ok [08:27] I'm happy for mvo_ to work on it [08:27] "good to have" [08:27] it should be a fairly small project [08:27] not sure it has to be automatic [08:27] it should be pretty trivial ... the CD is an APT archive anyway [08:27] I think it would be very slick for it to be automatic, post-hoary [08:27] but anyway that's the easy part [08:27] not *too* automatic though :-) [08:27] as automatic as other autorun stuff, i.e. prompt for confirmation first [08:28] and sudo password [08:28] mdz: auto-run of binaries signed by a key in a keyring type thing? === Kamion mails sabdfl a batch of trojaned CDs, just for fun === sabdfl installs everything Kamion sends me, just for fun [08:28] :-) [08:28] " Install libglide3 library when one of the supported 3dfx cards is detected" [08:28] Kamion: I was just going to burn one to carry around with me.. :-) [08:28] -> desktop seed suggestion [08:28] this has a question from Kamion next to it which doesn't seem to have been answered [08:28] daniels: do you know wha tit's about? [08:28] isn't libglide3 toxic^Wproprietary? [08:28] mdz: it's not dangerous to install libglide3 [08:28] sabdfl: Not for years [08:28] sabdfl: no [08:28] 3DFX GPLed it before going under [08:29] libglide3 is dlopened when using some cards or something? [08:29] It's needed for DRI on Voodoo3/4/5/6 [08:29] so let's make it part of X [08:29] mdz: X uses it if the driver is 3dfx and if there is a compatible board [08:29] ok [08:29] so, yes, desktop seed suggestion [08:29] mdz: yes, it's dlopened [08:29] Yeah, it's utterly harmless [08:29] " installer bootable from floppy (for older systems that don't boot from CD/network)" [08:29] libglide3 is fine for desktopseed [08:29] fabbione: can it emulate GL? [08:29] Except for its crackful build system [08:29] Kamion: ? [08:29] (sorry, just trying to figure out why my laptop's /home got shut down) [08:30] mdz: that's fairly trivial, I only disabled it for warty because we didn't have time to test it [08:30] we've had a lot of requests for it [08:30] bob2: it is for GL [08:30] fabbione: ah. thanks. [08:30] Kamion: ok, added to the list of stuff to switch on early and start testing [08:30] " installer bootable from USB drive (for laptops without CD drives)" [08:30] that would be extremely cool === fabbione did it once [08:31] d-i boots nicely from USB [08:31] should work fine [08:31] another Kamion plaything [08:31] pretty much likewise; I propose putting the netboot kernel and initrd in a form conveniently ddable to USB [08:31] .. to bad i didn't have any device that could boot from USB [08:31] nice to have it for our shop: memory stick preloaded with warty/hoary :) [08:31] Debian supports this, but they do it by telling you to put a businesscard ISO on the USB stick [08:31] doko: you can fit warty on a Laks watch at the moment :) [08:32] 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] 500mb in it? [08:32] ? [08:32] it works without an image, just the initrd and the kernel (and syslinux) [08:32] ok, let's take a brief diversion and talk about the laptop goals [08:32] sivang: 512MB [08:32] hmm... think we can keep hoary under 512MB? [08:32] because mjg59 can't stay much longer [08:32] My usbstick just needs 4 MB for a network d-i [08:32] Sorry - feeling miserably unwell [08:32] sabdfl: unlikely [08:32] (I have to go in about 40 minutes, BTW) [08:32] the big laptop goal is going to be suspend support [08:32] Let's make this quick then [08:32] mjg59: what's our strategy for that, regarding ACPI vs. swsusp etc. [08:32] software suspend? [08:33] Suspend to disk is fairly easy, with the possible exception of nvidia [08:33] There's some drivers that could do with fixups, but in most cases that's straightforward (and it's major community love) [08:33] this is definitely something we should break early [08:33] what changes do we need to make? [08:33] SuSE are shipping with swsusp enabled by default in 9.2, so there's no strong reason not to include it [08:33] It's a kernel patch plus some modifications to let it work with initrd [08:34] mjg59: and also changing acpi-support to enable it by default? [08:34] Yeah [08:34] what about acpi S3? do we care at all? [08:34] swsusp requires swap >= ram? [08:34] S3 is, in almost all cases, preferable to StD [08:34] what about all the problems we have with "boot with acpi=off"? [08:34] jdub: No [08:34] jdub: Except in extremely pathological cases [08:35] mjg59: so what will the default action be, for sleep button, lid close, etc.? [08:35] mdz: s3 is nice but really, really hard to get right [08:35] mdz: needs lots of testing and brute-forcing as to which modules need to get removed [08:35] s4 is too heavy-weight for lid close, I'd say [08:35] mdz: S3 has an outside chance of being useful early enough for Hoary [08:35] mdz: i'm making acpi-support-x40 more generic, so we can just slot in different module lists [08:36] mjg59: what's the change that we'll make in the next week or so in order to start testing it? [08:36] "outside chance" is not something we should aim for [08:36] mjg59: swsusp? [08:36] 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] I couldn't not spot the "excellent documentation" feature. is this going to be discussed here? [08:36] that sounds doable [08:36] being a hoary feature goal. [08:36] mdz: you need double sawp as ram [08:36] swap [08:36] amu: ?? [08:36] sivang: let mdz set the pace [08:36] amu: No [08:36] sivang: (we're not there yet) [08:37] ok, sorry. [08:37] mdz: sw susp [08:37] sivang: we've skipped ahead to accomodate mjg59 having the plague [08:37] There are three main issues with S3 [08:37] mjg59: no? [08:37] 1) hardware where it just doesn't work === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] [08:37] ok, it sounds like swsusp is what we should start testing for hoary [08:37] mdz : ok, we can always dicuss this on CC meeting [08:37] The VIA craptop is an example of this. I'm working on it, mildly in touch with someone in Intel [08:37] and if good things happen with s3, maybe we can enable it on a case-by-case basis for some laptops [08:38] 2) hardware where it works but video doesn't come back [08:38] mjg59: ok [08:38] mdz: this kinda ties into the hardware db [08:38] " More flexible implementation of TRLS features (hal/dbus, etc.)?" [08:38] is swsusp the One True suspend-to-disk thing now? [08:38] (2) is not easily solvable in the VESA case [08:38] what is that about? [08:38] ie will it support !i386 soon/now? [08:38] 3) individual drivers that don't work [08:38] (3) is easily fixed on a case by case basis [08:38] mjg59: TRLS? [08:38] bob2: as I understand it powermac support is RSN [08:38] mdz: it almost certainly is !hoary - moving power management infrastructure to use hal [08:38] More hardware for testing would be good. If I can sort the craptop, I'll produce kernel images. [08:39] trls == Totally Rad Laptop Support [08:39] and then doing all the TRLS stuff over dbus [08:39] I think that's post-hoary [08:39] we really ought to fix that [08:39] We need more hal support for platform devices first [08:39] as rad as it is, it's fairly hacktastic on the inside at the moment :-) [08:39] mdz: yes. [08:39] what about the configuration side of it? [08:40] i.e., currently the user needs to hand-edit scripts in /etc to change the timeouts and such [08:40] 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] especially that evil-cryptic hard drive timeout value [08:40] 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] mjg59: blank the screen and leave everything powered up? that seems to cause lots of user surprises [08:40] mjg59: there are some reports about swsusp.? i guess many brocken drivers, like cetrino wireless ;) [08:41] mdz: Suspend to disk on lid close is hard [08:41] amu: they'll be fixed [08:41] centrino even [08:41] mjg59: why harder than power button? [08:41] so no need to mod stuff under /etc [08:41] mdz: stand up, shut lid, move to other table, open lid [08:41] mdz: It's difficult to get most hardware to autoresume from swsusp on lid open at present [08:41] the time the lid is shut is often less than the time to actually suspend [08:41] mjg59: ah [08:42] (not to mention the technical reasons) [08:42] ok [08:42] And we're still talking 20 seconds or so for resume [08:42] mdz: something good for the liveCD [08:42] " Automatic /cpufreq module loading (possibly for desktop systems, too)" [08:42] Sladen was working on that [08:42] I think the path forward for that is hotplug cpu support, is it not? [08:42] It's straightforward - just need to map CPU to module, and then fall back to acpi [08:42] can we not do a delayed swsusp? [08:42] so if the lid stays closed for mor ethan 3 minutes, std? [08:42] sabdfl: Yes - a timer on closed lid is practical [08:43] mjg59: what was he working on? loading the right module based on /proc/cpuinfo? [08:43] mdz: Yes [08:43] mdz: yes [08:43] ok, sounds eminently doable for hoary [08:43] can we bounty hotplug cpu support, and stay with sladen's script short term? [08:43] yes [08:43] cool [08:43] " APM support selectable on install for laptops with missing/broken APCI support (BenjaminLong?)" [08:43] Firstly, anything that doesn't support ACPI should have APM loaded [08:44] *shrug* that should be automatic [08:44] At the moment, loads of people are having to add APM to /etc/modules by hand [08:44] sounds like early breakage to me [08:44] There's no real downside to always trying to load APM [08:44] mjg59: i have a lap that has acpi but isnt supported [08:44] so we should start loading apm automatically whenever acpi is not active? [08:44] can't we load acpi, and then apm -- iirc apm will not load if acpi was loaded and worked [08:44] Keybuk: I think so [08:44] mdz: If you try to load APM when acpi /is/ active, it'll just disable itself [08:44] what's the proper userland place to trigger apm loading? [08:44] oh, we have apmd in desktop [08:45] so apmd should start loading apm, it sounds like [08:45] The apm init script could check for a /proc/acpi, and load apm if it's not there [08:45] That's probably the easiest solution [08:45] ok [08:45] who will make the changes? [08:45] Passing acpi=off then results in the right thing happening [08:45] to the apm package? [08:45] mjg59: why do you need the acpi=off ? [08:45] i'll take [08:45] thom: yours [08:45] Keybuk: If you have working APM suspend but no working ACPI suspend, for instance [08:45] mjg59: that's it for the laptop stuff [08:46] mdz: Yup [08:46] Rock [08:46] ok, I assume you don't need that for an APM-only laptop [08:46] mdz: NetworkManager [08:46] Oh, one thing - I have a limited range of hardware for this. Another test machine would be handy [08:46] thom: that's under a separate heading [08:46] do we want to talk about this in relation to laptops, or seperately? (mjg59 has been looking at it, as have I) [08:47] separate, there's a big chunk of bullet points about it [08:47] only if there's a specific feature goal in it other than "package networkmanager and add it to desktop" [08:47] Yeah, it's more useful on laptops than elsewhere but I think it's part of the big network autoconfiguration love thing [08:47] k [08:47] mdz: Thanks [08:47] I'm already thinking that we may need to adjourn and finish tomorrow [08:47] we have another couple of hours, easily [08:47] but let's blaze through as much as we can [08:48] language support [08:48] oh man, another 2am meeting tomorrow would kill me :) [08:48] mdz: one hit is good for me and the others at 2am [08:48] (it's 5am) [08:48] jdub: interfering with breakfast? :p [08:48] mdz: i won't be able to be here tomorrow at this time [08:48] Keybuk: (i got up at 4am yesterday) [08:48] the big part of this bit is the backend infrastructure to pull things out of packages during the build cycle [08:48] which is a generic facility we may use for several things [08:49] during build, not install? [08:49] this is high priority, so someone will be assigned to implement it [08:49] doko: right, during build [08:49] for example [08:49] mdz: 2400UTC? [08:50] part of it is just pulling stuff out [08:50] the basic idea is to create language packs [08:50] by extracting locale-specific data from packages [08:50] the tricky bit is pulling stuff out entirely, and making new packages based on it [08:50] even more trickier is that the stuff must not be put into the original packages any more, right? [08:50] 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] the printing system tied to the locale would be nice [08:50] you'd have to do it somewhere between binary and signing the changes [08:51] 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] Keybuk: you'd do it before even creating the .deb [08:51] mdz: debhelper means lots of patches [08:51] jdub: why? [08:51] jdub: good [08:51] :-) [08:51] hrm, unless it was built in to an existing debhelper module [08:51] jdub: it would be a separate module [08:51] I don't think that something this invasive should be silent as far as the source package is concerned [08:51] dh_builddeb could call it [08:51] mdz: so surely that means lots of patches against modules [08:51] it wouldn't even necessarily have to be debhelper-compatible, but it would be used in the same way [08:51] mdz: and many things don't build-dep debhelper... [08:52] otherwise users will have a hell of a time building packages === Keybuk makes a note to be on holiday at hoary->grumpy merge :p [08:52] jdub: why does a separate module imply patches to existing modules? [08:52] Keybuk: trivial to automate, no? :-) [08:52] mdz: to change debian/rules ? [08:52] mdz: patches to packages [08:52] lamont: packages which use this facility should probably do so explicitly and build-dep [08:52] trying to intrusively hook into the process this way sounds rather insane [08:52] mdz: debian/{rules,control} [08:52] jdub: yes, right [08:52] mdz: so you don't mean _all_ packages, just those with locale compoinets? [08:52] jdub: I was talking debhelper modules [08:52] dunno [08:53] I think this needs a real design discussion [08:53] definitely [08:53] but it also needs someone to take the lead [08:53] lamont: it gets pretty close to all, given gnome (locales separation and .desktop extraction) [08:53] sounds interesting [08:53] jdub: there are lots of unlocalised and don't-need-to-be-localised packages below the desktop [08:54] libraries instantly spring to mind [08:54] yeah [08:54] .desktop extraction is significantly easier [08:54] beacuse it's a tiny amount of data === Keybuk tries to think of an unlocalised library [08:54] we don't need to exclude it from the .deb at all [08:54] wouldn't this be easier with arch-for-everything? [08:54] Kamion: most of gnome libs are localised [08:54] Kamion: not for locale data; it's generated at build time, no? [08:54] are desktop extractions worth to put in an extra package? [08:55] Kamion: lots of this has to be done after build [08:55] mdz: you could generate it from the .po files in the same way, I'd've thought [08:55] ok, I don't want to have the design discussion now [08:55] doko: not for an extra package, for a smart "Add/Remove Programs" app [08:55] mdz: well, if the stuff is extracted into an extra package, it shouldn't be in the original deb any more [08:55] mdz: it's a must-have from sabdfl isn't it? so should be punted to design later [08:55] pitti: (.desktop stuff is a bit different, it'll go elsewhere) [08:55] 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] the question in the table is who will implement it [08:56] has anyone checked if all of these language packs will actually fit on the CD? [08:56] they're going to be absolutely enormous [08:56] Kamion: won't ship all of them [08:56] sabdfl: even one of them will be enormous :) [08:56] that, and they won't have any new data to start [08:56] we'll just be moving things from one package to another [08:56] mdz: I'd like to look at this [08:56] pitti: ok, yours [08:56] Kamion: don't we currently ship *all* translations? [08:56] this is all of french (say) for all desktop apps in one package? [08:56] mdz: (though it will include all of Supported translations too) [08:56] sabdfl: no, see openoffice.org-l10n-* [08:56] about 3MB per language [08:56] Kamion: right [08:57] jdub: I think we can separate supported from desktop [08:57] anyway, trying not to get into it [08:57] sabfl: only for packages which don't have localization packages as extras [08:57] " excellent GDMLanguageIntegration? (selection of login language, selection of system languages)" [08:57] we'll only do this for the desktop package [08:57] s [08:57] we already can select the login language, no? [08:57] yeah [08:57] jdub: can you expand? [08:57] but not guiable [08:57] if generated, yeah [08:58] all three of those sound like bounties [08:58] agreed [08:58] needs a spec, though [08:58] moving on [08:58] there's no way of configuring the GDM language [08:58] what is the target size of the next release? [08:58] Sensebend: single CD [08:58] Sensebend: one CD [08:58] so 650MB or 700MB? [08:59] 650, I think [08:59] but there is a list of languages - if configured - to choose from for your session [08:59] we need a gui way of choosing available languages [08:59] next up, documentation [08:59] any documentation team folks here? [08:59] hornbeck: hi [08:59] agreed jdub [08:59] and add gdm language choice to gdmsetup [09:00] (this should probably be shifted to desktop) [09:00] me also [09:00] python port of yelp -> bounty [09:00] :) [09:00] jdub: and disable it if there is only one lang ? [09:00] mdz: python port of yelp can be dumped for hoary [09:00] even better [09:00] jdub : have you talked with shaunm ? [09:00] yes [09:00] " Network Administrator's Kick Arse Rollout Guide (Re: kickstart)" [09:00] extensively [09:01] mdz: bounty [09:01] " Devhelp for Python development documentation love" [09:01] mdz: bounty, have candidate [09:01] " Ubuntu in a nutshell style booklet (JeffWaugh?)" [09:01] mdz: bounty [09:01] jdub: what should be done? [09:02] we should have more documentation goals [09:02] but we can discuss them later [09:02] for the devhelp thing? [09:02] mdz : any connection to redhet's kickstart? [09:02] the doc team can bring that together [09:02] redhat [09:02] sivang: yes, scroll back about an hour [09:02] Ubutu in a netshell sounds good [09:02] doko: just making python docs appear in devhelp [09:02] moving on [09:02] X.org [09:02] yes [09:02] you are on it already [09:02] yes! to Xorg! [09:02] yes [09:02] Go Team Denmark! etc. [09:02] we are progressing slower than expected [09:02] high priority, get it in as soon as possible, fix what breaks [09:02] fabio and I are both on it [09:03] jdub: let's talk about it later please [09:03] mdz: read above [09:03] fabbione: what's a reasonable target date? [09:03] mdz: we are facing more problems than i expected [09:03] mdz: possibly end of novemeber [09:03] that's late [09:03] yes it is [09:03] mdz: i am working 15 hours/day on it but i can't sustain this rithm forever [09:03] fabbione: it doesn't need to be perfect [09:03] but it needs to be in [09:04] mdz: it doens't even compile [09:04] i have bigger issues than having it perfect [09:04] fabbione: can we provide help in any way? [09:04] what about the work that daniels did back in August? [09:04] are you working from that, or from scratch? [09:04] mdz: we are using all the things we have [09:04] sabdfl: i will soon need (root) access to amd64 and ppc to test portability [09:05] fabbione: you will have it [09:05] fabbione: we have porting boxes available [09:05] sabdfl, mdz: perfect [09:05] there are bits that goes in very fast [09:05] others are a real pain [09:05] fabbione: can we do it in stages? [09:05] there is not much i can do about it [09:05] mdz: ? [09:05] e.g., first transition the X server, and then the libs? [09:05] what you mean by stages? [09:05] fabbione: err, why root? [09:05] mdz: no [09:06] elmo: i need to be able to install packages i build on the fly [09:06] elmo: install stuff [09:06] elmo: no longer a single monolithic package, remember [09:06] elmo: otherwise i need you and/or thom available when i am working on it [09:06] i/we [09:06] current xorg isn't split out, is it? [09:06] mdz: stepping it in will be more work than just crashing the lot in [09:06] jdub: upstream, no. packaging, yes. [09:07] daniels: why? [09:07] splitting it out is less important than getting it in early [09:07] jdub: (why ... ?) [09:07] it is perfectly OK to have a monolithic package [09:07] mdz: it's like the python scripts.. either we get from the beginning or we don't [09:07] that does not make sense to me [09:07] mdz: and we will still face the same problems later [09:07] it is entirely a bulid-time problem [09:07] splitting up a package is much work [09:07] fabbione: but it can be tested in the mean time [09:07] moving binary packages between source packages is easy [09:08] fabbione: or it can be split for grumpy [09:08] once upstream is properly split, we can split along the same lines [09:08] mdz: we need to upgrade from Xfree and it doesn't make it easier [09:08] there are hell of dependencies already [09:08] fabbione: source package layout does not affect upgrades [09:08] there are two big issues here [09:08] - managing the upgrade from xfree [09:08] - testing the software itself === MrTom [~thomas@84.97.17.128] has joined #ubuntu-meeting [09:09] mdz: till a certain point. [09:09] splitting the package (for the packaging's sake) doesn't assist either of those [09:09] trying to split the source packages early is introducing a lot of unnecessarily complexity [09:09] s/rily/ry/ [09:10] mdz: we will only postpone the problem [09:10] we can afford to postpone that problem [09:10] we cannot afford to postone testing X.org in Hoary [09:10] fabbione: postponing until upstream does the split sounds great :) [09:10] ok [09:10] it's your call [09:10] xorg should be one of the first things to hit hoary [09:11] ok, let's delay the split [09:11] agreed [09:11] jdub: it's not like i haven't been working for it [09:11] get something which builds the right binary packages so we can get it in and test [09:11] OK, I have to go to beat people up^W^W^Wpractice peaceful martial arts now [09:11] fabbione: I understand, and I really appreciate your work [09:11] back in two hours or less, if you're still going [09:12] only portion of the patch forwarding costed me 30 hours of work if not more [09:12] upstream split is april/may [09:12] fabbione: we just need to make sure that we focus on the right priorities to make the release [09:12] which will defer our split to grumpy [09:12] fabbione: i grok - the split is a lot of work, and important for different reasons; thank you [09:12] split for grumpy sounds fine [09:12] we have lived with monolithic X for many years [09:12] another 6 months will not kill us [09:13] so let's establish a target for getting X.org uploaded [09:13] well ok.. [09:13] monolitich tree will be [09:13] i am not happy about this decision [09:14] because it will make X drops still complex and slow [09:14] but i have to accept the fact that we have deadlines [09:14] dates will be asap [09:14] fabbione: what are the dates of the X sprint? [09:15] daniels is coming here the 1st of nov until the 14th [09:15] ok [09:15] let's target array CD 3 [09:15] November 15 [09:15] so we should be able to upload something usable for that time [09:15] ok [09:15] awesome! [09:15] " Enhanced GDM" [09:16] mdz: bounty, have candidate [09:16] " Process bugs and feedback from the WartyWarthog? release" [09:16] impossible [09:16] not a feature goal :-) [09:16] " GNOME 2.10" [09:16] seb128: all you [09:16] yeah, no problem [09:16] Easy package install GUI (JeffWaugh?, talking to RossBurton?) [09:16] mdz: bounty, have candidate, almost finished already :) [09:17] Security update notification GUI (MichaelVogt?) [09:17] mvo_: ? [09:17] yes [09:17] mdz: depends on splitting .desktop files [09:17] no problem [09:17] (easy package) [09:17] jdub: right [09:17] not worried about the .desktop files [09:17] sabdfl, mdz, jdub: if there is nothing more for me i would like to go and get some dinner [09:17] with update manager application [09:17] " Fax support via efax or the new gfax?" [09:18] fabbione: thanks very much! [09:18] not really worth a 'goal' [09:18] fabbione: by all means, thank you [09:18] but george farris is getting gfax ready for inclusion in hoary [09:18] sabdfl: no! thanks to you! [09:18] gtk/mono-based [09:18] integrates with print system, etc. [09:18] cya tomorrow [09:18] " Bluetooth GUI, with EddDumbill?'s packages" [09:18] jdub: does it support ISDN devices? [09:18] ends up just being a package inclusion === sabdfl thought fabbione was offering to get me some dinner [09:18] sabdfl: also! [09:18] mdz: edd wants to do those, ends up being a seed change [09:18] sabdfl: welcome to join [09:19] sabdfl: but the new kitchen will be ready in 2 weeks now :-) [09:19] Replace fam with gamin [09:19] mdz: seed change [09:19] sabdfl: i am on microwave and sandwich [09:19] bluetooth will be important for the trls [09:19] jdub: does gamin exist? [09:19] mdz: already in universe [09:19] jdub: that's something we should get in as early as possible [09:19] ok [09:19] so all the crowd is invited to cook pasta at your home? ;) [09:19] i have updated packages beyond warty ready to upload when i can [09:19] jdub: are edd's packages in a state to go in early and get user feedbackl? [09:19] sabdfl: they're in my repo [09:19] " Replace esd with polypaudio" [09:20] another early breakage item [09:20] mdz: seed change [09:20] jdub: oh? [09:20] already in universe [09:20] i would like you to review polypaudio [09:20] jdub: what's polyaudio's state in the gnome universe? === MrTom is now known as MrTom-away [09:20] hmm, I thought we were going for dmix [09:20] rather than a replacement sound daemon [09:20] sabdfl: installable, replaces esound [09:20] mdz: this gives us a sane option [09:20] g2.10 standard? [09:20] sabdfl: oh, sorry [09:20] jdub: esd-compatible or no? [09:20] i'm hoping that it will replace esound in gnome land [09:21] mdz: protocol compatible [09:21] mdz: apps will still use libesd [09:21] jdub: apps linked with libesd? [09:21] ok [09:21] I thought the plan was to get rid of the sound daemon concept entirely [09:21] and let alsa handle it [09:21] mdz: then what multiplexes the sound card? [09:21] alsa specifically won't handle it, and are going the other way and saying you need a multiplexer [09:21] mdz: dmix may be rough to configure automagically, has no config tools, and mean syou have to use libalsa for everything [09:22] Keybuk: dmix handles it [09:22] Keybuk: for libasound apps, at least [09:22] dmix is a multiplexer daemon though? [09:22] libalsa for everything is doable for desktop [09:22] Keybuk: no, part of liba* [09:22] most of it is there already [09:22] mdz: that's lots of bugfixing, dude [09:22] with uuuuugly alsa [09:22] also, alsa api got carrots [09:22] jdub: why is polypaudioi better than esd? [09:22] sabdfl: and in en? [09:23] mdz: much, much saner structure, easier to configure, better for sync sound, latency, etc. [09:23] "the alsa api received less-than-glowing reivews from warty team members who looked at it" [09:23] sabdfl: true [09:23] jdub: as in click, wait, ping! [09:24] mdz: probably a longer discussion involve dhere [09:24] yes [09:24] mdz: but i'd like to start by replacing esound [09:24] if gnome 2.10 is going with polypaudio , we'll start there [09:24] if it's in universe let's get it in asap [09:24] and then look into other stuff [09:24] i think we should communicate very strongly that hoary will spend large amounts of time BROKEN [09:24] polyp is on the early breakage list [09:24] then not fear breaking it [09:24] we're going to break everything at once :-) [09:24] dns-sd via howl (JeffWaugh?) [09:24] jdub: ? [09:24] mdz: gnome-vfs depends change [09:24] there's a huge number of basically newbies who want to move to hoary [09:25] mdz: brings howl into main [09:25] isn't that going to open a port? [09:25] you need to get that message out very very loud [09:25] deb http://break-my-computer-and-stamp-on-the-pieces.ubuntu.com/... :p [09:25] 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] this is going to be breakage of a scale never before seen :-) [09:25] debian has never broken this much at once [09:25] libc5 -> libc6 migration? :p [09:25] jdub: the listening switch sounds like a bounty sort of thing [09:26] mdz: (we could just not install mDNSResponder by default to start with) [09:26] Keybuk: that's one thing [09:26] mdz: agree [09:26] just happened to affect lots of pakcages :-) [09:26] mdz: in which case, have candidate [09:26] mdz : true, but sid's small , harder to notice breakages also stung :) [09:26] mdz: in sufficiently incompatible ways that it wasn't *bootable* for long periods :p [09:26] jdub, mdz, how are we going to resolve the fundamental difference between "rendevous (howl) is awesome" and "don't listen by default"? [09:26] jdub: I'll mark it for further discussion, we'll break it down [09:26] sabdfl: require the user to check a box to turn it on [09:27] sabdfl: put them in a ring and let them fight it out? [09:27] sabdfl: by taking your clothes, tying you to a chair, and... oh, or providing a configuration item to turn it on === sabdfl thinks this sounds just like boarding school [09:27] jdub: can we have a cups configuration next to that? [09:27] Keybuk: i think this ends up being part of our 'services configuration' thingy [09:27] Keybuk: bounty ;) [09:27] the CUPS configuration thing sounds simpler; it should just open up its port when you're looking to add a printer [09:27] Keybuk: plus discussion ;) [09:27] no point in sitting around listening all the time [09:28] improved panel: [09:28] jdub: ? [09:28] mdz: bounty, have candidate [09:28] how does cups know when someone else on the network wants to install a printer? [09:28] accessible by default + include a11y packages? (JeffWaugh?) [09:28] sabdfl: we're talking about the client end of it [09:28] the print server will have a port open all the time [09:28] mdz: I was talking about the server end [09:28] mdz: dump as official goal, leave to community and 'research and development' derivative [09:28] but the thing we disabled was that the client currently needs a port open all the time in order ot browse [09:28] right [09:28] Some kind of reasonable video playback support (Fluendo's DVD Player?) [09:29] so "share printer" makes you a print server, and slightly vulnerable, but it's your option [09:29] mdz: requires further discussion [09:29] User management (e.g., select whether new users should have local device access or not) [09:29] pitti: ? [09:29] mdz: yes :-) [09:29] this is a patch to g-s-t, right? [09:29] that's a pam thing? [09:29] mdz: in gnome system tools? [09:30] pitti: yes [09:30] a small one, I think [09:30] pitti: will you do it? [09:30] mdz: yes [09:30] Remote desktop and rocking terminal support with NX? (TollefFogHeen?) [09:30] (we could bounty the author on that one, too) [09:30] Mithrandir is not here [09:30] anyone know what that's about? [09:30] integrating nomachine nx [09:30] definitely an attractive goal [09:30] in vino [09:30] no, just generally [09:31] not related to vino [09:31] which is some sort of vnc-ish thing? [09:31] low-bandwidth x [09:31] super-low-bandwidth X [09:31] mdz: way faster [09:31] NX is "make my X go really really fast" [09:31] (over a network) [09:31] combined with ltsp, will rock [09:31] yes [09:31] usually used for terminals, rather than sharing current session [09:31] parts of it are free, parts are non-free [09:31] X extension? [09:31] freenx is a 500-line shell script to tie shit together [09:31] no [09:31] or separate protocol? [09:31] special server [09:31] runs a proxying, caching server [09:31] mdz: ... woorks with a goof compression, working with a modem line is very very fast compared to vnc [09:32] what's involved in the feature for hoary? [09:32] separate protocol/server, also interoperates with os x and windows if you buy their product [09:32] packaging the thing? [09:32] yeah [09:32] packaging, yes [09:32] daniels: what parts are non-free, and can it be usefully used as entirely free config? [09:32] packaging + seed [09:33] who will do the work? [09:33] perhaps leave it for tollef to answer [09:33] can do it [09:33] he has already done bits [09:33] sabdfl: i believe you can get an entire freenx setup with free licences [09:33] ok, will check with tollef [09:33] Attempt to standardise on process elevation method throughout GNOME [09:33] knoppix already includes bits of freen [09:33] x [09:33] and the non-free stuff is what? optimised? [09:33] mdz: not convinced it's a useful goal for hoary [09:33] punting [09:34] Thought: Replace Gnome's default palm only sync with MultiSync? for syncing with many more devices? (BenjaminLong?) [09:34] mdz: can do as bounty for grumpy, can think of potential candidate [09:34] whoever wrote that is on crack, multisync doesn't work with evo 2.0, only 1.4 [09:34] sounds like a gnome job, not a hoary job [09:34] sabdfl: i think most of their integration is non-free but there are hacks around that [09:34] multisync isn't ready for integration [09:34] "their"? [09:34] jdub: is it the platform to build on top of though? [09:34] we had proposed a bounty of getting it into shape [09:34] especially if intended as a replacement for current palm foo [09:35] sabdfl: potentially - needs a lot of work [09:35] I looked through multisync briefly and I wasn't impressed [09:35] is it actively maintained? [09:35] several apparently major bugs on the current palm-fu [09:35] the general idea is right, but lots of mess gui and implimentation wise [09:35] Keybuk: I played with evo sync briefly, was so impressed I went back to jpilot [09:35] if there isn't something there to build on, we can't do this for hoary [09:35] sabdfl: not in a very strongly directed fashion ;) [09:35] mdz: i'd say punt [09:35] mdz: people can love it in universe [09:35] ok, pass [09:35] " Better sounds: for example new mail sound, preconfigured correctly" [09:36] sounds like random criticism of the audio theme :-) [09:36] wouldn't want to commit to supporting it [09:36] pity, because PDA stuff is going to be very important [09:36] erm, that was me [09:36] evo sync to palm is an "almost works, sortof" [09:36] sabdfl: something we should do professionally? [09:36] hmm, turning off single sounds in sound themes would be nice [09:36] we need to review every desktop app for sound integration so it all works well together [09:36] sabdfl: I know people who could do very slick sounds for us [09:37] like, thunderbird's new mail sound was just a beep post-install [09:37] mdz: great, ping me separately/ [09:37] yay, someone do a slick sound that sabdfl can use on his damn jabber client ;-P [09:37] xchat's too [09:37] and gaim could do with something a little cuter than the fingers-on-blackboard ring [09:37] "hassole" [09:37] and gossip could do with something louder than its shy little peep [09:37] so this particular item is just about making sound events more integrated and consistent? [09:37] elmo: AWOOGA! [09:37] DIVE! DIVE! [09:37] elmo: "WOO WOO" [09:38] can we do "sounds froma nudist colony"? [09:38] lol [09:38] sabdfl: 'slap!' 'squish!' etc? [09:38] what's the hoary piece of this? [09:38] sabdfl: the "you can't show tits on the radio" theme [09:38] review all desktop apps and make them use sound consistently? [09:38] mdz: yes [09:38] mdz: bounty for sounds, fix badly chosen sound bugs in packages [09:39] sabdfl: just using a consistent set of sounds, or adding sound stuff where it isn't currently present? [09:39] (a) creating a good sound theme [09:39] e.g., stuff which just beeps [09:39] (b) making sure all apps which use sound are correctly integrated to the theme [09:39] so gossip and gaim could use the same sounds [09:39] thunderbird and evo [09:39] for new mail, new im, etc [09:39] ok [09:40] but if an app only supports the console bell, or no sounds at all, we leave it alone? [09:40] basically, file bugs on packages where there are sound theme inconsistencies or unusabilities [09:40] yes [09:40] ok [09:40] no bash sound theme needed [09:40] bounty? [09:40] (a) I have bounty leads [09:40] sabdfl: Gentoo ... it's only a matter of time [09:40] contract for the overall theme, bugs for apps that don't integrate [09:40] "command not found" sound ... [09:40] (b) we need someone to do the review and file bugs [09:40] jdub: ? [09:41] i think once the team knows this is important they will file bugs [09:41] doko: "D'oh!" [09:41] mdz: hrm? [09:41] (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] azeem: what isn't these days? [09:41] hosted at fd.o, don't know how much movement there's been. [09:41] azeem: yeah, opensync is pretty far from ready [09:41] hosted != standard [09:41] ok, so we won't make this an official goal, and just file bugs [09:41] sync punted -> grumpy [09:42] Improved network integration? [09:42] NetworkManager [09:42] thom? [09:42] thom: you're packaging it? [09:42] 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] assuming thom will take that one [09:42] thom was showing it off here last week [09:42] looking pretty good [09:42] needs to be integrated with the broader picture of ifup ifdown [09:42] sorry [09:42] yes [09:42] lots of opportunities for NM integration in various programs [09:43] like evolution, etc. [09:43] thom: all of the sub-goals under that heading have been moved under networkmanager [09:43] thom: is that accurate? [09:43] we don't need anything else? [09:43] some patches have already been written by RH dudes [09:43] what about, e.g., not bringing the interface up at boot? [09:43] mdz: checking, but i think so [09:43] does networkmanager integrate with ifupdow? [09:43] ifupdown? [09:43] jdub: Colin's crusade against the "Network Error" dialog? [09:43] jdub : i.e ? [09:43] Keybuk: yeah (and clark's) [09:43] mdz: not as yet, intend for it to do so soon [09:43] so beyond packaging, there's integration work to do [09:44] thom: will you take that on as well? [09:44] not sure about zeroconf [09:44] mdz : and there's the trashing interfaces file when starting from skreatch no conffiles [09:44] is a good hoary goal [09:44] mdz: yes [09:44] there is fixing to do in networkmanager itself before its ripe to be a core component [09:44] TRLS! Yeah! [09:44] hmm, there's stuff under there that is clearly no tnetworkmanager stuff [09:44] so, zeroconf -> hoary [09:44] Kamion: what about the wireless/installer bit? [09:44] oh, he went away [09:44] Don't ask for WEP / ESSID details during install if they are not really needed [09:44] probably just file a bug about that [09:45] yep [09:45] plus, try the various essid's in of signal strength [09:45] IrDA [09:45] you're skipping the zeroconf bits? [09:45] does someone here care about IrDA? :-) [09:45] that sebastien added? [09:45] pass [09:45] jdub: I thought zeroconf was ->grumpy [09:46] what's the diff between zeroconf and howl? [09:46] I thought howl was an implementation of zeroconf [09:46] but surely there is lots of integration to do [09:46] sabdfl: howl provides implementations of the two sides of zeroconf [09:46] sabdfl: howl is a zeroconf implementation [09:46] once we have howl, there are lots of things to hook it into [09:46] there is a NetworkManager/Howl integration possibility here, for local lan [09:47] is howl out there, and stable? [09:47] you can get network details from zeroconf, which would need to tie into NM [09:47] plus there is the nss issue for .local [09:47] sabdfl: i package it === lamont gets dragged out the door by his wife, back in ~2 hours or so [09:47] sabdfl: it is a dependency of gnome-vfs already [09:47] ok [09:47] that's another reason for new glibc, by the way [09:47] sabdfl: (not in warty) [09:47] useful nameservice reloading stuff [09:47] ok [09:47] so what can we reasonable do with howl/zeroconf for hoary? [09:47] mdz: perhaps we should just talk about zeroconf issues between you, thom and i [09:47] s/able/ably/ [09:47] -> further discussion [09:48] gnome-vfs support is as easy as a build [09:48] tseng: (already covered earlier) [09:48] Support users who don't want to use the restricted component [09:48] sounds like a couple of simple d-i changes [09:48] bug for kamion [09:48] will discuss with colin when he gets back === mvo__ [~egon@suprimo-131.ping.de] has joined #ubuntu-meeting [09:48] ia64 [09:48] T-Bone is not here [09:48] mdz: there are some items under 'irda' that really shouldn't be there [09:49] jdub: good point [09:49] in fact nothing should be under irda [09:49] hp are very kindly sending me an itanium workstation, so i can test d-i === mvo__ is back after network problems [09:49] backing up [09:49] " More robust mechanism for consistently-named network interfaces" [09:49] thom: ? [09:49] that would be doing ifrename right [09:49] i think NM covers that to a certain extent [09:49] oh? [09:50] yeah, it unifies a lot of that stuff [09:50] (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] " Unified DNS configuration (resolvconf or similar)" [09:50] thom: aha [09:50] NM may have an impact on that [09:50] sabdfl: they sent me one as well, some time ago, so no worries there === bob2 is totally on the wrong team [09:50] that should happen through NM ideally [09:51] bob2: you get free trips to sydney for fish'n'chips! [09:51] we'll need to have a networkmanager meeting later [09:51] " Visual traffic indicators on panel network icons (so you can see when NIC or modem is busy)" [09:51] NetworkManager? [09:51] new glibc can notify apps of nameservice changes AIUI [09:51] yeah ;) [09:51] and ugh [09:51] jdub: hah, indeed [09:51] i put that in [09:51] thom: and TZ! :) [09:51] yeah [09:51] network is always busy, evil, distracting flashy icons [09:51] two things: first, the network stuff (wifi etc) should only be visible when it's meaningful [09:51] was that a yeah, networkmanager will do the blinkenlights? [09:52] mdz: yes [09:52] ok [09:52] and second, it's good to have evil, distracting, flashing icons :-)_ [09:52] not by default, please [09:52] NM will do wifi strength, not sure about traffic but it probably is trivial, will look [09:52] but seriously, often want to know if the network is busy or not, it's a common user perceptual reinforcement [09:52] sabdfl: but if you have a windows machine on the network, the light won't stop flashing [09:52] sabdfl: and common irritant ;) [09:52] isn't there already an applet for showing network traffic? I use one. [09:52] because they don't shut up broadcasting shit [09:53] sivang: there is, but NM centralises the configuration, etc. [09:53] jdub: i know which side i'm going to ask us to err on :-) [09:53] siretart: netspeed? === Keybuk wonders what that wailing sound is [09:53] thom: i wouldn't be surprised if some of the gnome applets are fixed up to support NM [09:53] mvo__: ew, no ;) [09:54] thom: can nm appear as a notifier, rather than an applet? [09:54] what about sabdfl's network-applets-only-when-meaningful? [09:54] nm is a notifier [09:54] sabdfl: it is a notification applet [09:54] perfect [09:54] mdz: requires massive, total, unrelenting overhaul of gnome-panel and gnome-applets [09:54] mdz: NM does that [09:54] we need the same for battery [09:54] hahaha [09:54] conflicting answers [09:54] should we also add support for handicapped people? i got some request for the liveCD some time ago === sivang is stunned to see mdz laughing :) [09:54] jdub: what's the right implementation overall? [09:54] mdz: NM provides an API to find out whether you're connected to the network [09:55] should the applets run always, and not display anything unless appropriate? [09:55] s/the/a [09:55] amu: we're followig the outline [09:55] mdz: can't answer that sanely [09:55] jdub: how do we implement what sabdfl proposed? [09:55] mdz: but NM has nicons that appear per-network-interface [09:55] mdz: NM [09:55] 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] jdub: battery [09:55] sound [09:55] other stuff which is not network [09:55] mdz: well, there's battfink which did that to start with [09:56] there is battfink and another notification for batter [09:56] iirc nat did one [09:56] Keybuk: need to be able to run them, and have them display nothing if there's nothing to tell [09:56] can an applet be converted to a notifier easily? [09:56] sabdfl: have chatted about this upstream with the gnome people [09:56] our general feeling is to convert the entire panel to a notification area [09:56] mdz: but in this case, using existing battstat code to run a nicon would be a quick fix [09:56] and make all applets nicons instead of silly bonobo controls [09:56] though jdub wailed a bit, iirc :p [09:56] yay [09:57] Keybuk: no [09:57] the battstat icon is close to perfect for us at the moment [09:57] except that it shows on computers without a battery :-) [09:57] can we move on? [09:57] 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:58] yes [09:58] i don't want to replace ALL the applets, just network and battery in our case [09:58] (was referring to upstream discussion) [09:58] mdz? next? [09:58] you shouldnt make gtik a nicon ;) === mdz snuck off to nibble on some food [09:59] busted [09:59] next up is ia64 [09:59] but T-Bone isn't around === MrTom-away is now known as MrTom [09:59] he's going to run that show, right? [10:00] yes, we're not going to make it an internal problem [10:00] ok [10:00] TestingInfrastructure [10:00] beyond buildd's and no doubt some lamont-lovin# [10:00] huge framework needed here [10:00] bounty material [10:00] needs a detailed spec and some candidates [10:00] this one i think is worth doing internally [10:01] QA ? [10:01] we'll be living with it for a long time [10:01] true, lots of ongoing maintenance probably [10:01] QA indeed [10:01] and it is not something we can just drop out if it doesn't show up [10:01] this could keep someone busy for most of the hoary cycle [10:01] yes [10:01] ok [10:02] " APT package authentication (signed releases, apt 0.6)" [10:02] not a big deal if we do it early [10:02] wish we had some apt hackers on board [10:02] needs answers to a few PKI type questions [10:02] how we'll manage keys, etc. [10:02] mdz: fire away, oo [10:02] b [10:02] I think sabdfl/elmo/I had it pretty much sorted the last time we talked [10:02] mdz: would like to help here [10:03] I'll put apt 0.6 on the early breakagae list [10:03] and get it uploaded ASAP === gro [~gro@u212-239-167-206.adsl.pi.be] has joined #ubuntu-meeting [10:03] mvo__: we'll need auth support in synaptic [10:03] and also in aptitude [10:03] yes, I can do this [10:04] mvo__: aptitude as well? [10:04] mdz: I'll contact daniel first, but I can do a patch if needed I think [10:04] ok [10:04] Splitting/removing files from binary packages we talked about already [10:04] bzip2'ed packages [10:04] Keybuk: ? [10:04] already on dpkg mainline [10:05] binary, anyway [10:05] Keybuk: early breakage [10:05] is it in warty dpkg? [10:05] no [10:05] sabdfl: no. [10:05] fuck [10:05] is that decided? installation slowdown? [10:05] doko: not for all pacakges [10:05] doko: we will have the feature [10:05] bzip2 packages will need to Pre-Depend: dpkg (>= 1.10.24) [10:05] that much is decided [10:05] just stuff like languagepacks [10:05] Keybuk: when can you upload bzip2-enabled dpkg? [10:05] or we could defer bzip packages to grumpy, but get dpkg in [10:06] mdz: when can I upload? [10:06] (suppose it doesn't matter, really) [10:06] Keybuk: as soon as you're done with the merge? [10:06] dpkg seems to have 2 ubuntu revisions [10:06] afaik hoary is open for uploads now [10:06] mdz: yeah, one of those was amd64; the other hasn't been merged upstream [10:07] oh? === jdub tries [10:07] elmo: is my key in the ring again yet? :p [10:07] elmo is importing packages anyway; real uploads should not be far behind [10:07] anyway, that one is Keybuk's [10:07] " Some facility for installation of meaningful package groups? (tasks)" [10:08] Kamion suggested that we resurrect tasksel or a similar feature [10:08] I would like to take this [10:08] some of that will be covered by app-install [10:08] yes, I think it makes sense to integrate the two into one [10:08] yeah, isn't this covered by Ross' gui [10:08] disagree [10:08] the nice slick app installer would likely look something like the win-foss gui [10:08] mdz: only some of the use cases are covered by app-install, not all [10:08] 0609, good night. [10:09] simple, click here to get this app [10:09] daniels: nite, dude [10:09] daniels: night [10:09] tasksel is a different thing [10:09] they wouldn't be presented together [10:09] but backend-wise, there is a lot of overlap [10:09] sabdfl: app-install can also install sets of packages, such as "OpenOffice.org" -> implies a bunch of packages [10:09] sabdfl: is it though? are click here to get "word processor" and "development environment" actually different? === sabdfl reconsiders [10:10] sabdfl: possibly things like "Web Development Environment" -> bunch of things [10:10] Keybuk: "development environment" has never been a useful task :-P [10:10] i'd like to keep that gui tool very basic and simple [10:10] it is :) [10:10] i'll send you sshots [10:10] oh, it should be very basic and simple [10:10] for complex task selection, synaptic should do that [10:10] sorry, aimed at "basic and simple users" and i'm not sure web development environment counts [10:10] honestly, I think that the app-installer and the security update notifier and the simple upgrader should be one app [10:11] sabdfl: "File Server" [10:11] that doesn't mean a complex ui; it could be a few separate UIs [10:11] mdz: agree [10:11] jdub: nfs, samba, ftp??? [10:11] agree with mdz; much simpler for users [10:11] sabdfl: there are lots of simple aggregate examples like these [10:11] sabdfl: but the only cover some of the use cases [10:12] hmm... security update notification will put a blinkenlight in the panel [10:12] that's all [10:12] and when you click on it... [10:12] sabdfl: something needs to happen when you click it :) [10:12] it opens the update maanager [10:12] :) [10:12] 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] like dia [10:12] this should all be effortless and obvious [10:13] and sodipodi (though i think inkscape might make it for hoary) === MrTom is now known as MrTom-away [10:13] whats wrong with inkscape ? [10:13] what's simple upgrader? [10:14] sabdfl: app-install does that delightfully, per spec we talked about at oxford [10:14] sabdfl: one-click system upgrade [10:14] shouldn't that be a simple view on synaptic? [10:14] no [10:14] maybe [10:14] jdub why not/ [10:14] sabdfl: could be, but it's desinged as a python app with synaptic as backend for now [10:15] mvo__: until synaptic is rewritten in python :-) [10:15] sabdfl: it effectively is as I understand it [10:15] sabdfl: because it's so much simpler [10:15] sabdfl: it runs synaptic to do the work [10:15] so it only lists updates and gives you "proceed" [10:15] the frontend is pygtk [10:15] where is this beast? [10:15] mdz: we'll do this later :) [10:15] why not make synaptic simpler? [10:15] sabdfl: sent by mail [10:15] ok [10:15] next [10:15] azeem: because package management is complex; synaptic offers a lot of power [10:16] we should not remove that power, but provide a simpler interface for simpler things [10:16] lm-sensors in main for hardware monitoring [10:16] -> seed change === MrTom-away is now known as MrTom [10:16] did you look at the red-carpet stuff from the ximian usability wizards? [10:16] hmm, and also fixing up the package [10:16] might be simpler [10:16] I thought we excluded lm-sensors 'cos the packaging was crackful? [10:16] to get rid of the 2.4 modules crap [10:16] azeem: it's about as complex as synaptic [10:17] I did a bunch of that for warty already [10:17] the source is in main [10:17] er [10:17] and yet it still build-depends on kernel-source-2.4.27 [10:18] oh, wrong version [10:18] Build-Depends: bison, flex, librrd0-dev, debhelper (>= 4.1.16) [10:18] elmo: yeah, I fixed lm-sensors in ubuntu already [10:18] Binary: sensord, libsensors3, lm-sensors, libsensors-dev [10:18] so it's just a seed change [10:18] " resolvconf in main for managing resolv.conf with multiple networks" [10:18] covered under network magic [10:18] HardwareDatabase [10:18] (cue ominous music) [10:19] another biggie [10:19] yes [10:19] fun though [10:19] cue thom running away and hiding === Keybuk is going to drop out now ... been a 14 hour day [10:19] sabdfl: bounty or no? [10:19] -cheers Keybuk [10:19] Keybuk: night [10:19] mdz: need to figure out who will use it [10:19] - fabbione [10:19] later Keybuk [10:19] - mjg59 [10:20] - herbert [10:20] - sound config [10:20] it should be interesting and doable - i've had some thoughts on the matter which i need to write up [10:20] kernel cant really adapt itself [10:20] that stuff will be very useful for the kernel [10:20] sabdfl: which modules get loaded, acpi v apm, etc [10:20] right [10:20] which devices are present but unrecognized by hotplug [10:21] thom: do you think hal could be extended for such things? Or do you write another db? [10:21] which modules to blacklist [10:21] I think using hal would make a huge project even huger [10:21] pitti: different problem space, i think [10:21] oh, you mean that kind of DB [10:21] thom: hal 0.4.0 has a lot of extensions, though [10:21] I thought you meant ZDHW [10:21] elmo: ZDHW? [10:22] elmo: it'd tie into zero day hardware, i think [10:22] ZeroDayHardWarez [10:22] isn't that the same as the hardware db we're talking about? [10:22] pitti: a web DB? [10:22] mdz: ZDHW is user-orientated [10:22] (well it is in MY mind ;-) === MrTom is now known as MrTom-away [10:22] tho, there's certainly overlap [10:22] can we move ZDHW/this to a different meeting? (is it a hoary goal?) [10:23] I envisioned a client app which would scan the system and ask questions, and upload the information to a central db [10:23] which would also have a web frontend [10:23] but mostly we would trawl it for information [10:23] the web frontend of that = ZDHW? [10:23] mdz: i think so [10:23] could be linked :-) [10:23] yes, let's treat that separately [10:23] same database, different app [10:23] so there are several challenges [10:24] if you're going to ask people to send in info, the db results need to be open [10:24] (a) the design of the database (yay!) [10:24] I think the collection app is the first step [10:24] thom: ok, I think I misunderstood the purpose [10:24] (b) the app that collects the data [10:24] (c) figuring out what the data means [10:24] (d) integrating it with the scripts that autoconf the setup [10:24] like x, sound, network, etc [10:25] that's a lot of work [10:25] yes. [10:25] yes, but we can do it in stages [10:25] first the db + app [10:26] wow, and auto bug reproduction system.... [10:26] and=an [10:26] reproduction ? [10:26] according to what sabdfl just outline, so it sound like. [10:26] I think he means the possibility of finding people with similar hardware to try to reporduce bugs [10:26] which I think is a good application of the system [10:27] the user could volunteer their contact info so that we could ask them for help in testing [10:27] that's an interesting idea [10:27] souds good [10:27] eww, that means storing contact info [10:27] make it a two-way flow [10:27] RUN AWAY [10:27] thom: link to Person :-) [10:27] hahaha [10:27] hardware matchmaker! [10:27] each interested party would list his details on the bugdb, and when the need arise we politely ask him to test [10:27] thom, have you SEEN the database of DOOM recently? [10:27] jdub: your systems are compatible! [10:27] "i love matrox too! see you on friday!" [10:28] this stuff would be very interesting to summarize, too [10:28] "nice cpu's wanna ....'? [10:28] hahah [10:28] sabdfl: no. but i do need to ask, have you looked into UK regs for personal data storage? [10:28] a/s/mhz?!?!?!! [10:28] hah [10:28] thom: hmmm... no [10:28] (the legal stuff, i mean) [10:28] you absolutely utterly need to [10:28] ok [10:29] not sure if we are technically in that part of the uk [10:29] we're going to store that stuff anyway, so that's not a problem specific to the hardware db === jdub attempts to upload to hoary... [10:29] jdub: x.org? [10:29] pre-emptive strike! [10:29] ok, moving on... [10:30] so thom, you're going to take on the hardware db? [10:30] with support from the rest of us, of course [10:30] no, let's have a separate meeting for that [10:30] ok [10:30] mdz: can we have a sep meeting? [10:30] done [10:30] *phew* [10:30] moving on [10:30] Derivative Distributions [10:30] what can we do in the hoary timeframe? [10:31] should have a lot of plumbing in place for christmas [10:31] at least for more adventurous / skillful candidates [10:31] this isn't specifically ubuntu stuff [10:31] unless you want to do the branding crack [10:31] -yes, exctly [10:31] it shouldn't require changes to the distribution itself [10:31] yes to branding crack? or yes to not specifically ubuntu? [10:32] yes to brandability of derivatives [10:32] which touches hoary [10:32] eek [10:32] touches? molests [10:32] easy tiger [10:32] we only deal in mature packages [10:32] consenting? [10:32] able, certainly [10:32] ok, that needs a metting and a spec I think === MrTom-away is now known as MrTom [10:33] yes [10:33] meeting, even [10:33] sabdfl: http://www.informationcommissioner.gov.uk/ for DPA stuff [10:33] compenentized linux made branding possible some time ago, and people seemed to like it [10:33] i'm thinking of making ubuntu-artwork divert a bunch of other art-related branding things [10:33] so you can just replace u-a for all of that [10:33] " Enforce main/universe separation on buildds (LaMontJones?)" [10:33] lamont: all you [10:34] he's still away [10:34] ok [10:34] that's the end of the list! [10:34] yayayay [10:34] well done [10:34] thanks for hanging in there === jdub dances around like kermit [10:34] especially those of little sleep [10:34] 26hrs! [10:35] left out the launchpad integration [10:35] mako: can we get a transcription and summary? [10:35] jdub: V. [10:35] 26hrs in a row? [10:35] doko: that's another meeting [10:35] ?? [10:35] bob2: sprite recharge ;) [10:35] jdub: hah [10:35] 'night jdub :) [10:35] meeting adjourned, thanks everyone === mdz ices his wrists [10:36] thank you [10:36] 4:35, hard core [10:36] thanks mdz === jdub goes to pay attention to pipka [10:36] g'night [10:36] 'night thom [10:36] cheers all, thanks mdz [10:36] night [10:36] thanks for the moderation [10:36] 'night everybody [10:36] I'll write up my notes for the wiki [10:36] thanks mdz [10:37] night thom [10:37] thanks for enabling us to participate :) [10:37] mdz : you're gonna do this on the new wiki? [10:37] sivang: yes [10:37] a bit later, need a break [10:37] ah ofcourse [10:37] :) [10:38] new wiki hurts my brain :| [10:38] jdub: i'm thinking we should keep moin format as recommended default [10:38] sabdfl: what about the tables? [10:39] inline html, or...? [10:39] jdub: we got tables in [10:39] i don't like the moin format but we can handle it now [10:39] (moing table format) [10:39] oh! [10:39] cool [10:39] 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:40] sivang yes please put it in the agenda [10:40] mdz: please put my name to the TestingInfrastructure thing, at least as a co-worker [10:40] sabdfl : ok np. I've already added to it [10:43] mdz: yes === maskie [~maskie@196-30-111-250.uudial.uunet.co.za] has left #ubuntu-meeting ["Leaving"] [10:55] night all [11:00] mdz: restricted/installer is trivial, it's a "file a bug and wait for Kamion to have a spare hour" routine [11:01] mdz: TestingInfrastructure> have I already massively pimped joeyh's d-i autoinstall framework at you? it's awesome [11:02] mdz: he's been doing full CD tests out of cron lately [11:02] works with iLO, which IIRC we have on some of our boxes === MrTom [~thomas@84.97.17.128] has left #ubuntu-meeting ["Leaving"] [11:13] doko: ok [11:13] mako: thanks [11:13] Kamion: sounds very interesting, where can we get more info/ [11:14] mdz: svn://svn.debian.org/d-i/people/joeyh/autoinstall/ is probably the best place for now === 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"] [11:45] Kamion: we have iLO on the new itaniums, and please go ahead on the restricted-free option [11:47] nah, we don't, iLO is an x86 server only option [11:47] the Itaniums have something much less fun, called "MP" [11:48] however joeyh also does have something going on ia64, may not be with iLO [11:48] I think it's just netboot over serial console === tseng [~tseng@thegrebs.com] has left #ubuntu-meeting []