| === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting | ||
| === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting | ||
| === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting | ||
| === pitti [~martin@195.227.105.180] has left #ubuntu-meeting [] | ||
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting | ||
| === Sensebend [~Sensebend@CPE0050f2c2257d-CM014480023927.cpe.net.cable.rogers.com] has joined #ubuntu-meeting | ||
| === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting | ||
| === mvo_ [~Michael@ip181.135.1511I-CUD12K-01.ish.de] has joined #ubuntu-meeting | ||
| === elmo [~james@83.216.141.215] has joined #ubuntu-meeting | ||
| === doko [doko@dsl-082-082-064-230.arcor-ip.net] has joined #ubuntu-meeting | ||
| === pitti [~martin@195.227.105.180] has joined #ubuntu-meeting | ||
| === smurfix_ [~smurf@run.smurf.noris.de] has joined #ubuntu-meeting | ||
| === Mithrandir [~tfheen@vawad.err.no] has joined #ubuntu-meeting | ||
| === wartylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting | ||
| === Topic for #ubuntu-meeting: Tuesday 30 November 2004 at 16:00 UTC: Technical Board meeting -- https://www.ubuntulinux.org/wiki/TechnicalBoardAgenda | ||
| === Topic (#ubuntu-meeting): set by mdz at Tue Nov 23 17:37:38 2004 | ||
| (pitti/#ubuntu-meeting) so I copied the ascii file to http://people.ubuntu.com/~pitti/langpacks.txt | 04:57 | |
| === warthylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting | ||
| === Topic for #ubuntu-meeting: Tuesday 30 November 2004 at 16:00 UTC: Technical Board meeting -- https://www.ubuntulinux.org/wiki/TechnicalBoardAgenda | ||
| === Topic (#ubuntu-meeting): set by mdz at Tue Nov 23 17:37:38 2004 | ||
| (smurfix_/#ubuntu-meeting) pitti: thx | 04:57 | |
| === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting | ||
| mdz | morning | 04:59 |
|---|---|---|
| === amu [~amu@195.71.9.198] has joined #ubuntu-meeting | ||
| (pitti/#ubuntu-meeting) Hi mdz | 05:00 | |
| mdz | pitti: your agenda item was masked by a markup error, I didn't see it until I tried to edit the page | 05:01 |
| (pitti/#ubuntu-meeting) mdz: huh? | 05:01 | |
| (pitti/#ubuntu-meeting) mdz: it was fine for me | 05:01 | |
| mdz | http://www.ubuntulinux.org/wiki/TechnicalBoardAgenda | 05:01 |
| (smurfix_/#ubuntu-meeting) was OK here too | 05:01 | |
| (smurfix_/#ubuntu-meeting) s/here/for me/ | 05:01 | |
| mdz | elmo,fabbione,kamion,keybuk,lamont,mvo_,sabdfl | 05:02 |
| (fabb1one/#ubuntu-meeting) mdz: i am here | 05:02 | |
| (fabb1one/#ubuntu-meeting) just a sec that the wartylog is desynced | 05:02 | |
| === wartylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has left #ubuntu-meeting [] | ||
| === wartylog [~warthylog@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-meeting | ||
| === Topic for #ubuntu-meeting: Tuesday 30 November 2004 at 16:00 UTC: Technical Board meeting -- https://www.ubuntulinux.org/wiki/TechnicalBoardAgenda | ||
| === Topic (#ubuntu-meeting): set by mdz at Tue Nov 23 17:37:38 2004 | ||
| fabb1one | test | 05:03 |
| fabb1one | ok much better | 05:03 |
| Keybuk | quite finished? ;o) | 05:03 |
| === fabb1one is now known as fabbione | ||
| 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 |
| === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting | ||
| pitti | Keybuk: what's Cadbury? | 05:04 |
| elmo | lol | 05:04 |
| 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 | 05:05 |
| === pitti understands :-) | ||
| pitti | mdz: that was me, BTW | 05:05 |
| === Keybuk is going off to bomb Bourneville when this is over | ||
| 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:05 |
| 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:06 |
| === pitti listens | ||
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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 | 05:15 |
| === Mithrandir thinks /usr/local/share/locale would be the right place, but that's a detail. | ||
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| === sivang [~sivang@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting | ||
| 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:36 |
| 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:37 |
| 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:38 |
| 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 |
| === Keybuk tightens the chastity belt on dpkg-deb, just in case mdz gets any more funny ideas :p | ||
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| mdz | in order to guarantee a consistent result | 05:45 |
| Keybuk | mdz: or modifying build-essential | 05:45 |
| === Kamion could live without the build-dep for the purposes of expediency ... | ||
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| mdz | given some magic which saves us from the crushing merge workload, the preferred solution for stripping locales is a dh_striplocales one | 05:53 |
| pitti | agreed | 05:54 |
| sabdfl | ok, next! | 05:54 |
| mdz | can we really take that for granted at this stage? | 05:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 05:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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 |
| === Mithrandir hides. | ||
| sabdfl | it might even use rsync! | 06:10 |
| 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 |
| === lamont_r [~lamont@dsl-140-203.dynamic-dsl.frii.net] has joined #ubuntu-meeting | ||
| mvo_ | Keybuk: +1 | 06:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| === seb128 [~seb128@ANancy-151-1-32-96.w83-196.abo.wanadoo.fr] has joined #ubuntu-meeting | ||
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| mdz | smurfix: O(packages*languages) | 06:34 |
| === jdz_ [~jdz@69.49.156.181] has joined #ubuntu-meeting | ||
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| pitti | mdz: without downloading? | 06:49 |
| === smurfix_ hides for a bit. real life calls :-/ | ||
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| pitti | it should be relatively easy to pack together a bunch of po files with a boilerplate control directory | 06:56 |
| === Mithrandir gets gentoo-vibes from that. | ||
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 06:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| mdz | ok | 07:04 |
| mdz | thanks, everyone | 07:04 |
| mdz | meeting adjourned | 07:04 |
| pitti | byebye | 07:04 |
| === lamont_r [~lamont@dsl-140-203.dynamic-dsl.frii.net] has left #ubuntu-meeting ["Leaving"] | ||
| === haggai [~halls@i-83-67-20-196.freedom2surf.net] has left #ubuntu-meeting [] | ||
| === pitti [~martin@195.227.105.180] has left #ubuntu-meeting [] | ||
| === amu [~amu@195.71.9.198] has left #ubuntu-meeting [] | ||
| === seb128 [~seb128@ANancy-151-1-32-96.w83-196.abo.wanadoo.fr] has left #ubuntu-meeting ["I] | ||
| === fabbione [~fabbione@port49.ds1-van.adsl.cybercity.dk] has left #ubuntu-meeting [] | ||
| === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] | ||
| === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has left #ubuntu-meeting [] | ||
| === sivangAFK [~sivang@80.179.93.130.forward.012.net.il] has left #ubuntu-meeting ["Leaving"] | ||
| === jdz_ [~jdz@69.49.156.181] has joined #ubuntu-meeting | ||
| === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting | ||
| === sabdfl [~mark@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting | ||
| === Mithrandir [~tfheen@vawad.err.no] has joined #ubuntu-meeting | ||
| === doko [doko@dsl-082-082-064-230.arcor-ip.net] has joined #ubuntu-meeting | ||
| === elmo_away [~james@83.216.141.215] has joined #ubuntu-meeting | ||
| === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting | ||
| === sladen [~paul@starsky.19inch.net] has joined #ubuntu-meeting | ||
| === smurfix [~smurf@smurfix.developer.debian] has joined #ubuntu-meeting | ||
| === boglot [~logbot@mentors.workaround.org] has joined #ubuntu-meeting | ||
| === KragenSitaker [~kragen@66-193-87-113.gen.twtelecom.net] has joined #ubuntu-meeting | ||
| === reformed [~benl@junkybox.pacific.net.au] has joined #ubuntu-meeting | ||
| === dieman [~dieman@3.14159265358979323846264338327950288419716939937510582097.org] has joined #ubuntu-meeting | ||
| === Kamion [~cjwatson@host81-153-126-219.range81-153.btcentralplus.com] has joined #ubuntu-meeting | ||
| === mako [mako@micha.hampshire.edu] has joined #ubuntu-meeting | ||
| === asw [~Alexander@node-423a728a.bos.onnet.us.uu.net] has joined #ubuntu-meeting | ||
| === rabidbt [~rabidbt@66.45.74.16] has joined #ubuntu-meeting | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!