Ubuntu-Meeting Log 2004-11-??
Topic:Technical Board Meeting - Tuesday 30 November 2004 at 16:00 UTC Agenda: https://www.ubuntulinux.org/wiki/TechnicalBoardAgenda pitti so I copied the ascii file to http://people.ubuntu.com/~pitti/langpacks.txt pitti Hi mdz 05:01 mdz pitti: your agenda item was masked by a markup error, I didn't see it until I tried to edit the page pitti mdz: huh? pitti mdz: it was fine for me 05:01 mdz http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda 05:02 mdz elmo,fabbione,kamion,keybuk,lamont,mvo_,sabdfl 05:03 fabb1one test 05:03 fabb1one ok much better 05:03 Keybuk quite finished? ;o) 05:04 sabdfl hi all 05:04 Keybuk btw, I'd just like to say, for the record, that Cadbury's are evil 05:04 mdz ok, we seem to have a quorum 05:04 pitti Keybuk: what's Cadbury? 05:04 elmo lol 05:05 Keybuk pitti: they make chocolate 05:05 elmo pitti: chocolate manufacturer 05:05 sabdfl pitti: it's a backup weapon to the jellybean 05:05 mdz the only predetermined agenda item is: language packs pitti understands :-) 05:05 pitti mdz: that was me, BTW 05:05 Keybuk (and then feel ill) 05:05 Keybuk :p 05:05 mdz if I'm not mistaken, this is carried over from the last TB meeting :-) 05:05 sabdfl mdz: we had a long discussion during your break 05:05 mdz ...which I have only skimmed 05:05 pitti mdz: yes, I distilled the discussion to http://people.ubuntu.com/~pitti/langpacks.txt and to ubuntu-devel 05:06 pitti however, the discussion on the ml wasn't very active 05:06 pitti so I would like to talk about it here 05:06 sabdfl i have a tech question for pitti 05:06 pitti we don't need to agree about every single detail 05:07 sabdfl if we set the default build process for packages so that english is installed by default by the package 05:07 pitti but we should agree on the general architecture 05:07 pitti sabdfl: this is the default, btw 05:07 sabdfl and had a mechanism so that a local build could install it's own translations for specific locally required languages, overriding the lang pack 05:07 sabdfl would this resolve the conflicts issue? 05:07 sabdfl largely 05:08 pitti sabdfl: you mean if you locally rebuild the debs from the source package? 05:08 sabdfl IOW i imagine someone building the package locally would automatically get (a) english and (b) the languages that their Ubuntu langpacks are installed for 05:08 sabdfl yes 05:08 sabdfl without having to rebuild the langpack 05:08 pitti it should be easy to confine the build to some languages, yes 05:08 Keybuk package would conflict with langpack in that situation, no? 05:08 Kamion isn't it quite important that local builds = our builds by default? 05:09 pitti this essentially means to delete all other languages from /usr/share/locale 05:09 mdz Kamion: yes 05:09 fabbione Kamion: yes 05:09 sabdfl Kamion: they would, in the sense that the deb would include english by default, as would ours 05:09 pitti but this would have similar drawbacks as F5 05:09 Kamion sabdfl: I mean in all senses, i.e. same list of files 05:09 mdz if we're going to do language packs, the language pack should become the central point for translation activity 05:09 Kamion that's really important for developers testing stuff 05:09 pitti I really thought over this issue 05:10 pitti IMHO putting the translations into proper debs leads to nothing but trouble 05:10 sabdfl agreed 05:10 pitti either our archive size or our mirrors explode 05:10 pitti and we become totally incompatible to the rest of the deb-world 05:10 mdz pitti: what do you mean by proper debs? 05:10 mdz e.g., language packs? 05:11 mdz I think there are certainly benefits 05:11 pitti mdz: putting the po files into a real deb (as in the F2 options) 05:11 Kamion pitti: nod - the approach of grabbing stuff straight to /usr/share/locale/ is looking kind of appealing right now, considering all the alternatives 05:11 pitti mdz: vs. managing the po files (and other stuff) aside from debs 05:11 mdz it allows us to safely update translations without touching the package itself 05:11 sabdfl F2-3: we should expect upwards of 200-500 languages within a year 05:11 pitti I still think that F4 is the sanest variant 05:11 smurfix_ pitti: that kills every otion but F4 (and F6 ;-) 05:11 pitti with some ideas from F3-2 05:12 pitti i. e. download new translations to e. g. /var/cache/locale 05:12 mdz pitti: did you make some estimates for disk space requirements? 05:12 sabdfl Kamion: you mean, taking /usr/share/local/ out of dpkg control, and managing it separately? 05:12 pitti and provide this as an alternative gettext root 05:12 Kamion sabdfl: with respect I find that hard to believe, considering 10+ years of free software translation work that have produced maybe 20 languages with plausible coverage 05:12 mdz 200-500 is quite a lot more than any package we currently ship 05:12 pitti mdz: the user would only download the languages and translations that he wants 05:12 sabdfl Kamion, mdz: these are clear goals of ubuntu/rosetta 05:13 pitti mdz: so disk space is minimal, without any deb overhead 05:13 Kamion sabdfl: I know, I'm just saying I find it hard to believe. 05:13 pitti mdz: and overhead of unwanted translations 05:13 Mithrandir pitti: why would F2 include conflicts? Replaces should be enough. 05:13 mdz sabdfl: yes, I'm saying that we need data to know what that would really look like in terms of resources 05:13 sabdfl fair nuff, just so you understand that's why i'm pushing this so hard now 05:13 pitti Mithrandir: I think it's a bad idea to have a language pack replace a complete application deb 05:14 Mithrandir pitti: Replaces: doesn't mean that. 05:14 pitti sabdfl: I do _not_ propose to change anything in /usr/share/locale, btw 05:14 sabdfl what about this? 05:14 Kamion sabdfl: don't think /usr/share/locale/ should be taken out of dpkg's control; pitti's F4 suggests somewhere in /var 05:14 pitti sabdfl: I only want to have additional translatiosn in /var/cache/locale 05:14 sabdfl could we update the ubuntu gettext to look in *two* locations? and take the newer? 05:14 pitti Kamion: yes 05:14 sabdfl language packas would go in /usr/share/langpack/ 05:15 pitti sabdfl: this should be easy for the majority of packages 05:15 mdz gnome-panel has 70 locales totalling 4.2M 05:15 pitti sabdfl: however, we need to manually fix packages which link gettext statically Mithrandir thinks /usr/local/share/locale would be the right place, but that's a detail. 05:15 Kamion avoiding any location that is currently used produces the huge benefit that we do not become instantly incompatible with everyone 05:15 sabdfl then the local build could go into a diff location 05:15 Kamion Mithrandir: it's still distro-managed though 05:15 smurfix_ pitti: that makes sense anyway 05:16 pitti Mithrandir: I would favor /var; /usr might be r/o 05:16 sabdfl the main thing being that the langpack would not put files anywhere a locally built deb would expect to be able to do 05:16 pitti My idea is to have a language pack which controls the downloading and installation 05:16 Mithrandir pitti: depends on where the langpacks comes from -- if they are .debs, then /usr is r/o => you lose. 05:16 mdz I like pitti's idea of treating the two pools of translations separately 05:16 pitti Mithrandir: as I said, I don't think it's a good idea to put updated translations in deb 05:17 mdz but it highlights a question about the overall process 05:17 Mithrandir pitti: why not? 05:17 mdz is our goal that these translations be passed upstream? 05:17 sabdfl mdz: yes, through rosetta 05:17 pitti Mithrandir: I explained in detail in my list 05:17 Mithrandir pitti: how else are you going to make sure that cruft is removed? 05:17 mdz if so, upstream inherits a lot of these problems 05:17 pitti Mithrandir: it's nothing but trouble 05:17 pitti Mithrandir: this must be handled by the download manager (i. e. the language pack) 05:17 mdz their source tarball grows, their default install size grows for source-based installs and for other packagers as well 05:17 Kamion mdz: upstream don't really, Debian does though 05:17 smurfix_ mithrandir: either you have LOTS of debs or your update is a 99% no-op 05:17 pitti Mithrandir: it shouldn't be too hard to sort out cruft in gettext files 05:18 Kamion most upstreams don't seem to care about source tarball size :) 05:18 smurfix_ mithrandir: both is not nice 05:18 sabdfl btw: bazaar 1.0 release in progress now 05:18 Mithrandir pitti: I'm talking about cruft as in "handling languages which are no longer on the system". You would be reinventing dpkg. 05:18 Kamion how about /usr/share/locale/extra/ or something? 05:18 Mithrandir Kamion: do people care about installed-size? 05:18 pitti Mithrandir: maybe, but using dpkg is even worse... 05:19 Kamion would be nice to keep within FHS directories 05:19 pitti Mithrandir: deleting a language pack can just remove /var/cache/locale/<lang> 05:19 smurfix_ mithrandir: it's a somewhat different problem space 05:19 pitti Mithrandir: s/delete/purge/ 05:19 Kamion or at least get this standardised somehow, since it sounds as if everyone will run into death-by-language-bloat soon 05:19 mdz Mithrandir: if installed-size were not an issue, I think language packs would be a non-issue as well 05:19 mdz well, almost 05:20 pitti mdz: there are also troubles with mirrors and pacakge rebuilds 05:20 mdz there would still be the issue of .deb size 05:20 pitti mdz: installed-size of language packs is the least evil point 05:20 Mithrandir mdz: I'm asking whether it's really an issue or whether we just have a bunch of whiners who can be ignored. (To be harsh) 05:20 mdz Mithrandir: any whiners are hypothetical at this stage 05:20 Kamion Mithrandir: CD size is pretty hard and fast 05:20 mdz we're extrapolating what would happen if the number of translations exploded 05:20 smurfix_ kamion: teaching dpkg to basically ignore some directories should be reasonably simple 05:21 mdz smurfix: that would only address installed-size, and not .deb size 05:21 Kamion smurfix_: that approach is pretty fragile and hard to reconfigure later though 05:21 Kamion and, as mdz said 05:21 pitti smurfix: why you want to do that? 05:21 sabdfl easy, Mithrandir 05:21 Kamion smurfix_: if somebody says "please can I have French translations now", you have to reinstall everything 05:21 Mithrandir sabdfl: I didn't intend to stomp on any toes -- I was wondering if we were discussing a real problem or not. :) 05:21 mdz we are 05:22 mdz though we are trying to discuss it before we actually have it 05:22 pitti Can we at least agree to drop the F2 options? 05:22 sabdfl in terms of where i would like ubuntu to be in two years time, which is much more widely translated than rhat, suse or debian, yes this will be a real issue 05:22 pitti i. e. extract translations during build into separate debs? 05:22 smurfix_ kamion: assuming that the files can't be downloaded from rosetta-or-whatever 05:22 sabdfl fine by me 05:23 mdz wait 05:23 mdz F2 are the only options which address the problem of .deb size 05:23 mdz oh, also F5 05:23 sabdfl our build process will have to be different 05:23 pitti mdz: ? 05:23 Mithrandir mdz: F5 means the shipped debs are different from what you get from apt-get -b source $package, though. 05:24 sabdfl in that we will not include the translations in a default .deb build 05:24 mdz Mithrandir: yes 05:24 mdz F5 has big problems in terms of package management 05:24 mdz but it does address the problem of .deb size 05:24 Mithrandir pitti: F3, F4 doesn't shave any size off the shipped debs. 05:24 pitti mdz: the point is that _anything_ using debs created by us makes troble 05:24 elmo F4 could be combined with a stripping 05:24 Mithrandir pitti: which we want to do, in order not to hit the 650MB limit. 05:24 mdz we could do a slight modification of F5 which results in having the same .debs in the archive and on the CD 05:24 elmo F4+strip down to English +whatever we can fit is by far the most sane option IMHO 05:25 pitti Mithrandir: yes, but _we_ have to create debs regularly 05:25 mdz local builds break 05:25 pitti Mithrandir: as opposed to F4, when the _user_ decices when to download what 05:25 Kamion sabdfl: I really think patching the source packages is the only correct way to modify the build process 05:25 sabdfl Kamion: yes, i expect that 05:25 pitti Mithrandir: this simplifies both building and downloading a lot 05:25 Mithrandir Kamion: I agree with you on that. 05:25 Kamion sabdfl: ok, good, alleviates my major concern :) 05:25 mdz sabdfl: based on our experience so far with merges, that would be a prohibitively large workload for our team 05:26 elmo mdz: okay, F4 +strip in binary and source 05:26 pitti Kamion: but I think if we can manage without patching source packages at all, this would be even better 05:26 mdz patching every source package is not an option for us 05:26 smurfix_ elmo: why both binary and source? Agreeing on either makes more sense imho 05:27 mdz elmo: hmm 05:27 Kamion mdz: the fact that a source package specifies what goes into its binary packages is an invariant; breaking that just for scheduling reasons is so wrong 05:27 elmo mdz: it's not every source, nly what's on the CD 05:27 elmo we can't not patch what's on the CD if you want local builds to work, AFAICS 05:27 Kamion if we're going to modify the build process then that change must be in Ubuntu 05:27 Kamion (i.e. not buildds) 05:27 mdz elmo: I think I like that very much 05:27 elmo smurfix: eh? the binary have to be modified to get the space down, the source has to be modified, if you want a local rebuild to procue an installable .deb 05:27 smurfix_ I'd prefer mangling the binaries when they arrive from the autobuilder. 05:27 mdz (F4 + stripping) 05:28 Kamion smurfix_: so wrong, so wrong 05:28 mdz that avoids the conflict issues with local builds 05:28 pitti Am I right that stripping and F4 are actually completely orthogonal? 05:28 Kamion think I agree with elmo here 05:29 pitti so we can discuss that independently? 05:29 Mithrandir mdz: and then leaving /var/cache/locales non-dpkg-managed? 05:29 mdz pitti: yes 05:29 mdz good plan 05:29 mdz we can decide separately how to best remove translations from .debs, and how to provide the translations separately 05:29 smurfix_ elmo: why would a local rebuild create a conflict? 05:29 mdz the former is the difficult bit 05:30 Keybuk stripping how? 05:30 mvo_ I think the later is tricky too :) 05:30 Kamion mdz: adding dh_striplocales (say) to debian/rules wouldn't be that bad, would it? 05:30 Kamion if it's a one-liner ... 05:30 Keybuk at buildd-time, or in the source package? 05:30 elmo smurfix: oh, okay, it wouldn't necessarily, but it wouldn create a different .deb, and there's a lot to be said for idempotency of builds 05:30 Mithrandir Kamion: aka rm -rf debian/$packagename/usr/share/locale ? :) 05:30 sabdfl it should be a one-time one-liner 05:30 pitti mdz: stripping binary debs is easy, but stipping source packages? We have to change every orig.tar.gz... 05:31 Kamion pitti: and then various upstream projects will accuse us of forking 05:31 pitti Kamion: how would that help to reduce the source package size? 05:31 Kamion (c.f. openssh) 05:31 Keybuk Kamion: the bit where it would go doesn't tend to change hugely -- though it'd trip on a major change to debian/rules and need manually fixing 05:31 Kamion Keybuk: yeah, but it should be mostly automergeable 05:31 Keybuk 9/10 times 05:31 Keybuk maybe 99/100 too 05:31 sabdfl pitti: source package size is not the issue 05:32 pitti elmo: do you actuallly mean "strip the source package" or "strip during building the debs from the source package"? 05:32 Kamion sabdfl: source CDs are a reality, various people want them 05:32 elmo pitti: latter 05:32 pitti sabdfl: ah, okay. I misunderstood 05:32 pitti elmo: okay, that's easier 05:32 mdz Keybuk: is it feasible to detect the case where we _only_ made this change, and fast-track it? 05:32 elmo kamion: point them at > 650Mb ISOs, what do we care? 05:32 sabdfl Kamion: they can be multi-cd sets 05:32 Keybuk mdz: yah 05:32 sabdfl dvd 05:32 Kamion sabdfl: they're already 3 CDs 05:32 Kamion sabdfl: turning them into 30 seems a bit non-trivial 05:32 sabdfl true :-) 05:32 Kamion (3 CDs for hoary as it stands) 05:32 elmo Kamion: don't you like a challenge?? 05:33 Kamion elmo: depends how fast you want auckland's disk space used up 05:33 mdz last I heard, we weren't hurting for disk space 05:33 Keybuk mdz: wish we were based on darcs rather than arch now though :p could have a "add dh_striplocales before dh_builddeb" change token :p 05:33 sabdfl ok, girls, focus ;-) 05:33 Kamion mdz: we will be if daily CD builds multiply by ten in size 05:33 mdz Kamion: I don't think we quite need _daily_ source CDs 05:34 Kamion mdz: we already have them, 'cos building CDs daily is about the only sane way to make sure they keep working 05:34 pitti before we discuss the details, is there anybody who thinks that strip+separate download is _not_ the solution? 05:34 sabdfl i don't think we need to keep them around though 05:34 mdz Kamion: if it's only as a test, we can throw away the result if the space become sa problem 05:34 mdz what sabdfl said 05:34 Kamion mdz: true 05:34 Mithrandir pitti: I wish they are handled by dpkg, but it seems people disagree with that, so. 05:35 mdz so, considering that we must remove translations from .debs in order to maintain the One True CD, I think we only have two options for the "remove translations from .debs" piece 05:35 mdz (source or binary) 05:35 pitti Mithrandir: if you find a way to sanely handle translations in deb, tell it to us :-) 05:35 sabdfl +1 source 05:35 mdz source is more correct in every way from a pure technical perspective 05:35 pitti Mithrandir: I would prefer proper debs from a cosmetic viewpoint too 05:36 pitti mdz: binary is easier, but source cleaner 05:36 Kamion source => change source package, binary => adjust binary package after build? 05:36 mdz Kamion: correct 05:36 Mithrandir pitti: they are just a bunch of files. Wrap them up in a deb; make a daily deb of all the files for a language if you so desire. 05:36 Keybuk source++ 05:36 Kamion definitely +1 source inasmuch as I don't get a TB vote 05:36 Keybuk Mithrandir: "Dear Mirrors, hello, here's SOME DEB" 05:36 pitti Mithrandir: either the mirrors or the number of debs would explode 05:36 mdz however, source thrusts us into a situation of having modified several times as many packages as we currently do 05:37 smurfix_ hmm, if source, how do the stripped-off translations end up where people can download them? 05:37 mdz so it is dependent on a greater level of merge automation 05:37 Mithrandir Keybuk: one per language; the biggest language on my system is french, that is about 8MB, compresses down to about 2.7MB. 05:37 Keybuk mdz: from 233 to "all of them" ? 05:37 pitti mdz: we can modify debhelper to do it automatically 05:37 pitti smurfix: but them into rosetta, I think 05:37 mdz some have claimed that we would only modify the packages on the CD 05:37 Keybuk Mithrandir: 200 languages, every day, half a gigabyte to each mirror each day 05:37 mdz which I think would be about 3x as many packages as we currently modify 05:38 Mithrandir Keybuk: only build if they have changed that day, then. 05:38 Kamion I think modifying dh_builddeb or something around that level in Ubuntu might be just about acceptable 05:38 Mithrandir Keybuk: I doubt we'll have changes to each language each day. 05:38 Kamion although it's a bit worrying 05:38 Keybuk Mithrandir: we upload source every day, leading to a language-pack change every day, for every language 05:38 mdz Kamion: except for non-debhelper packages 05:38 mdz Kamion: do you feel the same way about modifying dpkg-deb? ;-) 05:38 Kamion mdz: yeah, pretty trivial number though 05:38 Kamion mdz: I feel deep abhorrence for that idea; layering violation 05:38 Mithrandir Keybuk: I thought translations were to be handled completely in rosetta? 05:39 mdz Kamion: I agree, fwiw 05:39 pitti Mithrandir: but you will have a daily change in at least one package, which would trigger a rebuild of the whole langpack 05:39 Kamion debhelper is allowed to know about details of Debian policy as regards package layout; dpkg-deb is just an archiver 05:39 Mithrandir pitti: uhm, why would that be? 05:39 Kamion so s/Debian/Ubuntu/ and it looks barely tolerable 05:39 Kamion the problem is that that would break rebuilds of Debian packages 05:39 Kamion which would be a bad thing 05:39 elmo WRT debhelper, why don't we just declare it build-essential for us, then we can dh_strip_locale to any package even if it doesn't use debhelper? 05:39 pitti Mithrandir: if you have one deb per language, it just is like this 05:39 mdz Kamion: how so? 05:39 mdz I think all source-based solutions share that problem 05:40 pitti Mithrandir: if you have one deb per language per package, the number of debs explodes 05:40 Kamion mdz: no they don't, modifying our source packages doesn't 05:40 Kamion i.e. our source packages say what we want them to do 05:40 mdz Kamion: the source package modification doesn't make it into Debian 05:40 mdz you said rebuilds of Debian packages 05:40 pitti mdz: I wouldn't change dpkg-deb, only debhelper 05:40 Kamion mdz: uh-huh, but people rebuild Debian packages on Ubuntu 05:40 Mithrandir pitti: I'm talking about one deb per language. And if we do get 200 languages, well, then we have half a gig extra data to push. 05:40 Kamion mdz: e.g. backports 05:41 elmo Mithrandir: dude, please read the logs for the last meeting, we went over this TO DEATH 05:41 Kamion if some maintainer script in a Debian package does stuff to /usr/share/locale (and I believe some of them do), there'd be hell to pay 05:41 Keybuk yeah, I think some people would panic if I uploaded dpkg with all the translations stripped out 05:41 pitti Mithrandir: you have to push half a gig for _every_ language every day 05:41 Mithrandir elmo: ok 05:41 Keybuk I vote for dh_striplocales 05:41 Keybuk or dh_stripmessages 05:41 pitti Mithrandir: right now my /usr/share/locale is about 200 MB, but that will increase 05:41 Mithrandir pitti: /query? 05:41 Kamion Keybuk++ 05:41 mdz ok 05:42 pitti Mithrandir: ? 05:42 mdz so the broad solution of "modify the source package" seems to be favoured 05:42 smurfix_ kamion:not if we modify gettext and put the rosetta translations somewhere else 05:42 mdz within that solution, we have some choices 05:42 mdz - modify debian/rules 05:42 mdz - modify a debhelper tool (and, if debhelper is not used by the package, debian/rules also) 05:42 mdz - others? 05:42 pitti mdz: + modify rules 05:43 Kamion - add a debhelper tool to simplify the modification of debian/rules 05:43 fabbione - something that is absolutely shared by every package? 05:43 pitti mdz: least surprise 05:43 mdz Kamion: let's consider the debian/rules option under the assumption that we'll make the change trivial 05:43 mdz by whatever means 05:44 mdz fabbione: the only thing that falls into that category is dpkg-deb, and that's been declared evil 05:44 fabbione mdz: aren't we? ;) 05:44 mdz modifying debian/rules is going to mean adding a build-dependency as well 05:45 mdz in order to guarantee a consistent result 05:45 Keybuk mdz: or modifying build-essential Kamion could live without the build-dep for the purposes of expediency ... 05:45 mdz hmm, even to guarantee that it builds 05:45 mdz modifying debhelper lets us forego the build-dep 05:45 Kamion upload debhelper, wait for elmo/lamont to install it in all chroots, upload everything else 05:45 mdz if it's built with a debhelper that doesn't contain the change, they just don't get a stripped package 05:45 elmo modify build-essential .. 05:46 Kamion if we add a new debhelper program then the build will fail if it's missing 05:46 Kamion which is good enough 05:46 mdz hmmm 05:46 mdz and then the user is left scratching their head over why the package doesn't build 05:46 fabbione lamont will kill somebody just the amount of mails he will get :-) 05:46 elmo we need to ensure that if a user does 'apt-get build-dep gnupg', and tries to build ubuntu's source, it'll work 05:46 Kamion mdz: hoary'll ship with this modified debhelper presumably 05:46 elmo the only way to guarantee that is to modify our build-essential 05:47 mdz we'd break building Ubuntu debs on Debian, unless our debhelper change goes upstream 05:47 Kamion we could even ask joeyh to include the tool in mainstream debhelper 05:47 elmo we could (haha) || true it, or enclose it in a if [ -e ... ] type test 05:47 mdz I think he'd accept the dh_striplocales variety 05:47 Kamion mdz: we've already broken building a lot of Ubuntu .debs on Debian mind you 05:48 pitti Kamion: essentially it would just throw away any po files, right? 05:48 mdz perhaps not the dh_builddeb variety 05:48 Kamion mdz: plenty of them require Ubuntu-specific build-deps 05:48 mdz Kamion: really? 05:48 Kamion I think dh_striplocales is more correct anyway 05:48 Kamion mdz: sure, take GNOME 05:48 mdz I thought there were quite few of those 05:48 Kamion mdz: or our d-i 05:48 mdz d-i, sure 05:49 mdz Keybuk: didn't you have some numbers on how many packages don't use debhelper in warty/main? 05:49 Kamion might be worth ignoring all packages without translations 05:49 haggai I think you should try to find a solution that is upstreamable so that co-operative Debian maintainers can add the tool call to their source to reduce the debian->ubuntu diff 05:49 mdz 745/1022 I it looks like 05:49 mdz Kamion: I think the plan is to translate those, too :-) 05:49 Keybuk mdz: yeah, it came down about 30 don't 05:50 sabdfl we have a hard limit at this stage on those which don't use gettext at all 05:50 Kamion mdz: how about the ones without strings? :) 05:50 mdz 745/1022 have a build-dep on debhelper 05:50 elmo wow, that's less than I expected 05:50 Keybuk mdz: build-dep-indep too 05:50 sabdfl ok, i think we have an emergin consensus 05:50 mdz grep-dctrl -FBuild-Depends,Build-Depends-Indep -nsPackage debhelper 05:50 mdz 745 05:51 Keybuk mdz: grep-dctrl in hoary is broken 05:51 mdz oh, sweet 05:51 Keybuk grep-dctrl -s Package -FBuild-Depends,Build-Depends-Indep 05:51 Keybuk debhelper /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_source_Sources 05:51 Keybuk | wc -l 05:51 Keybuk 952 05:51 Keybuk Actually it catches over 90%, and of the remaining 98 packages only 28 05:51 Keybuk contain translations anyway (using the "does it depend on gettext or 05:51 Keybuk po-debconf" test). 05:51 pitti sabdfl: I think so too, since the guys are already talking about specific details 05:51 Keybuk -- 05:51 pitti sabdfl: but I think the general strategy works and is the sanest one 05:53 mdz given some magic which saves us from the crushing merge workload, the preferred solution for stripping locales is a dh_striplocales one 05:54 pitti agreed 05:54 sabdfl ok, next! 05:54 mdz can we really take that for granted at this stage? 05:55 mdz language packs are a hoary goal 05:55 mdz this level of divergence almost requires that we can put most of these merges on full automatic mode 05:55 mdz including the upload 05:55 sabdfl mdz: let's evaluate that after the first week of Mataro Sessions 05:56 sabdfl we'll have a handle on hct at that point 05:56 Keybuk hct doesn't help any more than mom 05:56 Keybuk a little less, in fact, because it requires tla/baz to play nice 05:56 elmo it's worth noting, that we're not running out of space yet either, so they may be a goal but they're not a 100% we can't ship without this 05:56 sabdfl yes 05:56 mdz elmo: however, it is a high priority item on Mark's hoary list 05:57 Keybuk mom works by breaking apart, mutating and driving patch itself 05:57 mdz which is fairly close to the same semantics 05:57 Keybuk we don't get that power with arch 05:57 Kamion (we have 55MB free on the powerpc CD, which is tightest) 05:57 mdz Kamion: and we need to get a ppc64 kernel image onto it :-/ 05:57 mdz Keybuk: yet :-P 05:57 Kamion mdz: should be OK ... 05:58 mdz that'll eat about 15M 05:58 mdz guestimating from the powerpc one 05:58 Kamion mdz: depends which of powerpc/power3/power4 we need 05:58 Kamion (can we bounty benh to fix the MMU crap that means we need those three? :-/) 05:59 elmo can't we pay/beg/bribe/hold hostage someone to get rid of the stupid sub-arch split... doh 05:59 mdz ok, so regarding stripping locales, we're fairly settled on dh_striplocales, on the assumption that Keybuk can provide the level of support we need for the merges 05:59 pitti sabdfl: is there actually a "next" item on the list? 05:59 mdz Kamion: let's talk about that a bit later 06:00 mdz Kamion: doesn't sound unreasonable at first hearing 06:00 mdz pitti: yes 06:00 mdz the second half is the approach for providing the translations in separate .debs 06:00 mdz it sounds like we were moving in the following direction there: 06:01 mdz - buildds collect the translations via dh_striplocales and drop them into a pool 06:01 mdz - some automated process runs periodically and builds .debs from the pool 06:01 elmo debs are crack for this 06:01 mdz - the .debs contain translations in some directory which is not /usr/share/locale 06:01 mdz oh? was that decided at the last meeting? 06:01 elmo I dunno, I'm just saying what I think 06:02 mdz ok, s/\.debs/language packs/ for now 06:02 pitti mdz: My idea is to have language-support-XX manage the download, install, and housekeeping 06:02 pitti mdz: but not stuffing the po files into a deb itself 06:02 mvo_ I think the problems reamins the same whatever format we use 06:02 pitti a reasonable compromise would be to build a deb on the fly on the user's machine 06:02 mdz pitti: I think that introduces much more complexity than we want 06:03 pitti mdz: but if we push debs, we have all these problems 06:03 mvo_ if we don't use deb we need to have package manager like functionality in a language-pack-get tool 06:03 pitti mdz: assembling debs on the fly on user's hosts seems much more sane then 06:03 Mithrandir pitti: I'm not too comfortable with that -- l-s-xx needs to be able to acquire, unpack, record what's installed and uninstall the files later. 06:03 mdz pitti: I think that has the same problems 06:03 pitti mvo_: but only downloading, copying and cleaning 06:03 mdz there is a lot of value in having a language pack blob which actually contains the translations 06:03 pitti Mithrandir: why record? 06:03 mdz which can be placed on the CD, passed around by the user, etc. 06:04 Mithrandir pitti: it needs to know what it has installed so it knows what it should update. 06:04 pitti mdz: but the whole point of all this is to avoid debs in the first place 06:04 pitti at least debs we provide on our mirrors 06:04 Mithrandir elmo: you think .deb files are insane because of the mirror load? 06:04 mdz it is? 06:04 Mithrandir elmo: or anything else too? 06:05 elmo Mithrandir: Packages files are useless for them and too large 06:05 elmo and yes, I don't desperately want them in the pool proper 06:05 pitti Mithrandir: not only because of the mirror load, also because of the download redundancy 06:05 pitti The user should be able to download only the translations for packages he actually uses 06:05 mdz elmo: don't desperately want, or desperately don't want? 06:05 haggai could new functionality for registering conffiles etc with dpkg (Keybuk?) be used to register new translations with the dpkg database? 06:06 mdz pitti: what it sounds like you're describing is a .deb which can't be installed without access to <someplace>.ubuntu.com 06:06 pitti mdz: ? 06:06 mvo_ when will he download them? will he need to do a apt-get upgrade and a lang-pack upgrade? 06:06 mdz pitti: <pitti> mdz: My idea is to have language-support-XX manage the download, install, and housekeeping 06:06 pitti mdz: l-s-XX would download the translations, create a deb and isntall it 06:06 mdz pitti: correct 06:06 Mithrandir mvo_: think install from cd, for instance. 06:06 pitti mdz: you need access to Rosetta, right 06:06 elmo mdz: depends what format the debs are, one per source or one per lang? 06:06 mdz that means that installing l-s-XX would require that the target system be able to talk to <someplace>.ubuntu.com 06:07 elmo mdz: the latter can be over my dead or P45-ed body 06:07 pitti mdz: but you need that anyway to get _any_ update 06:07 mdz which, in a wide variety of environments, just won't be true 06:07 Keybuk haggai: doesn't work, conffiles still need a replaces:/--force-overwrite 06:07 pitti mdz: building the deb can happen on the client 06:07 smurfix_ mithrandir: so the files are on CD instead of being downloaded 06:07 elmo mdz: the former.. I'm pretty unhappy about too, but I'd need to look at proper stats to be sure 06:07 mdz pitti: that isn't true, users have lots of ways of moving around .deb files 06:07 mdz pitti: the user needs to be able to insert a CD and obtain a language pack that way 06:07 pitti mdz: they can build the deb on a place with net access 06:08 haggai Keybuk: I didn't mean that. I meant, the ability to register a new file with the language-support deb 06:08 pitti mdz: they can as well just copy the po tree to their computer (with the help of l-s-xx) 06:08 mdz pitti: this defeats the purpose of providing a plug-and-play language pack 06:09 mdz what is the problem that we would hope to solve with such a solution? 06:09 pitti mdz: I still don't understand the problem 06:09 mdz large downloads for people tracking the development branch? 06:09 pitti mdz: where the deb is built, or who does it makes no difference 06:09 mdz pitti: the problem is that it's essentially an installer .deb, and installer .debs are inherently problematic 06:09 pitti mdz: we can put it onto a CD as well 06:09 sabdfl we can accept a certain lag during the freeze 06:09 Mithrandir mdz: large downloads for people who are running stable but want updated translations, I think. 06:09 sabdfl so, say, langpacks are updated weekly rather than daily 06:10 mdz sabdfl: right 06:10 mvo_ sabdfl: sounds good too me 06:10 sabdfl i think elmo is right that there are benefits to avoiding the pool altogether for this 06:10 mdz and we can provide a separate repository with daily updated language packs for those who really want them 06:10 pitti guys, it is just insane to publish translation debs in regular intervals 06:10 smurfix_ why do we need .debs anyway? 06:10 sabdfl as is mithrandir in that it's a small step towards reinventing dpkg :-) 06:10 mdz if the problem is that the .deb is too large, we break it up 06:10 Mithrandir .. you know, dpkg started out as a perl script. We could reinvent it in python. 06:10 sabdfl but... fundamentally, a langmgr on an ubuntu desktop needs to keep track of the languages that desktop needs, and sync in the data 06:10 pitti let the user choose which translations he want, at which intervals and give him an easy way to update his system with a "pull" strategy 06:10 sabdfl it might even use rsync! 06:11 Kamion Mithrandir: actually it was a shell script before that ... 06:11 Kamion (IIRC) 06:11 mdz sabdfl: why does it need to do that? 06:11 Keybuk you could always use the deb + delta idea ... 06:11 pitti mdz: what do you mean by installer deb? 06:11 mdz sabdfl: the user selects their languages, and from that point forward it's a simple upgrade 06:11 mvo_ Keybuk: +1 06:12 mdz pitti: a .deb which doesn't contain the data that it is meant to provide, but instead downloads it over the network (or requires that the user do so) 06:12 pitti mdz: with per-package debs or per-language? 06:12 mdz Keybuk: not for hoary we can't 06:12 sabdfl mdz: you mean, if we have an ubuntu-xx langpack in the pool? elmo hates that idea, and he's bigger than me, and i happen to agree with him 06:12 pitti mdz: you can also install readymade translation debs 06:12 mdz sabdfl: I'm going to go out on a limb and ask him to justify his hatred :-P 06:12 mdz sabdfl: you, too, if you agree 06:12 pitti mdz: it should be _possible_ to assemble them on the fly, not required 06:12 sabdfl the langpack debs will drive the mirrors crazy 06:13 sabdfl we can publish the translations as an rsyncable tree 06:13 Mithrandir sabdfl: if they're only updated when they need to, or weekly or something as well? 06:13 mdz as I said 06:13 mdz if the problem is that the .debs are too big 06:13 mdz then we break them up 06:13 elmo mdz: it's utter crack. if you change one translation in one source package, this n hundred Mb unrsyncable (and not normally rsynce danyway) .deb changes 06:13 sabdfl then dpkg/apt need to scale to more debs than they should have to 06:13 Mithrandir mdz: then you get a huge amount of them. 06:13 Kamion mdz: doesn't help, lots of them will generally change at once 06:13 pitti ARGH 06:13 mdz depends on how you break them up 06:13 pitti this is the very same discussion we had last time 06:14 Kamion mdz: either you have a source message which changes and lots of translations change, or you have a common translation of a frequently occurring string that changes 06:14 Kamion mdz: you can't win either way 06:14 elmo pitti: yes, I know. let's petition sabdfl to not let mdz go on holiday and miss TB meetings ;-) 06:14 pitti pushing debs to mirrors is crack 06:14 sabdfl elmo: only if you promise not to go on holiday too ;-) 06:14 smurfix_ I agree with sabdfl. Just use rsync and ignore all files belonging to packages you don't have installed. Problem solved. 06:15 pitti smurfix: when using /var/cache/locale, we don't even have the possibility of hitting pacakge conflicts 06:15 sabdfl smurfix_ it's easier than that, since the desktop install generally installs a solid well-defined set of packages 06:15 sabdfl we only do this for those 06:15 mdz I think you guys are optimising for the development branch case 06:15 mdz when we need to optimise for the stable release case 06:15 sabdfl yes, understood 06:15 mdz these problems are non-issues for the stable release 06:15 pitti mdz: you cannot force users to download huge amounts of debs for small translation changes 06:16 Mithrandir sabdfl: you'd need to ship something to rsync off on the cd, then. That is a lot more work than shipping one more deb. 06:16 pitti mdz: s/cannot/it wouldn't be the best solution/ 06:16 sabdfl but i /really/ dislike the idea of switching something this big on only at release time, we discussed that last time 06:16 elmo mdz: dude, this is not "optimization", this is "having a mirror network vs. not" 06:16 smurfix_ pitti: exactly. local packages use /usr/share. So check there too, and pick the newer one. 06:16 elmo mdz: if we implemented this with even the number of languages/translations we have today, we'd have zero mirrors within a month 06:16 elmo hell, _I_ wouldn't mirror us over the GB LAN :-P 06:17 sabdfl elmo: i love how you tell the truth :-p 06:17 smurfix_ mithrandir: so park the rsync-master file tree onto the cd ..? 06:17 mdz elmo: ok, I understand. let's try to change our approach to adapt to that, rather than throwing it away 06:17 Mithrandir smurfix_: have you touched debian-cd? 06:17 Kamion smurfix_: er ... uh-huh. 06:17 mdz I'll say again that this is strictly a development branch issue 06:17 Mithrandir smurfix_: doing that would be very icky and interesting. 06:17 Mithrandir smurfix_: I do not think Kamion would like you afterwards. :P 06:17 pitti mdz: so we need a system that is both able to install premade language debs, prepare these and also update directly from the network 06:17 mdz and I do not think that we should sacrifice having the feature look the way it should in the final release 06:18 Mithrandir mdz: I'm worried that elmo is so much against it, though.. 06:18 smurfix_ kamion: On the language-pack CD of course. Maybe packaged inside a cpio tree if too many small files are too icky. 06:19 Kamion smurfix_: I think all this is highly premature 06:19 Mithrandir smurfix_: that sounds like you're reinventing rpm rather than dpkg, then. 06:19 mdz Mithrandir: the issues that elmo raises apply only to the development branch, and I think the use case is different enough that we may need to solve the problem in two slightly different ways 06:19 Mithrandir mdz: mirrors mirror all, though 06:20 Kamion smurfix_: language pack CD structures aren't something we've even started to think about yet, and I'm not convinced that they're something we ought to be generating centrally anyway 06:20 pitti mdz: why, if stable users should be able to download their daily translation updates as well, it affects stable too 06:20 mdz we are not going to force a huge delta increase on mirrors 06:20 Kamion better to give people an easy way to build an Ubuntu CD for their language 06:20 elmo mdz: dude, it's not just the development branch. what about a security update that changes a translation? 06:20 mdz the sky is NOT falling 06:20 mdz elmo: they don't 06:20 elmo bullshit 06:20 elmo you've uploaded new upstream versions before - it's rare, but it happens 06:20 Kamion mdz: also security issues exist in translations; consider format string errors 06:21 mdz if we have a clusterfuck like that, we put the changed translations into the security update .deb 06:21 smurfix_ Well, I'm brainstorming on "how could this work" rather than "how do we make .debs to make it work", so ... 06:21 elmo mdz: and what Replaces: the langpack? 06:22 Kamion and if the langpack is a .deb we then run into the non-commutativity of Replaces: 06:22 Kamion (muttermutterdpkgbugsmuttermutter) 06:22 mdz elmo: uses a different path 06:22 Mithrandir versioned conflicts with the broken version of the langpack. (Yes, it's broken, but it works-ish) 06:22 elmo mdz: and how do apps know which to use? 06:22 Kamion Mithrandir: urgh 06:22 Kamion Mithrandir: yay for removing langpacks while upgrading packages 06:23 mdz elmo: they prefer the one provided by the package, if present (generally not) 06:23 Mithrandir Kamion: doesn't apt/dpkg DTRT and upgrade? 06:23 smurfix_ ... or the one timestamped newer. 06:23 elmo mdz: that technology exists for locales already? 06:23 mdz elmo: if it doesn't, it seems completely trivial to implement 06:23 Kamion Mithrandir: not if an updated langpack isn't available yet 06:24 Mithrandir Kamion: then we have to make sure it's available. (Yes, I know that's not trivial either) 06:24 Keybuk Mithrandir: dpkg does not upgrade on << conflicts. 06:24 Mithrandir Keybuk: what about apt and dselect? 06:25 mdz Mithrandir: depends 06:25 elmo mdz: *shrug* ok then. so how/when do you propose to transition to the stable model as part of the development process? 06:26 mdz depends on how we approach the development-branch model 06:26 elmo I still think you're trying to fit a square into a round hole, 'cos the round hole is familiar and looks pretty, but that's probably just me 06:26 pitti err, what is our "stable model"? and why it should be any different from the development one? 06:26 mdz pitti: put yourself in end-user mode for a moment and consider the problem 06:26 mdz "I want my Ubuntu to speak <language>" 06:26 pitti mdz: stable versions do not have any fewer updates than unstable ones 06:26 elmo oh, hang on 06:26 elmo mdz this doesn't work 06:27 mdz what's "this"? 06:27 elmo mdz: one of the reasons for all this crack, is sabdfl's desire to have translation updates out of bound 06:27 elmo i.e. in stable, still get translation updates 06:27 pitti mdz: apt-get install l-s-<language> with a net connection works 06:27 elmo so there is no stable model 06:27 pitti mdz: if you don't have a net connection, make it easy to copy the files from another host which has 06:27 pitti mdz: but that is orthogonal to the particular solution anyway 06:28 Mithrandir elmo: push updated translation-debs to warty-updates once a week? 06:28 mdz pitti: "you must have Internet access in order to do that, otherwise use this manual process"? 06:28 sabdfl mdz: what elmo said. but not about the pretty familiar round hole 06:28 mdz that answer won't fly for a lot of deployments 06:28 pitti mdz: how do you want to download stuff without net? 06:28 pitti mdz: it doesn't matter if you download debs or po file tarballs 06:28 pitti mdz: "you" == the language pack which manages the stuff 06:29 mdz sabdfl: what's the basis for updating stable with new translations, as opposed to doing the translations as part of the freeze process, as GNOME does? 06:29 elmo Mithrandir: that has the "mirror admins lynch you" problem all over again 06:29 Mithrandir elmo: yes, that might be a slight problem. 06:29 sabdfl mdz: reality 06:29 mdz pitti: there is a big difference between a packaging system which downloads packages, and a package which downloads .po files 06:29 Mithrandir pitti: we end up having to reinvent dpkg to grab the translations off $MEDIA 06:29 pitti mdz: we can include the current language snapshots on the CD too if we want 06:30 mdz pitti: you open yourself to a lot of site-specific problems 06:30 mdz outbound access policy, proxy authentication, ... 06:30 pitti mdz: but we can use debs to hold the actual updates 06:30 mdz pitti: and have the package copy them from the CD when it's installed? 06:31 mdz then suddenly you need to implement this in apt 06:31 pitti mdz: the point is not to avoid debs, but to avoid building and pushing them to our servers regularly 06:31 pitti mdz: as I said, you can assemble the debs either on the fly or use premade ones 06:31 Mithrandir would having a separate repository for translations be complete crack? 06:31 mdz if it's a problem for them to be pushed to the mirrors regularly, then may I make the bold suggestion that we, well, don't push them to the mirrors regularly? 06:31 pitti mdz: create them on the fly in rosetta? 06:32 pitti mdz: when an user wants to update his translations? 06:32 elmo mdz: or how about this for a bold suggestion: don't insist on sticking with a format that's so inflexible we can neither split them up, nor ship them in one big lump, and that way get to ship them as often as we want 06:32 mdz pitti: what would the system look like which would decide whether to create a .deb or use an existing one? which piece of the package management system would it inhabit? 06:33 mdz what is the proposed alternative transport format? a few million .po files? 06:33 smurfix_ mdz: million? 06:33 pitti mdz: ^ that is actually the most flexible one 06:33 pitti mdz: the user needs to download exactly the po files he needs, nothing else 06:33 elmo per-source or per-binary package lumps of .po files is an alternative too 06:33 pitti mdz: but still, having deb as transport format is not a bad idea on itself 06:34 mdz smurfix: O(packages*languages) 06:34 mdz which is O(thousands*hundreds) at least 06:34 pitti mdz: the bad idea is not the deb format, but to include the debs into our normal archive structure 06:34 mdz elmo: how exactly is a per-source or per-binary lump of .po files better or worse than per-source or per-binary .debs? 06:34 pitti mdz: re your first question: the deb would be recreated if the user presses "update language" 06:35 pitti mdz: of course with network access 06:35 elmo mdz: by definition, they wouldn't be in the pool or bloating the Packages files 06:35 pitti mdz: alternatively the user can install an updated deb from somewhere else 06:35 mdz elmo: instead, they would be in a separate "pool" with its own index file and bloat that? 06:35 smurfix_ mdz: end users won't see that many files and mirrors can use more scalable distribution methods if necessary. 06:35 elmo mdz: if you use .debs, yes :P 06:36 mdz elmo: or anything else 06:36 pitti mdz: if you download po files direcly, there is no need for index files at all 06:36 mdz storing the .po files individually doesn't scale at all 06:36 pitti mdz: why not? 06:36 mdz aggregation is a must 06:36 mdz pitti: how will you determine which ones to download? 06:36 pitti mdz: timestamps? 06:37 mdz pitti: you will do thousands and thousands of HTTP HEAD requests? 06:37 Keybuk sorry guys, I'm going to have to bow out now 06:37 mdz or download an index with every .po file in it? 06:37 pitti mdz: not necessarily 06:37 Keybuk have to pack for both London, Mataro and Christmas-week tonight 06:37 pitti mdz: you can tell rosetta "give me all translations newer than date x" 06:37 pitti mdz: rosetta would give you a tarball-like answer 06:38 pitti mdz: the timestamps can be sent out by rosetta as well 06:38 pitti mdz: so we don't need to rely on clocks 06:38 pitti mdz: or peek on po files 06:38 mvo_ pitti: I'm not sure if this will not hit rosetta way too hard if a lot of users use our system 06:38 pitti mdz: we just store the last timestamp/index mark/whatever of the last update 06:38 smurfix_ if http head doesn't scale, then don't use it ... sounds simple. :-P 06:38 pitti mvo_: if users start to download translations daily, it doesn't matter if we hit rosetta or archive 06:39 Mithrandir pitti: rosetta isn't mirrored. 06:39 mdz smurfix: the point is that we don't have a choice in whether to aggregate .po files into larger blobs 06:39 mdz which seems to be the idea that everyone is attacking 06:39 pitti Mithrandir: then let's mirror it :-) 06:39 elmo mdz: no, what I'm saying is that putting these in .debs in the archive is not a sane solution, given the requirements 06:39 pitti mdz: but the aggregation would just be temporary as a download armor 06:40 pitti mdz: s/armor/transport format/ 06:40 Mithrandir elmo: do you think putting them somewhere which is not mirrored would be as bad? 06:40 pitti Mithrandir: if we don't have the bandwidth to support daily translation downloads, then there is no solution at all, I think 06:41 Mithrandir if so, the language-pack tool could just be a small shell script which wraps apt similar to d-i's build process. 06:41 mdz elmo: how do you propose that we provide them as a portable, CD-friendly, installable, removable chunk of data, then? 06:41 pitti same transport format as for download, I think? 06:41 Mithrandir pitti: putting plain files on CDs is painful, .debs are easy. :) 06:41 pitti all translations later than 0 06:41 elmo mdz: whatever you want dude, I'm not trying to impose a solution on you or pretend to be clever enough to have even close to a good one. I'm just trying to tell you what is and isn't possible and/or sane from a archive/mirror perspective 06:42 pitti Mithrandir: so wrap it up in a deb for my sake 06:42 mdz elmo: the message I'm getting is that we need something which provides .deb-like semantics without sending mirrors running away screaming 06:43 mdz even if we accept that we need a delta-update mechanism 06:43 pitti mdz: maybe we should think a bit about this particular problem before continuing 06:43 mdz we need an initial blob that we ship on CDs 06:43 mdz pitti: aw, it hasn't even been two hours yet :-) 06:43 smurfix_ the transport blob on cd would just have a few files you don't want *shrug* 06:44 pitti mdz: the cd can wrap up rosetta's transport format into a deb 06:44 mdz how do we mirror translations, if not as .debs? 06:44 pitti mdz: we should rather mirror rosetta's database 06:44 smurfix_ mdz: a replicated datavase? 06:44 Kamion Mithrandir: .debs not in the main archive are no easier than random files, TBH 06:44 mdz smurfix: say what? 06:44 smurfix_ database 06:45 Kamion Mithrandir: at least not significantly 06:45 Mithrandir Kamion: they are. 06:45 mdz smurfix: I understood that, but what do you mean? 06:45 mdz smurfix: "run a copy of this application"? 06:45 Mithrandir Kamion: just duplicate the code to do security patches on the CD. 06:45 Kamion Mithrandir: it's pretty trivial to get debian-cd to copy random files onto a CD 06:45 Kamion Mithrandir: I know how to do it 06:45 Kamion Mithrandir: the question is doing anything useful with them at the other end 06:45 mdz anything which is not a flat file is not going to be mirrored to an extent even close to the current archive 06:46 mdz let's explore that a bit 06:46 mdz so we have some random data on the CD 06:46 mdz well, not so random 06:46 mdz translation data 06:46 mdz which we need to install on the system 06:46 pitti mdz: but with any aggregation you will loose the flexibility of individually updating po files 06:46 Kamion mdz: I'm not necessarily saying it's a good idea, just that it's not impossible 06:47 elmo mdz: it doesn't necessarily need to be - the hit on translations is going to be an order of magnitude less than archive for some time tocome, and if we come up with something that doesn't involve databases, we will get mirrors for it in time 06:47 Mithrandir pitti: yes, you will. Some overhead is fine. 06:47 pitti mdz: the blob could be put into something similar to /var/cache/apt/archives, and l-s-XX could use that instead of downloading 06:47 mdz elmo: something that doesn't involve databases == flat file, no/ 06:47 mdz ? 06:47 smurfix_ mdz: it's one possible solution. Whether it's actually feasible for mirrors to run mysql-or-whatever is a different question, which I'm not qualified to answer. 06:47 mdz pitti: so d-i would do this copying? 06:47 elmo mdz: no, I mean doesn't invovle replicating databases.. 06:47 pitti mdz: it probably has 06:48 pitti mdz: similar to archive-copier 06:48 mdz smurfix: I can say, even in near-complete ignorance of the existing mirrors, that it is not feasible 06:48 elmo mdz: i.e. anything that can be mirrored via http, ftp and/or rsync 06:48 pitti mdz: if l-s-XX sees that something is already in the cache, it doesn't need to contact rosetta 06:48 mdz elmo: agreed 06:48 pitti mdz: just an idea... 06:48 mdz pitti: what about the case where I have installed the system, and then later want to install an additional language? 06:49 pitti mdz: without downloading? 06:49 mdz pitti: right, say I have an Ubuntu DVD which contains translations for many languages 06:49 Kamion I would like to avoid piling more and more stuff into d-i which we don't have an interface for changing in the real system 06:50 pitti mdz: same technology as with the initial install, I think, but we need an easy interface for that 06:50 Kamion d-i should certainly take care of installing your primary language, but it's not going to solve the whole problem for you 06:50 pitti Kamion: in fact d-i shouldn't bother about these blobs at all 06:50 pitti Kamion: d-i should just install l-s-XX and be fine 06:50 Kamion pitti: mkay 06:51 pitti the lang packs should have the knowledge of getting their blobs 06:51 Kamion pitti: but I think you'll find it needs to bother for net-less installs 06:51 pitti Kamion: at least this seems to be more consistent 06:51 Kamion pitti: at least at the archive-copier level or similar 06:51 pitti right 06:51 mdz pitti: the language pack will not be able to get data from the CD 06:51 pitti not? 06:51 Kamion pitti: the CD's ejected 06:51 mdz I would object to reimplementing apt-cdrom in the language pack 06:51 pitti mdz: me too 06:52 pitti maybe archive-copier should be extended then 06:52 pitti I don't have a very good solution without thinking about it for at least some hours 06:52 mdz the reason that I'm hesitant to give up on .debs entirely is that so many of these problems simply go away for .debs 06:52 pitti it's all ad-hoc solutions 06:52 pitti mdz: then let's find a solution which uses debs as transport format 06:52 mdz we even have gnome-app-install as a nice interface for add/remove 06:53 pitti mdz: use debs as wrapper, but don't publish them onto our normal archive 06:53 mdz I'm at a disadvantage, having missed the previous meeting 06:53 mdz was a consensus reached there that .debs really aren't the way to go? 06:53 elmo no 06:53 pitti mdz: well, at the previous meeting we argued about extracting po files during build and shipping the debs in our archive 06:53 pitti mdz: no 06:53 mdz if we move away from .debs, we trade the delta-update problem for a bunch of other problems which aren't necessarily less 06:54 pitti mdz: wouldn't that be cured by allowing debs to be built on the fly? 06:54 pitti mdz: allowing, not requiring 06:54 pitti mdz: initial translations would be on the CD as normal debs 06:54 mdz pitti: I'm not clear on exactly what the debs-on-the-fly solution would look like, can you describe it? 06:55 pitti but upgrades would assemble a new deb based on existing and downloaded translations 06:55 pitti this new deb is then installed normally as a new revision of the old one 06:55 pitti something along that line 06:55 mdz what piece of software would be responsible for building the .debs? 06:55 pitti the langpack, Isuppose 06:55 mdz the language pack deb? 06:55 pitti it would depend on dpkg-dev 06:56 pitti it should be relatively easy to pack together a bunch of po files with a boilerplate control directory 06:56 mdz if you're thinking of invoking dpkg --install in postinst or something like that, I think there are solid technical reasons not to do that 06:57 pitti mdz: no, not necessarily in postinst 06:57 Kamion can't be done in postinsts 06:57 mdz definitely can't be done now, and good reasons not to fix it 06:57 pitti mdz: of course we have to delay that somehow 06:57 mdz pitti: dpkg post-hooks or some such? 06:57 pitti mdz: I don't know instantly 06:57 pitti mdz: but I feel that there surely is a sane solution for that 06:58 pitti mdz: btw, creating the deb is not done in the postinst 06:58 pitti mdz: it is done in sudo update-language-pack or so 06:58 pitti mdz: and this could install the deb 06:58 mdz pitti: it seems to me that you end up solving most of the .deb delta update problem in the process 06:58 mdz in which case we should just solve the .deb delta update problem and be done with it 06:58 pitti mdz: we just have to find a way to call update-lang-pack 06:59 pitti outside of langpack postinst, that is 06:59 pitti but we solve the mirror problem, the download redundancy and pretty much all other problems AFAICS 07:00 pitti actually, when I think about it 07:00 mdz true, the ideal solution for .deb delta updates in apt wouldn't necessarily work for rsync mirrors 07:00 pitti the translations don't need to be updated in sync with pacackage updates 07:00 pitti the user could click onto a button "update translations" which would just call update-language-... 07:01 pitti especialyl in stable releases this is a fine thing 07:01 pitti since you don't normally upgrade pacakges anyway 07:01 mdz this is similar to how the OAV signature stuff works, for example 07:01 pitti (modulo security udpates) 07:02 pitti Proposal: I will think about it once more and post my result to the list 07:02 mdz yes, we need to close this meeting 07:02 pitti unless anybody has a great new idea 07:02 mdz interest is waning :-) 07:02 pitti I'll sum up on the list 07:03 mdz let's give it some more thought and revisit in Mataro 07:03 pitti oh right, a BOF! 07:03 Mithrandir BOFs are good. 07:03 mdz we will have translators, etc. there as well 07:03 pitti I will work out the current plan for Mataro 07:03 pitti mdz: right, I already saw the planned bof on the wiki 07:04 mdz ok 07:04 mdz thanks, everyone 07:04 mdz meeting adjourned 07:04 pitti byebye Generated by irclog2html.pl 2.1 by Jeff Waugh - find it at freshmeat.net!