=== sm [~simon@lsanca1.ar5-4.15.64.42.lsanca1.dsl-verizon.net] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === cenerentola [~cenerento@84.222.38.54] has joined #ubuntu-meeting === skyrider [~skyrider@kid.stu.cn.ua] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has left #ubuntu-meeting [] === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === ..[topic/#ubuntu-meeting:pitti] : Tuesday 16 November 2004 at 16:00 UTC: Technical Board meeting === doko [doko@dsl-084-057-097-131.arcor-ip.net] has joined #ubuntu-meeting === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting === sivang [~sivang@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting === eklm [doko@dsl-082-082-214-225.arcor-ip.net] has joined #ubuntu-meeting === doko [doko@dsl-082-082-214-225.arcor-ip.net] has joined #ubuntu-meeting === Keybuk [scott@descent.netsplit.com] has joined #ubuntu-meeting === cenerentola [~cenerento@84.222.39.231] has joined #ubuntu-meeting === Gwildor_ [~onceagain@adsl-68-249-245-156.dsl.sfldmi.ameritech.net] has joined #ubuntu-meeting === daniels [~daniels@george.kkhotels.co.uk] has joined #ubuntu-meeting === egli [~egli@gate.wyona.com] has joined #ubuntu-meeting === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting === seb128 [~seb128@ANancy-151-1-23-252.w83-194.abo.wanadoo.fr] has joined #ubuntu-meeting [04:55] Quick question: are the logs (or a synopsis) from the last tech meeting available someplace? [04:56] smurfix: people.ubuntu.com/~fabbione/irclogs/ [04:56] a more official url needs to be done [04:56] so do not bookmark it [04:59] OK. (NB, official logs should probably have UTC timestamps.) === hornbeck [~hornbeck@adsl-69-155-172-150.dsl.okcyok.swbell.net] has joined #ubuntu-meeting === amu [~amu@195.71.9.198] has joined #ubuntu-meeting [05:00] smurfix: i am not going to change date and time on my server for that :-) [05:00] moins [05:00] Hi folks [05:00] fabbione: env TZ=UTC should be sufficient. [05:00] afternoon pitti [05:00] and the others too :) [05:01] afternoon folks [05:01] seb128: (wishlist) temporarily turn off "typing break" feature [05:01] yeah :) [05:01] ok, let's get started [05:02] saomebody ping sabdfl? [05:02] done [05:02] heh, good point :p === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting === ironwolf [~ironwolf@c-24-6-251-226.client.comcast.net] has joined #ubuntu-meeting [05:02] elmo? [05:02] is baby jesus in attendance also? [05:02] ODB? === ..[topic/#ubuntu-meeting:Keybuk] : Tuesday 16 November 2004 at 16:00 UTC: Technical Board meeting -- https://www.ubuntulinux.org/wiki/TechnicalBoardAgenda === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [05:03] Hi silbs === lupus_ [~lupus@kn-ivl-2.kuleuven.net] has joined #ubuntu-meeting [05:03] hi pitti [05:03] silbs, lulu: throw a bread roll or something at Mark, would ya? :p === haggai [~halls@i-83-67-20-196.freedom2surf.net] has joined #ubuntu-meeting [05:04] Keybuk: or a jellybean === mako waves [05:04] hey mako === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [05:04] hi all [05:04] keybuk: thrown [05:04] Hi [05:05] Missing agenda item: confirmation of new maintainers? *cough* ;-) === lamont_r [~lamont@adsl-69-107-92-115.dsl.pltn13.pacbell.net] has joined #ubuntu-meeting [05:05] have there been additional new maintainers since the last community meeting? [05:05] smurfix: you mean the ones that were approved by the CC last week? [05:05] it's been done on the CC meeting last time, with TB attandent . === magneto [~magneto@68.184.116.72] has joined #ubuntu-meeting === Henri1 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting [05:06] ok, so I'm going to act as emergency-holographic-mdz while he's sunning himself on some beach somewhere :) === plovs [~plovs@62.84.21.44] has joined #ubuntu-meeting [05:06] Ah, OK. Mark wrote that that still needs to happen AFAIR. [05:07] those maintainers that want to be on the keyring for uploads do need to be approved by the TB === tseng [~tseng@thegrebs.com] has joined #ubuntu-meeting [05:07] because they need to be comfortable with the gpg key management security [05:07] sabdfl: that would be me then [05:07] sabdfl: do we want to add that to the agenda for this meeting? [05:07] Keybuk: yes please [05:08] smurfix: you're already a DD right? [05:08] sabdfl: Yep [05:08] ok, then np [05:08] as long as the rest of the TB concurs :-) === elmo [~james@83.216.141.215] has joined #ubuntu-meeting [05:08] sabdfl: I do, certainly. [05:08] damn timezones [05:09] do we have a list of the others that need confirming? [05:09] Keybuk: do we have the full TB? [05:10] enrico said he would like upload, so he needs to be confirmed [05:10] I would like upload [05:10] for future sake [05:10] hornbeck: how comfortable are you with gpg? === amu too [05:10] sabdfl: mdz is on holiday, he was around about 10 minutes ago for just 5-10 more minutes [05:10] getting real comfortable === haggai puts up hand too [05:11] haggai: have you been approved by the CC last week? [05:11] sabdfl: no [05:11] then start there :-) [05:11] okey dokey [05:12] sabdfl: the list you posted on the 9th Nov was: [05:12] - Thibaut Varenet [05:12] - Alexander Poslavsky [05:12] - John Hornbeck [05:12] - Matthias Urlichs === ChrisH [~chaas@gw.workaround.org] has joined #ubuntu-meeting [05:12] and enrico, behind the scenes === jdz` [~jdz@chpau.oxfordnetworks.net] has joined #ubuntu-meeting === plovs doesn't need upload for now, later maybe [05:13] hornbeck: doyou have a gpg key that is widely signed? [05:13] not yet, I can hold on upload right now [05:13] hornbeck: ok, i think so [05:13] thats fine [05:13] upload via enrico for the moment, if you are coming to the conf it will be a good way to get your key trusted [05:14] ok keybuk, take it away [05:14] we should definitely ensure we have a trusted path to anyone whose key we put in the keyring [05:14] Keybuk: dude, we had problems doing that for employees [05:15] (not that I'm saying we shouldn't, but you should be aware it's going to be painful for some folks) [05:15] we can use formal procedures, notarisation etc to get it done [05:15] trust path doesn't imply direct, necessarily [05:15] trusted path can be "we have a signed contract and pay them" :) [05:15] you could use debian wot, e.g. [05:15] "we know where you live" [05:15] daniels: I was using the debian wot and indirect paths [05:15] elmo: making the exceptions higly visible would be a good way of dealing with the few that are exceptions... [05:15] elmo: i think you are the only one not signing keys yet :P [05:15] we'll get it done for anyone that really needs it, using notaries etc [05:16] let's get going on today's agenda, keybuk leads [05:16] elmo: oh, wow [05:16] yup, I'm going to move the ongoing merge feedback to the end to give Colin time to get back [05:16] so first up is pitti and splitting out language packs [05:16] Yes [05:17] I already started working on firefox and thunderbird [05:17] OO.o is cleared, too [05:17] the remaining question is whether we really want to extract gettext po files [05:17] pro: saves some installed space [05:18] con: heavily intrusive, needs rebuild of whole archive [05:18] this is taking the translation data out of the application packages and into a single .deb (for those not following this :p) [05:18] con: needs debhelper change and makes inconsistencies easy [05:18] Keybuk: right, that was an idea [05:18] however, I think the main problem we really have is missing translations for OO.o, Firefox and so on [05:18] pitti: i very much want this as a hoary feature, fwiw [05:19] sabdfl: we will have language packs for above apps in any case [05:19] that's an orthogonal issue, which rosetta aims to solve [05:19] do we want to leave any languages in the original packages? [05:19] or should they all be split into language packs? [05:19] Keybuk: you mean gettext? [05:19] pitti: I mean in general [05:19] is this going to require source changes? [05:19] Keybuk: yes, for packages outside of the desktop list [05:19] for every source package? [05:19] elmo: for the base and desktop packages [05:19] for now I think the advantages we would get from extracting gettext files don't outweigh the cons [05:20] sabdfl: that's ugly before the infrastructure is there... [05:20] legislatura danese [05:20] ops [05:20] "infrastructure" in this case would mean a modified debhelper and a handful of packages which require manual changes [05:20] pitti: is there any particular reason why extracting the gettext files is any harder/uglier than Mozilla/OOo's translations ... other than sheer weight of numbers? [05:20] sabdfl: that's going to take the merge work from minimal to... lots [05:21] Keybuk: yes [05:21] can you elaborate? [05:21] Keybuk: because for OO.o and mozilla we already have separate locale debs [05:21] Keybuk: thesep rograms don't use gettext [05:21] Keybuk: e. g. Mozilla uses these xpi files [05:21] this is the sort of "do it across the whole archive" thing that we can do [05:21] and OOo/moz already have separate .debs in Debian [05:21] so for OO.o and mozilla it's just a matter of a metapackage that depends on e. g. mozilla-firefox-locale-de [05:22] 'm willing to hire a team just to handle this sort of stuff [05:22] we need to make it as efficient as possible [05:22] sabdfl: but what's the real benefit of having extracted gettext files? [05:22] pitti: lay the groundwork for rosetta, make the languages more concrete and visible [05:22] the user won't notice whether foo.deb or language-support-XX.deb shipped a gettext template [05:22] sabdfl: yes, but it's not a once off cost - there's the ongoing merge cost [05:22] ok, my understanding of language-pack-$LANG is that it basically contains /usr/share/locale/$LANG/LC_MESSAGES -- with a file for each package in base and desktop [05:23] is that the basic idea? [05:23] yes [05:23] elmo: we are going to get to the point where we have touched every package in main, and have to sustain the merge [05:23] adn the original debs don't contain the files any more [05:23] but it's not only a merging problem [05:23] what about doing the change in Debian proper too? [05:23] we have to update the language pack for each and every upload (including seurity updates) [05:24] the "merging problem" is just a change to debian/rules binary in an area that Debian probably don't change too much -- so I'm not *overly* worried about that [05:24] has anyone found out how big language-pack-$LANG will be? [05:24] we will continue to update the language pack after release [05:24] and the problem is that the language pack would depend on _all_ other packages with a particular version [05:24] Why not pull the locale files out of the .deb files after the fact? No more merge problems. [05:24] so that new translations come into use [05:24] without requiring code updates [05:24] sabdfl: ?? [05:24] elmo: my /usr/share/locale is 169 MB [05:24] elmo: but this contains _all_ translations, [05:24] wow, mdz's going to be so sorry he missed this meeting [05:24] so I think a particular language pack will be quite small [05:25] about 10 MB or so [05:25] pitti: so we have, best case, 169MB of unrsyncable debs that change every day? woot [05:25] pitti: can you see how many languages in average? [05:25] descent scott% ls -l ca_data.tar.* [05:25] -rw-rw-r-- 1 scott scott 1.7M 2004-11-16 16:24 ca_data.tar.bz2 [05:25] -rw-rw-r-- 1 scott scott 1.9M 2004-11-16 16:24 ca_data.tar.gz [05:25] fabbione: what do you mean` [05:25] that's using Catalan (I think) [05:25] pitti: see how big is one language. [05:26] fabbione: 100 directories, 161 MB [05:26] fabbione: that makes 1.6 MB on average for a language [05:26] fabbione: of course popular ones are much bigger [05:26] sabdfl: where are we going to put the updated language packs? hoary itself, hoary-security or hoary-updates ? [05:26] sorry, what's the big gain in this? [05:26] other than being able to update translations independently [05:26] elmo: I don't understand either [05:26] elmo: 160MB more place on the CD for other packages? [05:27] doko: how does that work? [05:27] sabdfl: but what is the point in updating lang packages after a release? i don't think we are going to change strings after... [05:27] it really makes an user-visible difference for langpacks for OO.o and firefox/thunderbird, but not for gettext [05:27] doko: unless we have per lang CDs? [05:27] fabbione: strings don't change, but we get more translations [05:27] doko: no, because we have to ship the translations anyway [05:27] so you can update each week, and your apps become "more translated" [05:27] sabdfl: at an insane cost for mirrors [05:27] and you are only downloading the new strings for languages you care about [05:27] fabbione: security updates might touch translations [05:27] sabdfl: from my experience about debconf translation, we will get them for new releases of the packages. [05:28] real quick, can I post here, or just "listen"? [05:28] so, say, I update ed and a translation changes, instead of the 20K ed.deb changing, a (best case) 2M .deb language package changes for n languages [05:28] pitti: yes that is a very special case that will push hell of an update [05:28] Gwildor_: feel free to jump in if you've got something to contribute :) be on topic, there's time at the end for any other business [05:28] fabbione: luckily it shouldn't occur very often [05:28] I have a proposal [05:28] for Hoary, we confine the language packs to OO.o and Mozilla stuff [05:29] then we can wait for Rosetta and try out whether separating the translations really brings benefit [05:29] elmo: another reason: if the catalan translation is updated, you won't even download 20k? [05:29] another point: as soon as we have langpacks, our packages will conflict to every debian pacakge [05:29] doko: _I_ won't, but the mirrors will download 2Mbxn (where n is, what conservatively? 50?) [05:29] maybe make a language repo?, being a synaptic user, it is quite annoying searching thru language packs? [05:29] and worse, users cannot compile packages on their own [05:30] pitti: personally I don't think that's an exciting proposal ... those packs are already separated, so it's actually not changing anything from warty -> hoary is it? [05:30] it's not worth saving our users 20k, if it costs our mirrors 160Mb [05:30] pitti: no, just Replaces [05:30] Keybuk: it makes a difference [05:30] Keybuk: right now, non-english users don't get translations for firefox/ooo/thunderbird [05:31] Keybuk: but the langpack can be integrated into d-i, so this would install all relevant stuff automatically [05:31] pitti: it's a good start [05:31] elmo: is the issue that mirrors won't like the rapid changing languagepack packages? [05:31] not being able to compile packages on one's own is a major drawback [05:31] talking of d-i ... how are we handling debian/po with this? are we splitting out the debconf translations as well? [05:31] pitti: im sure we can solve that one [05:31] sabdfl: how? [05:32] sabdfl: the user would be required to take our build infrastructure [05:32] sabdfl: no, the issue is that by congealing language packs from hundreds of different source packages into one deb, you've massively increased the mirror cost for a change in any one of those source packages [05:32] sabdfl: and generate his own language pack [05:32] pitti: make it so a normal build leaves the translations in [05:32] like, on an order of magnitude increased [05:32] sabdfl: this does not work [05:32] sabdfl: you couldn't install the normal build -- it'd conflict with the language pack [05:32] sabdfl: because the newly compiled package and the language pack would conflict filewise [05:32] sabdfl: dpkg will refuse to install the locally built package [05:33] no debian packages, no external apt sources any more [05:33] for a change that an user does not actually see [05:33] and you get a lot of extra differences between debian<->ubuntu package file lists [05:33] he will get translations either way [05:34] We should ask ourselves a question: what is our actual problem? [05:34] providing the users with apps in his language? [05:34] pitti: (a) we cannot update translations after release without updating packages [05:34] sabdfl: but you have to update the language pack [05:35] pitti: (b) we put a lot of translations on the cd that will never be used, languagepacks would be more efficient [05:35] sabdfl: update or add new? Adding new is probably easier to do than update [05:35] sabdfl: so you want to throw out translations for (b)? [05:35] what about making an additional language pack and divert the files, which the language pack updates? [05:35] pitti: (c) we want "install a new language" to be a more concrete action, that updates various bits of the system config accordingly [05:35] that way, local build can still be installed. [05:35] (c) is not even necessary now [05:36] doko: iirc dpkg-divert goes on crack in certain situation. (there is something about it on debian bts related to xfree86) [05:36] yes, (c) is necessary. I'd like, for example, that installing a new language pack asks if you want the GDM login to switch to that language, and make that the system default, etc [05:36] fabbione: that's Branden being on crack (shock) [05:36] but it is a dpkg-divert bug [05:36] AFAICS (b) is the only real reason [05:36] Keybuk: eheh [05:36] pitti: (a) is just as important [05:37] with rosetta, we will get a lot of translations after a release [05:37] and we want to be able to get those translations to users for that release, as well as later ones [05:37] new translations or updates of existing languages? [05:37] sabdfl: but whether you update language packs or normal packages does not really make a difference [05:37] my concern with updating translations after a release is that updated translations can introduce security holes [05:37] haggai: both [05:37] pitti: it's a much smaller update for the user [05:37] right [05:38] and it changes no functionality, so it could go out with our daily/weekly post-release updates [05:38] but as Keybuk say, an error in a translation can easily make a buffer overflow [05:38] so each week i download 2-10 mb and i get smarter translations [05:38] so translations have to be reviewed very carefully if we put them into stable reelases [05:38] sabdfl: at a quite simply unbearable cost to mirrors [05:38] using dpkg-divert increases the disk space on the user's disk, but that shouldn't be such an issue. provided that dpkg-divert works reliably. [05:39] elmo: how many mirrors cover warty-security? [05:39] I actually like the idea with diverting changed files in the language pack [05:39] seriously, I can't overstate this enough. my /usr/share/locale/ is 223Mb - you're proposing a 223Mb hit PER DAY [05:39] doko: the other option is to have an /usr/share/language-pack alternate locale heirachy [05:39] elmo: are separate ftp areas for language packs a solution? [05:39] and bear in mind that's "katie" days, i.e. in reality ==> half an hour [05:39] sabdfl: any that have the archive [05:40] elmo: only during the development period [05:40] sabdfl: I doubt that it is a smaller update. Right now, you download only the translations for programs you have installed; with a langpack, you have to download translations for _all_ packages [05:40] keybuk: ant to search this one first? that would mean _one_ change in gettext? [05:40] sabdfl: err, even when we're frozen, there was easily an update of a desktop package once a day (real day) [05:40] sabdfl: what do you think about the diversion idea? Itsounds nice to me [05:40] sabdfl: and just one source package is enough to incure the 223Mb hit [05:41] elmo: after release, there are no string changes, or very, very few [05:41] so it's only new translations that will be downloaded [05:41] sabdfl: but dude, we develop for what? 2/3 months? [05:41] pitti: i don't know enough about the diversion mechanism, how does it work? [05:41] it's just not sane that a souce package with string changes ==> 223Mb hit [05:41] A source package. one of them. any one of them (in desktop). [05:42] sabdfl: it basically means that a package can say "hey, I have a replacement for this file X in this other deb" [05:42] sabdfl: so the langpack would only divert the files it actually changed [05:42] sabdfl: we could leave our current debs intact [05:42] sabdfl: and after the release, the langpack would "replace" (divert) just the changed .po files [05:42] and the language pack would become incrementally larger after release adding or updating translations? [05:42] pitti: does that scale to the numbers of files we are dealing with? [05:43] how is this even going to work anyway - what's going to update the language pack? [05:43] pitti: keybuk's proposal about the alternative hierarchy boils down to the same thing: don't modify the source package, but ship additional language files. [05:43] what happens with concurrent builds on buildds? [05:43] sabdfl: I don't really know [05:43] sabdfl: yeah, you can dpkg-divert your entire file system quite happily [05:43] or is it taken out-of-bounds of the build-a-source package process? [05:43] that would mean that people can't enhance their self-built package with new translated strings though [05:43] well KDE handle in such a way they deliver a big packages with all translation in it, and deliver kind of diff to updates [05:43] Keybuk: is it easy to have a second hierarchy globally? [05:43] pitti: no idea. [05:43] Keybuk: or does it require a change of all packages? [05:44] Keybuk: it seems that only a gettext change is required, though [05:44] amu: yah, but KDE doesn't deal with binary packages [05:44] elmo: is it _one_ language pack source package, or one for each language? [05:44] amu: you don't push a new kde-i18n binary every time someone updates kdeextragear-1 [05:44] you'd have to be wary of packages that statically linked an in-source libintl :-/ [05:44] doko: AFAIK they're talking about one for each "language" [05:44] doko: one for each language [05:45] Keybuk: oh, right. This is hard to catch... [05:45] one for each source package, would actually solve the mirror problem, it just brings back the Packages problem back a little bit [05:45] it would also solve the concurrent-buildds issue [05:46] i'm not sure we can safely multiple the number of packages by 200 :-) [05:46] elmo: would having language-pack only contain new and updated translations since the last release of the source package satisfy the mirror hit? You'd only be updating it when you got new stuff in, and it'd not contain the full set [05:46] daniels: you can package only the diffs compared to the first version, with a release you merge all to a new big one [05:46] elmo: i weep on behalf of dialup [05:46] Keybuk: how on earth would that work? [05:46] amu: how does that actually work? [05:46] elmo: you'd just update language-pack-XX when you got new translations in, and not bother with the source package [05:47] daniels: see Keybuk [05:48] if you update a package that has a file that has been diverted by another package, what does it do with the new version of it's diverted file? [05:48] sabdfl: dude, if it's really 200 languages, that's more like 400Mb hit then ... [05:48] sabdfl: puts it in the diverted place [05:48] elmo: many languages have very few translations [05:48] with rosetta, we hope that will change [05:48] Keybuk: sorry, I still don't get it? the problem is you've got an unrsyncable (even ignoring the filename change) .deb which is 2mb, x 200 [05:48] Keybuk: I don't see how anything you've said could help with that? [05:48] if we get to the point that it is 400MB of translations, then this will be a necessity in any event, so deal with it :-) [05:49] elmo: no, it starts off 0 x 200 ... and only grows in size if new translations come in [05:49] sabdfl: no, dude, it's NOT [05:49] sabdfl: if evolution gets new strings, the hit to mirrors is evolution [05:49] sabdfl: with language packages, the hit is 400Mb [05:49] elmo: I think Mark's point is that 400MB of translations doesn't fit will on a CD :p [05:49] even in 2015, evolution won't be 400Mb big [05:49] (+ evolution) [05:49] elmo: if every package is fully translated to every language, the size of the translations in all the packages will be 2/3 of the CD [05:50] so we won't be able to put the packages for desktop on the cd [05:50] sabdfl: i think we should approach this problem in a different way [05:50] instead of changing the build system for all package [05:50] we should find a way to strip languages for CDs [05:50] sabdfl: so we split them out, but we can't split them out into some monstrous "I come from all desktop sources" mirror-killer package [05:50] fabbione: you mean, repack the .debs? [05:50] fabbione: this should be easy [05:50] elmo: what would you suggest that wouldn't kill the mirrors? [05:50] pitti: only to build the CD [05:51] sabdfl: the we have that many translatios, we'll DVD's ;) [05:51] fabbione: but what do you do with the stripped files then? [05:51] pitti: at that point we can have CD English/Itaglish/Italian [05:51] fabbione: ah, I see [05:51] pitti: trash them. [05:51] Keybuk: don't do this? seriously. I don't know of a way to do this that wouldn't kill them. the fundamental flaw is congealing that many sources together [05:51] fabbione: APT gets its freaky on when it has two packages of the same version (one installed, one in the archive) with different installed-size [05:51] fabbione: you delete all but one language [05:51] sabdfl: the time we have that many translatios, we'll DVD's ;) [05:51] pitti: the packages in the archive will not be altered [05:51] fabbione: good idea [05:51] fabbione: is it ok for the debs on the cd to be different to the debs you build, or the debs in the archive? [05:51] elmo: we're going to have to accept we can't fit all the translations on the CD ... so what do we do? [05:51] pitti: only the one that lands on the CD [05:52] Keybuk: yeah. name/version/architecture tuple needs to uniquely identify the file [05:52] Keybuk: strip them out, oo.o/mozilla style? [05:52] sabdfl: at that point yes. because if i reinstall from the mirror there will be no conflict [05:52] sabdfl: the language file will belong to the same package [05:52] maybe with with big language groupings somehow to reduce the number of packages [05:52] elmo: and land up with 200x8000 packages? [05:52] fabbione: we could also think about only leaving the most popular 10 [05:52] elmo: so ~200,000 new source packages is better than 200 source packages? [05:52] pitti: that's the plan [05:52] fabbione: this should be fairly flexible [05:53] sabdfl: seriously, that's a saner alternative than killing mirrors - if we have to put resources into fixing apt/dpkg/katie/whatever to cope, we can at least do that. we can't ask mirrors to take 400Mb for the team every dat [05:53] fabbione: no, it's really not ok. apt will randomly reinstall some, and not others [05:53] fabbione: that's the reason that you have to flush the cache during the arch bootstrap process, and part of why mix-n-match with debian repositories is bad [05:53] Keybuk: bad luck. how gets updates, gets all the package [05:53] elmo: i agree with you, i was thinking we could manage the build / strip process so that the bullet would not be necessary [05:53] s/how/who [05:54] fabbione: after an install, the first net update could take a 600MB hit! [05:54] Keybuk: if the 200 source packages change every day and total hit is 400Mb, yes [05:54] back [05:54] Keybuk: teach apt-get/dpkg not to do so? [05:54] Keybuk: in my experience it just throws a fit (but that's with the old package in the cache, not fetching...) [05:55] lamont_r: stick Debian + Ubuntu in your sources.list -- it'll randomly swap packages around every update between the two archives :( [05:55] anyway, that's getting slightly off-topic [05:55] kewl [05:55] can I propose an alternative? [05:55] so: a language-pack per language kills the mirrors, as it needs to be updated for every new source upload [05:55] elmo: yes of course [05:55] elmo: please :) [05:56] let's devote all our resources into converting the world to use a single common language!!!!!!!!!1! [05:56] \o/ [05:56] ahahha [05:56] ouch [05:56] a language-pack per source per language kills the Packages file, as it introduces roughly a quarter of a million packages [05:56] elmo: +1 :-) [05:56] elmo: I thought that was tried with esperanto [05:56] elmo: can we pick french ? :) === seb128 runs [05:56] Keybuk: the packages file alone would fill the cd [05:56] pitti: not to mention you needing a few gig of memory for APT to parse it [05:57] seb128: istr the french gov't would require that. :-) [05:57] Keybuk: in 10+ years of the GNU translation project they've managed about 30 languages total, maybe average 10 a package [05:57] Keybuk: and a week to download [05:57] Keybuk: I don't think we're going to surpass that by orders of magnitude any time soon [05:57] so maybe we don't use Packages for this - maybe we use something lighter weight? [05:57] keybuk: could you work around that by adding a new section main-de, universe-de ? [05:58] we could download translations from rosetta directly to /var/share/locale [05:58] without packages [05:58] i'm not opposed to a separate infrastructure of per-package, per-language files, coordinated through a new index [05:58] How about one package each week containing diffs for all languages each week and a small utility to patch them in? Would that break the apps? It would only be 13 packages in 6 months and they would be quite small. [05:58] it's a lot of work though, on new infrastructure [05:59] I don't think there's anything the tech-board can decide on today [05:59] This needs a lot more discussion and some more concrete proposals we can pro/con [05:59] One diff from the Gold frelease and one from each relevant security update. [05:59] this discussion should be wrote up in a pro/con list [06:00] pitti: are you up for doing that? [06:00] You don't even need an index, minimally; just try to download ftp://wherever/LANG/PACKAGE.deb... but I agree with keybuk [06:00] I can do this [06:00] unfortunately I forgot to turn on logging, but fabbione's logs should do [06:00] smurfix: that doesn't scale if you have 1000s of packages installed [06:00] I write that up to u-devel [06:00] smurfix: need versioning though [06:01] haggai: it's not worse than the existing /pool. [06:01] pitti: excellent. hopefully we'll be able to get some proposals for solving this, and then if no consensus about which one's the best appears, it can come before the board again. [06:01] Keybuk: I also think we should digest this discussion a bit [06:01] Kamion: true, I sortof included the version in PACKAGE. [06:01] smurfix: you don't currently try to download a file for every installed package on your system [06:01] Keybuk: a pro/con table will help to device [06:02] Keybuk: s/device/decide/ [06:02] ok, moving on. [06:02] fabbione: sparc port status? [06:02] Keybuk: next item? BTW, you forgot the first one [06:02] yup [06:02] during the last weeks i was kind bored waiting for Xorg to compile [06:03] so i started porting Ubuntu to sparc [06:03] right now i am at stage0 of the port [06:03] half way trough main [06:03] and it is going pretty well [06:03] very few failures [06:03] elmo: can you get me some quotes on a sparc port box and 3 buildd's? [06:03] there were a few requests for this port on some mailing lists [06:03] sabdfl: new? [06:04] what kinds of sparc is this targetted at? Low end, or shiny ultras? 32-bit or 64-bit? [06:04] sabdfl: i gave you already a good number to phone for sparc hw [06:04] elmo: your judgment, bang for buck but make sure they can keep up [06:04] fabbione: please send it to me [06:04] elmo: i will [06:04] sabdfl: ok [06:04] Keybuk: sparc64. i don't have any sparc32 [06:04] but before asking for official buildd's [06:04] i have a few questions to raise to all of you [06:05] first we need a way to measure the use of one unofficial port [06:05] in order to decide if it is really worth to buy buildd's or not [06:05] and what i was thinking about [06:05] was to have one machine at the datacenter [06:05] fabbione, you did build everything for sparc64? [06:06] that can act as temporary archive for unofficial port in "evaluaton" status [06:06] fabbione: you mean, we should offer to host any unofficial port, then decide based on downloads? [06:06] sounds good [06:06] doko: as i wrote above i am half way trough main' [06:06] sabdfl: exactly [06:06] sabdfl: i don't see any point in wasting money if the port can't keep up [06:06] "port" meaning also porters behind it [06:07] clearly i am doing this on my spare time and not company time [06:07] fabbione: no, I mean sparc32 or sparc64 ? [06:07] fabbione: are there people besides you interested in contributing development effort? [06:07] so i might get sucked as well [06:07] Kamion: there were a few people talking about the port on the mailing lists [06:07] also thom and Mithrandir, but i will not speak for them [06:07] fabbione: I like that idea. elmo: any comments? [06:08] doko: i am building the same way debian does atm. [06:08] also [06:08] this temporary repository should not be available for mirrors [06:08] it makes sense, I guess - we'll just need another repository [06:08] elmo: could this be integrated with our normal package upload infrastructure, keyrings etc? [06:08] the reason is that we need to be able to measure [06:08] how many downloads we get for that port [06:08] and mirrors will make the calculation more complex [06:09] as lamont suggested to me this morning [06:09] well.. actually, I guess we could put it in the normal repo and just --exclude it when we sync to archive.ubuntu.com .. if that's not too disgusting? [06:09] fabbione: that will be very difficult. Could you make use of popcon? [06:09] once the port will be allowed to enter the official archive [06:09] the packages will be already close to the buildd for usage [06:09] haggai: just make use of /var/log/apache2/sparc.ubuntu.com :) [06:09] and not on my desparate 2M/512k adsl [06:10] elmo: I was thinking it is likely to get mirrored / copied via CD / apt-proxy etc that won't show up [06:10] elmo: it's really up to you... [06:10] haggai: yeah, but users still run apt-get update [06:10] also [06:10] the fact of keeping everything seperate is better in the beginning [06:10] well, I'm happy to do the dubious --exclude method, it's certainly the path of least resistance [06:10] i wouldn't like the idea that we let sparc enter the archive [06:10] elmo: true, that will give you a count of sites using it [06:11] and then tomorrow i will die in a flight accident [06:11] nobody will maintain it and it will have to be removed [06:11] anyway i don't have anything more to say [06:11] i hope i was fast enough :-) [06:12] ok, so everybody seems happy with the idea -- fabbione and elmo, can you draw up a plan between you ? [06:12] fabbione: when does you flight go tomorrow? ;) [06:12] fabbione: thanks for this idea, it's awesome [06:12] no problem for that [06:12] doko: together with you :-) [06:12] sabdfl: welcome :-) [06:12] Keybuk: k [06:12] id be reassured if we could actually get some non-canonical guys keen enough to work on it [06:12] so that would be a key test for "official" status [06:12] sabdfl: i am pretty sure we will.. i think they only need a kick to start [06:13] it will be more resilient if it gets community momentum [06:13] sabdfl: i didn't decide a key moment to make it official [06:13] but i would say when we start receiving bugs on it, it will be a very good sign [06:13] clearly it is unsupported [06:14] but it is a key point [06:14] I guess a port becomes an official when we've forgotten it's not an official one :) we can decide that on a port-by-port basis until we've decided goals they need to meet [06:14] pitti: you're up again, dropping support for Mozilla? [06:14] Keybuk: i agree, but there is also a limitation we need to take into account [06:15] Keybuk: well, I asked myself if it is wort supporting Mozilla in Hoary [06:15] my sparc can't manage to keep up with * alone [06:15] because we have Firefox and Thunderbird [06:15] so i know that i will be able to offer only main [06:15] either we have to promote the locale* packages to main, or drop Mozilla to universe [06:15] I guess it's been relatively less used since firefox.. [06:15] pitti: Mozilla itself is main because it's a build-dependency of GNOME [06:15] what's the general feeling about this? [06:15] i'm ok with it [06:15] Keybuk: for epiphany, yes [06:15] it was === babui [~babui@gardeny.udl.es] has joined #ubuntu-meeting [06:16] Keybuk: but that does not mean that the debs need to be in main [06:16] I've rebuilt epiphany/yelp/debhelp with firefox [06:16] pitti: they do. [06:16] seb128: nice [06:16] seb128: are there any remaining dependencies on Mozilla itself? [06:16] pitti: yeah, they do [06:16] pitti: a main package can't depend on something outside main [06:16] Keybuk: not on the base installation at least, I've removed the package for like a week now here [06:16] well, can't we leave just the source in main? [06:17] as with apache? [06:17] seb128: what about evolution -> nspr-dev / [06:17] hum, not looked on this [06:17] I guess the way to find out is to remove Mozilla from the desktop seed [06:18] pitti: the buildds have now been changed to build main against only main [06:18] and see where it falls [06:18] okay, so if we want to fully support Mozilla in addition to FireFox, do we want to support translations, too? [06:18] pitti: so if there's a build-dependency on it in main, the binaries have to stay ... [06:18] it sounds like seb128 has already done the hard work [06:18] Keybuk: mozilla-browser is not needed by anything in main afaik [06:18] Kamion: ah, okay. I thought only having the source package in main was possible [06:18] pitti: do firefox / thunderbird do their translations the same way mozilla does? [06:18] sabdfl: yes [06:18] sabdfl: but they have their own set of locale debs [06:19] sabdfl: are you happy with dropping Mozilla into universe, and just having Firefox and Epiphany in main? [06:19] sabdfl: I already did the firefox and thunderbird debs today, but not mozilla [06:19] well those will definitely fold into languagepacks [06:19] lp#'s for oo.o, tbird, ffox [06:19] sabdfl: as soon as we have real langpacks, yes [06:19] sabdfl: right now, they stay as they are and are only pulled in as a dependency of a metapackage [06:19] epiphany-extensions build-deps on mozilla-dev which depends on mozilla-browser [06:20] swfdec has the same build-dep [06:20] seb128: can you investigate those ... and check for any remaining build-deps ? [06:20] Kamion: oups, I just need to rebuild epiphany-extensions [06:20] As far as I understand, mozilla upstream will move to ffox/tbird in the long run [06:20] that's all germinate reports, anyway [06:20] Keybuk: ok, I'll do [06:20] so the question is how long they still support mozilla proper [06:20] Kamion: if we drop mozilla from the seed, that's all that holds it in desktop? [06:21] we still need other stuff from the mozilla source package; evolution depends: libnss3, for example [06:21] yes, i think mozilla is rapidly switching to ffox / tbird [06:21] Keybuk: it's not in desktop in the first place [06:21] it's in ship [06:21] if it's a dependency, then it will say in main, so we have to do all the work to support it anyhow [06:21] dropping mozilla-psm from Ship would take mozilla-browser off the CD [06:21] unless we can split out the source package pieces that are really needed for main [06:22] I'm not familiar with the consequences of dropping mozilla-psm [06:22] does firefox use it? [06:22] is that also used for firefox security? [06:22] I think so [06:23] I think mozilla-psm is not necessary for ffox [06:23] ok, maybe pitti can look into whether we can do entirely without that source package in main [06:23] at least I did not have it installed, but https:// works in ffox anyway [06:23] yes [06:23] and if so, we can drop it [06:23] if we can do without the source, I'm all for dropping it [06:24] elmo, keybuk, Kamion? === lamont_r thought moz-psm handled password caching etc, no? [06:24] i thought it did pki stuff === lamont_r shrugs [06:24] dropping it from Ship's cool with me if somebody investigates it and finds that it has no effect [06:24] (perfectly willing to be told I'm dead wrong...) [06:24] mozilla-firefox doesn't recommends mozilla-psm, so it's probably not useful [06:25] hm, I don't even have mozilla-psm installed -- and I use https and password cacheing all the time [06:25] what kamion said [06:25] it's necessary for mozilla proper to do SSL stuff, but not for ffox [06:25] that'd recover 10MB or so of space [06:25] ok [06:25] for translations :-) (SCNR) [06:25] i think we're all in agreement [06:25] I'll look into this [06:25] dependency-wise [06:26] can we also conduct a check with the user community? [06:26] i think this would be a good start for the "Ubuntu Enhancement Proposal" process we discussed in oxford [06:26] pitti, could you work up such a proposal with mako, and send it to -devel and -users? [06:27] sure [06:27] the proposal should note that we can drop mozilla-browser from the CD without necessarily de-supporting it (as an option) [06:27] it should be posted on the wiki, with room for people's comments below [06:27] right, it could go to main [06:27] sorry guys.. i need to leave for today. Thanks a lot everybody :-) [06:27] fabbione: thanks. [06:27] cheers fabbione, enjoy the new kitchen [06:27] sabdfl: will do :-) [06:27] fabbione: mind out of planes. [06:27] bye fabbione [06:27] stay INside planes [06:27] lol [06:28] pitti: ok, Thunderbird locale packages ... [06:28] speaks for itself [06:28] the mozilla-thunderbird-locale-* packages are currently in universe [06:28] they're in universe now, should we move them to supported/main/etc. ? [06:28] I think this is more an accident than deliberate, right? [06:28] Kamion: ? [06:28] yes, i think so [06:28] I already changed them today to support language packs [06:28] seems straightforwardly correct to move them to main [06:28] but if the langpack wants to depend on them, they must be main === cenerentola [~cenerento@84.222.39.231] has joined #ubuntu-meeting [06:29] put 'em with mozilla-firefox-locale-* in Supported [06:29] okay, then this point is already finished :-) [06:29] Kamion: agreed. [06:29] Keybuk: next? [06:29] as long as all of them are up-to-date and usable with the current version [06:29] no, they aren't [06:29] Kamion: I will mail you which are [06:29] ok, pick those that are and seed them, then [06:29] Kamion: same thing the other way round: many of the ffox locale packages are out of date [06:30] yep [06:30] Kamion: I already have a list [06:30] ongoing merge feedback -- I just wanted to get some feedback from the Ubuntu guys how well the ongoing merge process is doing, and whether they had any comments? [06:30] note that those are being aggressively updated/dropped in Debian at the moment [06:30] I always wondered why you merge Debian changes against Ubuntu [06:30] doing it the other way round would be more straigtforward [06:30] pitti: because it works better about 70% of the time [06:31] Keybuk: I'm finding that the automerges tend to be a bit aggressive about running debconf-updatepo; they sometimes do it when there are no debian/po/ changes, producing some unnecessary diffs [06:31] but if Debian and Ubuntu hav the same solution, we should prefer the Debian one, right? [06:31] I've put some changes in today so it will try the other way around as well, and favour the one that drops less [06:31] ah, nice [06:31] Keybuk: there seemed to be some missing merges too; rootskel 1.09 was uploaded to Debian two or three days ago, but there was no bug about it (I did it by hand today) [06:32] elmo: ? [06:32] yeah? [06:32] has rootskell appeared in needs-merged.txt ? [06:32] the merges fail for packages with patches inside. Maybe just add a note to the REPORT file, that patch/dpatch files were found. [06:32] Keybuk: yep [06:33] Kamion: will probably appear tomorrow then [06:33] there's usually 1-2 days delay between things happening [06:33] Keybuk: well not anymore, but it was there when kamion asked about it [06:33] "not anymore" ? [06:33] oh, right [06:33] Keybuk: ah, fair enough [06:33] I'm not sure the work/ directories are helpful? [06:33] Kamion: it only happens at about midday each day ... and depending on the exact situation of Open, snapshot.dn and our mirror, it might delay it a day or so [06:34] you get work directories? [06:34] yes, I already got some of them [06:34] they've appeared in a number of candidate merged source packages, some people have forgotten to remove them on upload [06:34] I just deleted them [06:34] but one can forget about this [06:34] they just have ,,magic-reject files [06:34] Keybuk: having the unmolested input .dsc/diff.gz would be nice as well, although that's seldom really needed [06:34] Kamion: d'oh ... will fix that bug :p they're supposed to go elsewhere [06:35] ENOos.path.abspath [06:35] would it be possible to get the code in a form that it can be run by hand, or is that impractical at the moment? [06:36] well, you can check it out and fiddle with the code to make it do one-shot things [06:36] scott@canonical.com--2004/merge-o-matic--devel--0 [06:36] and you'll need "deb" from [06:36] scott@canonical.com--2004/sourcerer--devel--0 [06:36] and "util" from [06:37] scott@canonical.com--2004/hct--devel--0 [06:37] ok. [06:37] any other business? [06:37] nothing from me [06:38] I've added an agenda item to next week's community council meeting for those people who asked for upload earlier to present themselves to the CC for approval [06:38] nope [06:39] Keybuk: thanks === jdz` [~jdz@69.49.156.181] has joined #ubuntu-meeting [06:39] ok, thanks very much everybody. === ChrisH [~chaas@gw.workaround.org] has left #ubuntu-meeting [] [06:40] Keybuk: do we have a webcal for hte meetings ? [06:40] s/hte/the/ [06:40] Keybuk: thanks dude [06:40] seb128: no, they're just every two weeks. TB/CC on alternate Tuesdays === smurfix waves [06:40] thanks all [06:41] Keybuk: ok [06:41] thanks Keybuk [06:41] keybuk, thanks for sitting in The Chair [06:41] thanks Keybuk :) [06:41] cheers all === daniels [~daniels@george.kkhotels.co.uk] has left #ubuntu-meeting [] [06:41] happy hacking, folks === babui [~babui@gardeny.udl.es] has left #ubuntu-meeting ["Abandonando"] [06:41] see you === lamont_r [~lamont@adsl-69-107-92-115.dsl.pltn13.pacbell.net] has left #ubuntu-meeting ["Leaving"] === seb128 [~seb128@ANancy-151-1-23-252.w83-194.abo.wanadoo.fr] has left #ubuntu-meeting ["I] === pitti [~martin@195.227.105.180] has left #ubuntu-meeting [] [06:42] cheers === egli [~egli@gate.wyona.com] has left #ubuntu-meeting ["Leaving"] === amu [~amu@195.71.9.198] has left #ubuntu-meeting [] === Henri1 [~Henrik@henrik.gotadsl.co.uk] has left #ubuntu-meeting [] === Keybuk [scott@descent.netsplit.com] has left #ubuntu-meeting ["Leaving"] === elmo [~james@83.216.141.215] has left #ubuntu-meeting ["Leaving"] === haggai [~halls@i-83-67-20-196.freedom2surf.net] has left #ubuntu-meeting ["move] === jdz` [~jdz@69.49.156.181] has left #ubuntu-meeting [] === sivang [~sivang@80.179.93.130.forward.012.net.il] has left #ubuntu-meeting ["Leaving"] === ironwolf [~ironwolf@c-24-6-251-226.client.comcast.net] has left #ubuntu-meeting ["Leaving"] === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] === hornbeck [~hornbeck@adsl-69-155-172-150.dsl.okcyok.swbell.net] has left #ubuntu-meeting ["Leaving"] === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] === lupus_ [~lupus@kn-ivl-2.kuleuven.net] has left #ubuntu-meeting ["Leaving"] === cenerentola [~cenerento@84.222.39.231] has joined #ubuntu-meeting === cenerentola is away: I'm busy