#Ubuntu-Meeting

Ubuntu-Meeting Log 2004-11-27

Topic: Technical Board meeting
Agenda: https://www.ubuntulinux.org/wiki/TechnicalBoardAgenda

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


Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!