=== sm [~simon@lsanca1.ar5-] has joined #ubuntu-meeting
=== pitti [~martin@] has joined #ubuntu-meeting
=== cenerentola [~cenerento@] has joined #ubuntu-meeting
=== skyrider [~skyrider@kid.stu.cn.ua] has joined #ubuntu-meeting
=== pitti [~martin@] has joined #ubuntu-meeting
=== mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting
=== pitti [~martin@] has left #ubuntu-meeting []
=== pitti [~martin@] 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@] has joined #ubuntu-meeting
=== sivang [~sivang@] 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@] 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
smurfixQuick question: are the logs (or a synopsis) from the last tech meeting available someplace?04:55
fabbionesmurfix: people.ubuntu.com/~fabbione/irclogs/04:56
fabbionea more official url needs to be done04:56
fabbioneso do not bookmark it04:56
smurfixOK. (NB, official logs should probably have UTC timestamps.)04:59
=== hornbeck [~hornbeck@adsl-69-155-172-150.dsl.okcyok.swbell.net] has joined #ubuntu-meeting
=== amu [~amu@] has joined #ubuntu-meeting
fabbionesmurfix: i am not going to change date and time on my server for that :-)05:00
pittiHi folks05:00
smurfixfabbione: env TZ=UTC should be sufficient.05:00
seb128afternoon pitti 05:00
seb128and the others too :)05:00
Keybukafternoon folks05:01
Keybukseb128: (wishlist) temporarily turn off "typing break" feature <g>05:01
seb128yeah :)05:01
Keybukok, let's get started05:01
fabbionesaomebody ping sabdfl?05:02
Keybukheh, good point :p05:02
=== 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
danielsis baby jesus in attendance also?05:02
=== ..[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
pittiHi silbs05:03
=== lupus_ [~lupus@kn-ivl-2.kuleuven.net] has joined #ubuntu-meeting
silbshi pitti05:03
Keybuksilbs, lulu: throw a bread roll or something at Mark, would ya? :p05:03
=== haggai [~halls@i-83-67-20-196.freedom2surf.net] has joined #ubuntu-meeting
danielsKeybuk: or a jellybean05:04
=== mako waves
sivanghey mako05:04
=== sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting
sabdflhi all05:04
silbskeybuk: thrown05:04
smurfixMissing agenda item: confirmation of new maintainers? *cough* ;-)05:05
=== lamont_r [~lamont@adsl-69-107-92-115.dsl.pltn13.pacbell.net] has joined #ubuntu-meeting
Keybukhave there been additional new maintainers since the last community meeting?05:05
sabdflsmurfix: you mean the ones that were approved by the CC last week?05:05
sivangit's been done on the CC meeting last time, with TB attandent .05:05
=== magneto [~magneto@] has joined #ubuntu-meeting
=== Henri1 [~Henrik@henrik.gotadsl.co.uk] has joined #ubuntu-meeting
Keybukok, so I'm going to act as emergency-holographic-mdz while he's sunning himself on some beach somewhere :)05:06
=== plovs [~plovs@] has joined #ubuntu-meeting
smurfixAh, OK. Mark wrote that that still needs to happen AFAIR.05:06
sabdflthose maintainers that want to be on the keyring for uploads do need to be approved by the TB05:07
=== tseng [~tseng@thegrebs.com] has joined #ubuntu-meeting
sabdflbecause they need to be comfortable with the gpg key management security05:07
smurfixsabdfl: that would be me then05:07
Keybuksabdfl: do we want to add that to the agenda for this meeting?05:07
sabdflKeybuk: yes please05:07
sabdflsmurfix: you're already a DD right?05:08
smurfixsabdfl: Yep05:08
sabdflok, then np05:08
sabdflas long as the rest of the TB concurs :-)05:08
=== elmo [~james@] has joined #ubuntu-meeting
Keybuksabdfl: I do, certainly.05:08
elmodamn timezones05:08
Keybukdo we have a list of the others that need confirming?05:09
sabdflKeybuk: do we have the full TB?05:09
sabdflenrico said he would like upload, so he needs to be confirmed05:10
hornbeckI would like upload05:10
hornbeckfor future sake05:10
sabdflhornbeck: how comfortable are you with gpg?05:10
=== amu too
Keybuksabdfl: mdz is on holiday, he was around about 10 minutes ago for just 5-10 more minutes05:10
hornbeckgetting real comfortable05:10
=== haggai puts up hand too
sabdflhaggai: have you been approved by the CC last week?05:11
haggaisabdfl: no05:11
sabdflthen start there :-)05:11
haggaiokey dokey05:11
Keybuksabdfl: the list you posted on the 9th Nov was:05:12
Keybuk - Thibaut Varenet05:12
Keybuk - Alexander Poslavsky05:12
Keybuk - John Hornbeck05:12
Keybuk - Matthias Urlichs05:12
=== ChrisH [~chaas@gw.workaround.org] has joined #ubuntu-meeting
sabdfland enrico, behind the scenes05:12
=== jdz` [~jdz@chpau.oxfordnetworks.net] has joined #ubuntu-meeting
=== plovs doesn't need upload for now, later maybe
sabdflhornbeck: doyou have a gpg key that is widely signed?05:13
hornbecknot yet, I can hold on upload right now05:13
sabdflhornbeck: ok, i think so05:13
hornbeckthats fine05:13
sabdflupload via enrico for the moment, if you are coming to the conf it will be a good way to get your key trusted05:13
sabdflok keybuk, take it away05:14
Keybukwe should definitely ensure we have a trusted path to anyone whose key we put in the keyring05:14
elmoKeybuk: dude, we had problems doing that for employees05:14
elmo(not that I'm saying we shouldn't, but you should be aware it's going to be painful for some folks)05:15
sabdflwe can use formal procedures, notarisation etc to get it done05:15
danielstrust path doesn't imply direct, necessarily05:15
Keybuktrusted path can be "we have a signed contract and pay them" :)05:15
danielsyou could use debian wot, e.g.05:15
Keybuk"we know where you live"05:15
elmodaniels: I was using the debian wot and indirect paths05:15
lamont_relmo: making the exceptions higly visible would be a good way of dealing with the few that are exceptions...05:15
fabbioneelmo: i think you are the only one not signing keys yet :P05:15
sabdflwe'll get it done for anyone that really needs it, using notaries etc05:15
sabdfllet's get going on today's agenda, keybuk leads05:16
danielselmo: oh, wow05:16
Keybukyup, I'm going to move the ongoing merge feedback to the end to give Colin time to get back05:16
Keybukso first up is pitti and splitting out language packs05:16
pittiI already started working on firefox and thunderbird05:17
pittiOO.o is cleared, too05:17
pittithe remaining question is whether we really want to extract gettext po files05:17
pittipro: saves some installed space05:17
pitticon: heavily intrusive, needs rebuild of whole archive05:18
Keybukthis is taking the translation data out of the application packages and into a single .deb (for those not following this :p)05:18
pitticon: needs debhelper change and makes inconsistencies easy05:18
pittiKeybuk: right, that was an idea05:18
pittihowever, I think the main problem we really have is missing translations for OO.o, Firefox and so on05:18
sabdflpitti: i very much want this as a hoary feature, fwiw05:18
pittisabdfl: we will have language packs for above apps in any case05:19
sabdflthat's an orthogonal issue, which rosetta aims to solve05:19
Keybukdo we want to leave any languages in the original packages?05:19
Keybukor should they all be split into language packs?05:19
pittiKeybuk: you mean gettext?05:19
Keybukpitti: I mean in general05:19
elmois this going to require source changes?05:19
sabdflKeybuk: yes, for packages outside of the desktop list05:19
elmofor every source package?05:19
sabdflelmo: for the base and  desktop packages05:19
pittifor now I think the advantages we would get from extracting gettext files don't outweigh the cons05:19
lamont_rsabdfl: that's ugly before the infrastructure is there...05:20
fabbionelegislatura danese05:20
pitti"infrastructure" in this case would mean a modified debhelper and a handful of packages which require manual changes05:20
Keybukpitti: 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
elmosabdfl: that's going to take the merge work from minimal to... lots05:20
pittiKeybuk: yes05:21
Keybukcan you elaborate?05:21
pittiKeybuk: because for OO.o and mozilla we already have separate locale debs05:21
pittiKeybuk: thesep rograms don't use gettext05:21
pittiKeybuk: e. g. Mozilla uses these xpi files05:21
sabdflthis is the sort of "do it across the whole archive" thing that we can do05:21
haggaiand OOo/moz already have separate .debs in Debian05:21
pittiso for OO.o and mozilla it's just a matter of a metapackage that depends on e. g. mozilla-firefox-locale-de05:21
sabdfl'm willing to hire a team just to handle this sort of stuff05:22
sabdflwe need to make it as efficient as possible05:22
pittisabdfl: but what's the real benefit of having extracted gettext files?05:22
sabdflpitti: lay the groundwork for rosetta, make the languages more concrete and visible05:22
pittithe user won't notice whether foo.deb or language-support-XX.deb shipped a gettext template05:22
elmosabdfl: yes, but it's not a once off cost - there's the ongoing merge cost05:22
Keybukok, 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 desktop05:22
Keybukis that the basic idea?05:23
sabdflelmo: we are going to get to the point where we have touched every package in main, and have to sustain the merge05:23
pittiadn the original debs don't contain the files any more05:23
pittibut it's not only a merging problem05:23
haggaiwhat about doing the change in Debian proper too?05:23
pittiwe have to update the language pack for each and every upload (including seurity updates)05:23
Keybukthe "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 that05:24
elmohas anyone found out how big language-pack-$LANG will be?05:24
sabdflwe will continue to update the language pack after release05:24
pittiand the problem is that the language pack would depend on _all_ other packages with a particular version05:24
smurfixWhy not pull the locale files out of the .deb files after the fact? No more merge problems.05:24
sabdflso that new translations come into use05:24
sabdflwithout requiring code updates05:24
elmosabdfl: ??05:24
pittielmo: my /usr/share/locale is 169 MB05:24
pittielmo: but this contains _all_ translations,05:24
elmowow, mdz's going to be so sorry he missed this meeting05:24
pittiso I think a particular language pack will be quite small05:24
pittiabout 10 MB or so05:25
elmopitti: so we have, best case, 169MB of unrsyncable debs that change every day?  woot05:25
fabbionepitti: can you see how many languages in average?05:25
Keybukdescent scott% ls -l ca_data.tar.*05:25
Keybuk-rw-rw-r--    1 scott    scott        1.7M 2004-11-16 16:24 ca_data.tar.bz205:25
Keybuk-rw-rw-r--    1 scott    scott        1.9M 2004-11-16 16:24 ca_data.tar.gz05:25
pittifabbione: what do you mean`05:25
Keybukthat's using Catalan (I think)05:25
fabbionepitti: see how big is one language. 05:25
pittifabbione: 100 directories, 161 MB05:26
pittifabbione: that makes 1.6 MB on average for a language05:26
pittifabbione: of course popular ones are much bigger05:26
Keybuksabdfl: where are we going to put the updated language packs?  hoary itself, hoary-security or hoary-updates ?05:26
elmosorry, what's the big gain in this?05:26
elmoother than being able to update translations independently05:26
pittielmo: I don't understand either05:26
dokoelmo: 160MB more place on the CD for other packages?05:26
elmodoko: how does that work?05:27
fabbionesabdfl: 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
pittiit really makes an user-visible difference for langpacks for OO.o and firefox/thunderbird, but not for gettext05:27
elmodoko: unless we have per lang CDs?05:27
sabdflfabbione: strings don't change, but we get more translations05:27
pittidoko: no, because we have to ship the translations anyway05:27
sabdflso you can update each week, and your apps become "more translated"05:27
elmosabdfl: at an insane cost for mirrors05:27
sabdfland you are only downloading the new strings for languages you care about05:27
pittifabbione: security updates might touch translations05:27
fabbionesabdfl: from my experience about debconf translation, we will get them for new releases of the packages. 05:27
Gwildor_real quick, can I post here, or just "listen"?05:28
elmoso, 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 languages05:28
fabbionepitti: yes that is a very special case that will push hell of an update05:28
KeybukGwildor_: feel free to jump in if you've got something to contribute :)  be on topic, there's time at the end for any other business05:28
pittifabbione: luckily it shouldn't occur very often05:28
pittiI have a proposal05:28
pittifor Hoary, we confine the language packs to OO.o and Mozilla stuff05:28
pittithen we can wait for Rosetta and try out whether separating the translations really brings benefit05:29
dokoelmo: another reason: if the catalan translation is updated, you won't even download 20k?05:29
pittianother point: as soon as we have langpacks, our packages will conflict to every debian pacakge05:29
elmodoko: _I_ won't, but the mirrors will download 2Mbxn (where n is, what conservatively? 50?)05:29
Gwildor_maybe make a language repo?, being a synaptic user, it is quite annoying searching thru language packs?05:29
pittiand worse, users cannot compile packages on their own05:29
Keybukpitti: 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
elmoit's not worth saving our users 20k, if it costs our mirrors 160Mb05:30
Keybukpitti: no, just Replaces05:30
pittiKeybuk: it makes a difference05:30
pittiKeybuk: right now, non-english users don't get translations for firefox/ooo/thunderbird05:30
pittiKeybuk: but the langpack can be integrated into d-i, so this would install all relevant stuff automatically05:31
sabdflpitti: it's a good start05:31
sabdflelmo: is the issue that mirrors won't like the rapid changing languagepack packages?05:31
pittinot being able to compile packages on one's own is a major drawback05:31
Keybuktalking of d-i ... how are we handling debian/po with this?  are we splitting out the debconf translations as well?05:31
sabdflpitti: im sure we can solve that one05:31
pittisabdfl: how?05:31
pittisabdfl: the user would be required to take our build infrastructure05:32
elmosabdfl: 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 packages05:32
pittisabdfl: and generate his own language pack05:32
sabdflpitti: make it so a normal build leaves the translations in05:32
elmolike, on an order of magnitude increased05:32
pittisabdfl: this does not work05:32
Keybuksabdfl: you couldn't install the normal build -- it'd conflict with the language pack05:32
pittisabdfl: because the newly compiled package and the language pack would conflict filewise05:32
fabbionesabdfl: dpkg will refuse to install the locally built package05:32
pittino debian packages, no external apt sources any more05:33
pittifor a change that an user does not actually see05:33
haggaiand you get a lot of extra differences between debian<->ubuntu package file lists05:33
pittihe will get translations either way05:33
pittiWe should ask ourselves a question: what is our actual problem?05:34
pittiproviding the users with apps in his language?05:34
sabdflpitti: (a) we cannot update translations after release without updating packages05:34
pittisabdfl: but you have to update the language pack05:34
sabdflpitti: (b) we put a lot of translations on the cd that will never be used, languagepacks would be more efficient05:35
haggaisabdfl: update or add new?  Adding new is probably easier to do than update05:35
pittisabdfl: so you want to throw out translations for (b)?05:35
dokowhat about making an additional language pack and divert the files, which the language pack updates?05:35
sabdflpitti: (c) we want "install a new language" to be a more concrete action, that updates various bits of the system config accordingly05:35
dokothat way, local build can still be installed.05:35
pitti(c) is not even necessary now05:35
fabbionedoko: iirc dpkg-divert goes on crack in certain situation. (there is something about it on debian bts related to xfree86)05:36
sabdflyes, (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, etc05:36
Keybukfabbione: that's Branden being on crack (shock)05:36
Keybukbut it is a dpkg-divert bug05:36
pittiAFAICS (b) is the only real reason05:36
fabbioneKeybuk: eheh05:36
sabdflpitti: (a) is just as important05:36
sabdflwith rosetta, we will get a lot of translations after a release05:37
sabdfland we want to be able to get those translations to users for that release, as well as later ones05:37
haggainew translations or updates of existing languages?05:37
pittisabdfl: but whether you update language packs or normal packages does not really make a difference05:37
Keybukmy concern with updating translations after a release is that updated translations can introduce security holes05:37
sabdflhaggai: both05:37
sabdflpitti: it's a much smaller update for the user05:37
sabdfland it changes no functionality, so it could go out with our daily/weekly post-release updates05:38
pittibut as Keybuk say, an error in a translation can easily make a buffer overflow05:38
sabdflso each week i download 2-10 mb and i get smarter translations05:38
pittiso translations have to be reviewed very carefully if we put them into stable reelases05:38
elmosabdfl: at a quite simply unbearable cost to mirrors05:38
dokousing 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:38
sabdflelmo: how many mirrors cover warty-security?05:39
pittiI actually like the idea with diverting changed files in the language pack05:39
elmoseriously, I can't overstate this enough.  my /usr/share/locale/ is 223Mb - you're proposing a 223Mb hit PER DAY05:39
Keybukdoko: the other option is to have an /usr/share/language-pack alternate locale heirachy05:39
dokoelmo: are separate ftp areas for language packs a solution?05:39
elmoand bear in mind that's "katie" days, i.e. in reality ==> half an hour05:39
elmosabdfl: any that have the archive05:39
sabdflelmo: only during the development period05:40
pittisabdfl: 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_ packages05:40
dokokeybuk: ant to search this one first? that would mean _one_ change in gettext?05:40
elmosabdfl: err, even when we're frozen, there was easily an update of a desktop package once a day (real day)05:40
pittisabdfl: what do you think about the diversion idea? Itsounds nice to me05:40
elmosabdfl: and just one source package is enough to incure the 223Mb hit05:40
sabdflelmo: after release, there are no string changes, or very, very few05:41
sabdflso it's only new translations that will be downloaded05:41
elmosabdfl: but dude, we develop for what?  2/3 months?05:41
sabdflpitti: i don't know enough about the diversion mechanism, how does it work?05:41
elmoit's just not sane that a souce package with string changes ==> 223Mb hit05:41
elmoA source package.  one of them.  any one of them (in desktop).05:41
pittisabdfl: it basically means that a package can say "hey, I have a replacement for this file X in this other deb"05:42
pittisabdfl: so the langpack would only divert the files it actually changed05:42
pittisabdfl: we could leave our current debs intact05:42
pittisabdfl: and after the release, the langpack would "replace" (divert) just the changed .po files05:42
Keybukand the language pack would become incrementally larger after release adding or updating translations?05:42
sabdflpitti: does that scale to the numbers of files we are dealing with?05:42
elmohow is this even going to work anyway - what's going to update the language pack?05:43
dokopitti: 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
elmowhat happens with concurrent builds on buildds?05:43
pittisabdfl: I don't really know05:43
Keybuksabdfl: yeah, you can dpkg-divert your entire file system quite happily05:43
elmoor is it taken out-of-bounds of the build-a-source package process?05:43
smurfixthat would mean that people can't enhance their self-built package with new translated strings though05:43
amuwell KDE handle in such a way they deliver a big packages with all translation in it, and deliver kind of diff to updates05:43
pittiKeybuk: is it easy to have a second hierarchy globally?05:43
Keybukpitti: no idea.05:43
pittiKeybuk: or does it require a change of all packages?05:43
pittiKeybuk: it seems that only a gettext change is required, though05:44
danielsamu: yah, but KDE doesn't deal with binary packages05:44
dokoelmo: is it _one_ language pack source package, or one for each language?05:44
danielsamu: you don't push a new kde-i18n binary every time someone updates kdeextragear-105:44
Keybukyou'd have to be wary of packages that statically linked an in-source libintl :-/05:44
elmodoko: AFAIK they're talking about one for each "language"05:44
sabdfldoko: one for each language05:44
pittiKeybuk: oh, right. This is hard to catch...05:45
elmoone for each source package, would actually solve the mirror problem, it just brings back the Packages problem back a little bit05:45
elmoit would also solve the concurrent-buildds issue05:45
sabdfli'm not sure we can safely multiple the number of packages by 200 :-)05:46
Keybukelmo: 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 set05:46
amudaniels: you can package only the diffs compared to the first version, with a release you merge all to a new big one  05:46
danielselmo: i weep on behalf of dialup05:46
elmoKeybuk: how on earth would that work?05:46
danielsamu: how does that actually work?05:46
Keybukelmo: you'd just update language-pack-XX when you got new translations in, and not bother with the source package05:46
amudaniels: see Keybuk 05:47
sabdflif 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
elmosabdfl: dude, if it's really 200 languages, that's more like 400Mb hit then ...05:48
Keybuksabdfl: puts it in the diverted place05:48
sabdflelmo: many languages have very few translations05:48
sabdflwith rosetta, we hope that will change05:48
elmoKeybuk: 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 20005:48
elmoKeybuk: I don't see how anything you've said could help with that?05:48
sabdflif 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:48
Keybukelmo: no, it starts off 0 x 200 ... and only grows in size if new translations come in05:49
elmosabdfl: no, dude, it's NOT05:49
elmosabdfl: if evolution gets new strings, the hit to mirrors is evolution05:49
elmosabdfl: with language packages, the hit is 400Mb05:49
Keybukelmo: I think Mark's point is that 400MB of translations doesn't fit will on a CD :p05:49
elmoeven in 2015, evolution won't be 400Mb big05:49
fabbione(+ evolution)05:49
sabdflelmo: if every package is fully translated to every language, the size of the translations in all the packages will be 2/3 of the CD05:49
sabdflso we won't be able to put the packages for desktop on the cd05:50
fabbionesabdfl: i think we should approach this problem in a different way05:50
fabbioneinstead of changing the build system for all package05:50
fabbionewe should find a way to strip languages for CDs05:50
elmosabdfl: so we split them out, but we can't split them out into some monstrous "I come from all desktop sources" mirror-killer package05:50
pittifabbione: you mean, repack the .debs?05:50
pittifabbione: this should be easy05:50
Keybukelmo: what would you suggest that wouldn't kill the mirrors?05:50
fabbionepitti: only to build the CD05:50
dokosabdfl: the we have that many translatios, we'll DVD's ;)05:51
pittifabbione: but what do you do with the stripped files then?05:51
fabbionepitti: at that point we can have CD English/Itaglish/Italian05:51
pittifabbione: ah, I see05:51
fabbionepitti: trash them.05:51
elmoKeybuk: 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 together05:51
Keybukfabbione: APT gets its freaky on when it has two packages of the same version (one installed, one in the archive) with different installed-size05:51
pittifabbione: you delete all but one language05:51
dokosabdfl: the time we have that many translatios, we'll DVD's ;)05:51
fabbionepitti: the packages in the archive will not be altered05:51
pittifabbione: good idea05:51
sabdflfabbione: 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
Keybukelmo: we're going to have to accept we can't fit all the translations on the CD ... so what do we do?05:51
fabbionepitti: only the one that lands on the CD05:51
lamont_rKeybuk: yeah.  name/version/architecture tuple needs to uniquely identify the file05:52
elmoKeybuk: strip them out, oo.o/mozilla style?05:52
fabbionesabdfl: at that point yes. because if i reinstall from the mirror there will be no conflict05:52
fabbionesabdfl: the language file will belong to the same package05:52
elmomaybe with with big language groupings somehow to reduce the number of packages05:52
sabdflelmo: and land up with 200x8000 packages?05:52
pittifabbione: we could also think about only leaving the most popular 1005:52
Keybukelmo: so ~200,000 new source packages is better than 200 source packages?05:52
sabdflpitti: that's the plan05:52
pittifabbione: this should be fairly flexible05:52
elmosabdfl: 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 dat05:53
Keybukfabbione: no, it's really not ok.  apt will randomly reinstall some, and not others05:53
lamont_rfabbione: 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 bad05:53
fabbioneKeybuk: bad luck. how gets updates, gets all the package05:53
sabdflelmo: i agree with you, i was thinking we could manage the build / strip process so that the bullet would not be necessary05:53
Keybukfabbione: after an install, the first net update could take a 600MB hit!05:54
elmoKeybuk: if the 200 source packages change every day and total hit is 400Mb, yes05:54
fabbioneKeybuk: teach apt-get/dpkg not to do so?05:54
lamont_rKeybuk: in my experience it just throws a fit (but that's with the old package in the cache, not fetching...)05:54
Keybuklamont_r: stick Debian + Ubuntu in your sources.list -- it'll randomly swap packages around every update between the two archives :(05:55
Keybukanyway, that's getting slightly off-topic05:55
elmocan I propose an alternative?05:55
Keybukso: a language-pack per language kills the mirrors, as it needs to be updated for every new source upload05:55
sabdflelmo: yes of course05:55
Keybukelmo: please :)05:55
elmolet's devote all our resources into converting the world to use a single common language!!!!!!!!!1! 05:56
Keybuka language-pack per source per language kills the Packages file, as it introduces roughly a quarter of a million packages05:56
pittielmo: +1 :-)05:56
lamont_relmo: I thought that was tried with esperanto05:56
seb128elmo: can we pick french ? :)05:56
=== seb128 runs
pittiKeybuk: the packages file alone would fill the cd05:56
Keybukpitti: not to mention you needing a few gig of memory for APT to parse it05:56
lamont_rseb128: istr the french gov't would require that. :-)05:57
KamionKeybuk: in 10+ years of the GNU translation project they've managed about 30 languages total, maybe average 10 a package05:57
pittiKeybuk: and a week to download05:57
KamionKeybuk: I don't think we're going to surpass that by orders of magnitude any time soon05:57
elmoso maybe we don't use Packages for this - maybe we use something lighter weight?05:57
dokokeybuk: could you work around that by adding a new section main-de, universe-de ?05:57
pittiwe could download translations from rosetta directly to /var/share/locale05:58
pittiwithout packages05:58
sabdfli'm not opposed to a separate infrastructure of per-package, per-language files, coordinated through a new index05:58
Henri1How 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
sabdflit's a lot of work though, on new infrastructure05:58
KeybukI don't think there's anything the tech-board can decide on today05:59
KeybukThis needs a lot more discussion and some more concrete proposals we can pro/con05:59
Henri1One diff from the Gold frelease and one from each relevant security update.05:59
pittithis discussion should be wrote up in a pro/con list05:59
Keybukpitti: are you up for doing that?06:00
smurfixYou don't even need an index, minimally; just try to download ftp://wherever/LANG/PACKAGE.deb... but I agree with keybuk06:00
pittiI can do this06:00
pittiunfortunately I forgot to turn on logging, but fabbione's logs should do06:00
haggaismurfix: that doesn't scale if you have 1000s of packages installed06:00
pittiI write that up to u-devel06:00
Kamionsmurfix: need versioning though06:00
smurfixhaggai: it's not worse than the existing /pool.06:01
Keybukpitti: 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
pittiKeybuk: I also think we should digest this discussion a bit06:01
smurfixKamion: true, I sortof included the version in PACKAGE.06:01
haggaismurfix: you don't currently try to download a file for every installed package on your system06:01
pittiKeybuk: a pro/con table will help to device06:01
pittiKeybuk: s/device/decide/06:02
Keybukok, moving on.06:02
Keybukfabbione: sparc port status?06:02
pittiKeybuk: next item? BTW, you forgot the first one06:02
fabbioneduring the last weeks i was kind bored waiting for Xorg to compile06:02
fabbioneso i started porting Ubuntu to sparc06:03
fabbioneright now i am at stage0 of the port06:03
fabbionehalf way trough main06:03
fabbioneand it is going pretty well06:03
fabbionevery few failures06:03
sabdflelmo: can you get me some quotes on a sparc port box and 3 buildd's?06:03
fabbionethere were a few requests for this port on some mailing lists06:03
elmosabdfl: new?06:03
Keybukwhat kinds of sparc is this targetted at?  Low end, or shiny ultras?  32-bit or 64-bit?06:04
fabbionesabdfl: i gave you already a good number to phone for sparc hw06:04
sabdflelmo: your judgment, bang for buck but make sure they can keep up06:04
elmofabbione: please send it to me06:04
fabbioneelmo: i will06:04
elmosabdfl: ok06:04
fabbioneKeybuk: sparc64. i don't have any sparc3206:04
fabbionebut before asking for official buildd's06:04
fabbionei have a few questions to raise to all of you06:04
fabbionefirst we need a way to measure the use of one unofficial port06:05
fabbionein order to decide if it is really worth to buy buildd's or not06:05
fabbioneand what i was thinking about06:05
fabbionewas to have one machine at the datacenter06:05
dokofabbione, you did build everything for sparc64?06:05
fabbionethat can act as temporary archive for unofficial port in "evaluaton" status06:06
sabdflfabbione: you mean, we should offer to host any unofficial port, then decide based on downloads?06:06
sabdflsounds good06:06
fabbionedoko: as i wrote above i am half way trough main'06:06
fabbionesabdfl: exactly06:06
fabbionesabdfl: i don't see any point in wasting money if the port can't keep up06:06
fabbione"port" meaning also porters behind it06:06
fabbioneclearly i am doing this on my spare time and not company time06:07
dokofabbione: no, I mean sparc32 or sparc64 ?06:07
Kamionfabbione: are there people besides you interested in contributing development effort?06:07
fabbioneso i might get sucked as well06:07
fabbioneKamion: there were a few people talking about the port on the mailing lists06:07
fabbionealso thom and Mithrandir, but i will not speak for them06:07
Keybukfabbione: I like that idea.  elmo: any comments?06:07
fabbionedoko: i am building the same way debian does atm.06:08
fabbionethis temporary repository should not be available for mirrors06:08
elmoit makes sense, I guess - we'll just need another repository06:08
sabdflelmo: could this be integrated with our normal package upload infrastructure, keyrings etc?06:08
fabbionethe reason is that we need to be able to measure06:08
fabbionehow many downloads we get for that port06:08
fabbioneand mirrors will make the calculation more complex06:08
fabbioneas lamont suggested to me this morning06:09
elmowell.. 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
haggaifabbione: that will be very difficult.  Could you make use of popcon?06:09
fabbioneonce the port will be allowed to enter the official archive06:09
fabbionethe packages will be already close to the buildd for usage06:09
elmohaggai: just make use of /var/log/apache2/sparc.ubuntu.com :)06:09
fabbioneand not on my desparate 2M/512k adsl06:09
haggaielmo: I was thinking it is likely to get mirrored / copied via CD / apt-proxy etc that won't show up06:10
fabbioneelmo: it's really up to you...06:10
elmohaggai: yeah, but users still run apt-get update06:10
fabbionethe fact of keeping everything seperate is better in the beginning06:10
elmowell, I'm happy to do the dubious --exclude method, it's certainly the path of least resistance06:10
fabbionei wouldn't like the idea that we let sparc enter the archive06:10
haggaielmo: true, that will give you a count of sites using it06:10
fabbioneand then tomorrow i will die in a flight accident06:11
fabbionenobody will maintain it and it will have to be removed06:11
fabbioneanyway i don't have anything more to say06:11
fabbionei hope i was fast enough :-)06:11
Keybukok, so everybody seems happy with the idea -- fabbione and elmo, can you draw up a plan between you ?06:12
dokofabbione: when does you flight go tomorrow? ;)06:12
sabdflfabbione: thanks for this idea, it's awesome06:12
fabbioneno problem for that06:12
fabbionedoko: together with you :-)06:12
fabbionesabdfl: welcome :-)06:12
elmoKeybuk: k06:12
sabdflid be reassured if we could actually get some non-canonical guys keen enough to work on it06:12
sabdflso that would be a key test for "official" status06:12
fabbionesabdfl: i am pretty sure we will.. i think they only need a kick to start06:12
sabdflit will be more resilient if it gets community momentum06:13
fabbionesabdfl: i didn't decide a key moment to make it official06:13
fabbionebut i would say when we start receiving bugs on it, it will be a very good sign06:13
fabbioneclearly it is unsupported06:13
fabbionebut it is a key point06:14
KeybukI 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 meet06:14
Keybukpitti: you're up again, dropping support for Mozilla?06:14
fabbioneKeybuk: i agree, but there is also a limitation we need to take into account06:14
pittiKeybuk: well, I asked myself if it is wort supporting Mozilla in Hoary06:15
fabbionemy sparc can't manage to keep up with * alone06:15
pittibecause we have Firefox and Thunderbird06:15
fabbioneso i know that i will be able to offer only main06:15
pittieither we have to promote the locale* packages to main, or drop Mozilla to universe 06:15
sivangI guess it's been relatively less used since firefox..06:15
Keybukpitti: Mozilla itself is main because it's a build-dependency of GNOME06:15
pittiwhat's the general feeling about this?06:15
sabdfli'm ok with it06:15
pittiKeybuk: for epiphany, yes06:15
seb128it was06:15
=== babui [~babui@gardeny.udl.es] has joined #ubuntu-meeting
pittiKeybuk: but that does not mean that the debs need to be in main06:16
seb128I've rebuilt epiphany/yelp/debhelp with firefox06:16
Keybukpitti: they do.06:16
sabdflseb128: nice06:16
Keybukseb128: are there any remaining dependencies on Mozilla itself?06:16
elmopitti: yeah, they do06:16
sabdflpitti: a main package can't depend on something outside main06:16
seb128Keybuk: not on the base installation at least, I've removed the package for like a week now here06:16
pittiwell, can't we leave just the source in main?06:16
pittias with apache?06:17
Keybukseb128: what about evolution -> nspr-dev /06:17
seb128hum, not looked on this06:17
KeybukI guess the way to find out is to remove Mozilla from the desktop seed06:17
Kamionpitti: the buildds have now been changed to build main against only main06:18
Keybukand see where it falls06:18
pittiokay, so if we want to fully support Mozilla in addition to FireFox, do we want to support translations, too?06:18
Kamionpitti: so if there's a build-dependency on it in main, the binaries have to stay ...06:18
Keybukit sounds like seb128 has already done the hard work06:18
seb128Keybuk: mozilla-browser is not needed by anything in main afaik06:18
pittiKamion: ah, okay. I thought only having the source package in main was possible06:18
sabdflpitti: do firefox / thunderbird do their translations the same way mozilla does?06:18
pittisabdfl: yes06:18
pittisabdfl: but they have their own set of locale debs06:18
Keybuksabdfl: are you happy with dropping Mozilla into universe, and just having Firefox and Epiphany in main?06:19
pittisabdfl: I already did the firefox and thunderbird debs today, but not mozilla06:19
sabdflwell those will definitely fold into languagepacks06:19
sabdfllp#'s for oo.o, tbird, ffox06:19
pittisabdfl: as soon as we have real langpacks, yes06:19
pittisabdfl: right now, they stay as they are and are only pulled in as a dependency of a metapackage06:19
Kamionepiphany-extensions build-deps on mozilla-dev which depends on mozilla-browser06:19
Kamionswfdec has the same build-dep06:20
Keybukseb128: can you investigate those ... and check for any remaining build-deps ?06:20
seb128Kamion: oups, I just need to rebuild epiphany-extensions06:20
pittiAs far as I understand, mozilla upstream will move to ffox/tbird in the long run06:20
Kamionthat's all germinate reports, anyway06:20
seb128Keybuk: ok, I'll do06:20
pittiso the question is how long they still support mozilla proper06:20
KeybukKamion: if we drop mozilla from the seed, that's all that holds it in desktop?06:20
Kamionwe still need other stuff from the mozilla source package; evolution depends: libnss3, for example06:21
sabdflyes, i think mozilla is rapidly switching to ffox / tbird06:21
KamionKeybuk: it's not in desktop in the first place06:21
Kamionit's in ship06:21
sabdflif it's a dependency, then it will say in main, so we have to do all the work to support it anyhow06:21
Kamiondropping mozilla-psm from Ship would take mozilla-browser off the CD06:21
sabdflunless we can split out the source package pieces that are really needed for main06:21
KamionI'm not familiar with the consequences of dropping mozilla-psm06:22
Keybukdoes firefox use it?06:22
sabdflis that also used for firefox security?06:22
lamont_rI think so06:22
pittiI think mozilla-psm is not necessary for ffox06:23
sabdflok, maybe pitti can look into whether we can do entirely without that source package in main06:23
pittiat least I did not have it installed, but https:// works in ffox anyway06:23
sabdfland if so, we can drop it06:23
Keybukif we can do without the source, I'm all for dropping it06:23
sabdflelmo, keybuk, Kamion?06:24
=== lamont_r thought moz-psm handled password caching etc, no?
sabdfli thought it did pki stuff06:24
=== lamont_r shrugs
Kamiondropping it from Ship's cool with me if somebody investigates it and finds that it has no effect06:24
lamont_r(perfectly willing to be told I'm dead wrong...)06:24
seb128mozilla-firefox doesn't recommends mozilla-psm, so it's probably not useful06:24
Keybukhm, I don't even have mozilla-psm installed -- and I use https and password cacheing all the time06:25
elmowhat kamion said06:25
pittiit's necessary for mozilla proper to do SSL stuff, but not for ffox06:25
Kamionthat'd recover 10MB or so of space06:25
pittifor translations :-) (SCNR)06:25
sabdfli think we're all in agreement06:25
pittiI'll look into this06:25
sabdflcan we also conduct a check with the user community?06:26
sabdfli think this would be a good start for the "Ubuntu Enhancement Proposal" process we discussed in oxford06:26
sabdflpitti, could you work up such a proposal with mako, and send it to -devel and -users?06:26
Kamionthe proposal should note that we can drop mozilla-browser from the CD without necessarily de-supporting it (as an option)06:27
sabdflit should be posted on the wiki, with room for people's comments below06:27
sabdflright, it could go to main06:27
fabbionesorry guys.. i need to leave for today. Thanks a lot everybody :-)06:27
Keybukfabbione: thanks.06:27
sabdflcheers fabbione, enjoy the new kitchen06:27
fabbionesabdfl: will do :-)06:27
Keybukfabbione: mind out of planes.06:27
pittibye fabbione 06:27
sabdflstay INside planes06:27
Keybukpitti: ok, Thunderbird locale packages ...06:28
pittispeaks for itself06:28
pittithe mozilla-thunderbird-locale-* packages are currently in universe06:28
Keybukthey're in universe now, should we move them to supported/main/etc. ?06:28
pittiI think this is more an accident than deliberate, right?06:28
KeybukKamion: ?06:28
sabdflyes, i think so06:28
pittiI already changed them today to support language packs06:28
Kamionseems straightforwardly correct to move them to main06:28
pittibut if the langpack wants to depend on them, they must be main06:28
=== cenerentola [~cenerento@] has joined #ubuntu-meeting
Kamionput 'em with mozilla-firefox-locale-* in Supported06:29
pittiokay, then this point is already finished :-)06:29
KeybukKamion: agreed.06:29
sabdflKeybuk: next?06:29
Kamionas long as all of them are up-to-date and usable with the current version06:29
pittino, they aren't06:29
pittiKamion: I will mail you which are06:29
Kamionok, pick those that are and seed them, then06:29
pittiKamion: same thing the other way round: many of the ffox locale packages are out of date06:29
pittiKamion: I already have a list06:30
Keybukongoing 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
Kamionnote that those are being aggressively updated/dropped in Debian at the moment06:30
pittiI always wondered why you merge Debian changes against Ubuntu06:30
pittidoing it the other way round would be more straigtforward06:30
Keybukpitti: because it works better about 70% of the time06:30
KamionKeybuk: 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 diffs06:31
pittibut if Debian and Ubuntu hav the same solution, we should prefer the Debian one, right?06:31
KeybukI've put some changes in today so it will try the other way around as well, and favour the one that drops less06:31
pittiah, nice06:31
KamionKeybuk: 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:31
Keybukelmo: ?06:32
Keybukhas rootskell appeared in needs-merged.txt ?06:32
dokothe merges fail for packages with patches inside. Maybe just add a note to the REPORT file, that patch/dpatch files were found.06:32
elmoKeybuk: yep06:32
KeybukKamion: will probably appear tomorrow then06:33
Keybukthere's usually 1-2 days delay between things happening06:33
elmoKeybuk: well not anymore, but it was there when kamion asked about it06:33
Keybuk"not anymore" ?06:33
Keybukoh, right06:33
KamionKeybuk: ah, fair enough06:33
KamionI'm not sure the work/ directories are helpful?06:33
KeybukKamion: 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 so06:33
Keybukyou get work directories?06:34
pittiyes, I already got some of them06:34
Kamionthey've appeared in a number of candidate merged source packages, some people have forgotten to remove them on upload06:34
pittiI just deleted them06:34
pittibut one can forget about this06:34
Kamionthey just have ,,magic-reject files06:34
lamont_rKeybuk: having the unmolested input .dsc/diff.gz would be nice as well, although that's seldom really needed06:34
KeybukKamion: d'oh ... will fix that bug :p  they're supposed to go elsewhere <g>06:34
Kamionwould 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:35
Keybukwell, you can check it out and fiddle with the code to make it do one-shot things06:36
Keybukand you'll need "deb" from06:36
Keybukand "util" from06:36
Keybukany other business?06:37
sabdflnothing from me06:37
KeybukI'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 approval06:38
KamionKeybuk: thanks06:39
=== jdz` [~jdz@] has joined #ubuntu-meeting
Keybukok, thanks very much everybody.06:39
=== ChrisH [~chaas@gw.workaround.org] has left #ubuntu-meeting []
seb128Keybuk: do we have a webcal for hte meetings ?06:40
danielsKeybuk: thanks dude06:40
Keybukseb128: no, they're just every two weeks.  TB/CC on alternate Tuesdays06:40
=== smurfix waves
sabdflthanks all06:40
seb128Keybuk: ok06:41
lamont_rthanks Keybuk06:41
sabdflkeybuk, thanks for sitting in The Chair06:41
seb128thanks Keybuk :)06:41
sabdflcheers all06:41
=== daniels [~daniels@george.kkhotels.co.uk] has left #ubuntu-meeting []
pittihappy hacking, folks06:41
=== babui [~babui@gardeny.udl.es] has left #ubuntu-meeting ["Abandonando"]
dokosee you06:41
=== 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@] has left #ubuntu-meeting []
=== egli [~egli@gate.wyona.com] has left #ubuntu-meeting ["Leaving"]
=== amu [~amu@] 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@] has left #ubuntu-meeting ["Leaving"]
=== haggai [~halls@i-83-67-20-196.freedom2surf.net] has left #ubuntu-meeting ["move]
=== jdz` [~jdz@] has left #ubuntu-meeting []
=== sivang [~sivang@] 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@] has joined #ubuntu-meeting
=== cenerentola is away: I'm busy

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!