=== 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 [04:57] (pitti/#ubuntu-meeting) so I copied the ascii file to http://people.ubuntu.com/~pitti/langpacks.txt === 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 [04:57] (smurfix_/#ubuntu-meeting) pitti: thx === mdz [~mdz@69-167-148-207.vnnyca.adelphia.net] has joined #ubuntu-meeting [04:59] morning === amu [~amu@195.71.9.198] has joined #ubuntu-meeting [05:00] (pitti/#ubuntu-meeting) Hi mdz [05:01] 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] 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:02] 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 === 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 [05:03] test [05:03] ok much better [05:03] quite finished? ;o) === fabb1one is now known as fabbione [05:04] hi all [05:04] btw, I'd just like to say, for the record, that Cadbury's are evil [05:04] ok, we seem to have a quorum === silbs [~sbsm0084@host217-37-231-28.in-addr.btopenworld.com] has joined #ubuntu-meeting [05:04] Keybuk: what's Cadbury? [05:04] lol [05:05] pitti: they make chocolate [05:05] pitti: chocolate manufacturer [05:05] pitti: it's a backup weapon to the jellybean [05:05] the only predetermined agenda item is: language packs === pitti understands :-) [05:05] mdz: that was me, BTW === Keybuk is going off to bomb Bourneville when this is over [05:05] (and then feel ill) [05:05] :p [05:05] if I'm not mistaken, this is carried over from the last TB meeting :-) [05:05] mdz: we had a long discussion during your break [05:05] ...which I have only skimmed [05:05] mdz: yes, I distilled the discussion to http://people.ubuntu.com/~pitti/langpacks.txt and to ubuntu-devel [05:06] however, the discussion on the ml wasn't very active [05:06] so I would like to talk about it here [05:06] i have a tech question for pitti [05:06] we don't need to agree about every single detail === pitti listens [05:07] if we set the default build process for packages so that english is installed by default by the package [05:07] but we should agree on the general architecture [05:07] sabdfl: this is the default, btw [05:07] 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] would this resolve the conflicts issue? [05:07] largely [05:08] sabdfl: you mean if you locally rebuild the debs from the source package? [05:08] 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] yes [05:08] without having to rebuild the langpack [05:08] it should be easy to confine the build to some languages, yes [05:08] package would conflict with langpack in that situation, no? [05:08] isn't it quite important that local builds = our builds by default? [05:09] this essentially means to delete all other languages from /usr/share/locale [05:09] Kamion: yes [05:09] Kamion: yes [05:09] Kamion: they would, in the sense that the deb would include english by default, as would ours [05:09] but this would have similar drawbacks as F5 [05:09] sabdfl: I mean in all senses, i.e. same list of files [05:09] if we're going to do language packs, the language pack should become the central point for translation activity [05:09] that's really important for developers testing stuff [05:09] I really thought over this issue [05:10] IMHO putting the translations into proper debs leads to nothing but trouble [05:10] agreed [05:10] either our archive size or our mirrors explode [05:10] and we become totally incompatible to the rest of the deb-world [05:10] pitti: what do you mean by proper debs? [05:10] e.g., language packs? [05:11] I think there are certainly benefits [05:11] mdz: putting the po files into a real deb (as in the F2 options) [05:11] 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] mdz: vs. managing the po files (and other stuff) aside from debs [05:11] it allows us to safely update translations without touching the package itself [05:11] F2-3: we should expect upwards of 200-500 languages within a year [05:11] I still think that F4 is the sanest variant [05:11] pitti: that kills every otion but F4 (and F6 ;-) [05:11] with some ideas from F3-2 [05:12] i. e. download new translations to e. g. /var/cache/locale [05:12] pitti: did you make some estimates for disk space requirements? [05:12] Kamion: you mean, taking /usr/share/local/ out of dpkg control, and managing it separately? [05:12] and provide this as an alternative gettext root [05:12] 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] 200-500 is quite a lot more than any package we currently ship [05:12] mdz: the user would only download the languages and translations that he wants [05:12] Kamion, mdz: these are clear goals of ubuntu/rosetta [05:13] mdz: so disk space is minimal, without any deb overhead [05:13] sabdfl: I know, I'm just saying I find it hard to believe. [05:13] mdz: and overhead of unwanted translations [05:13] pitti: why would F2 include conflicts? Replaces should be enough. [05:13] sabdfl: yes, I'm saying that we need data to know what that would really look like in terms of resources [05:13] fair nuff, just so you understand that's why i'm pushing this so hard now [05:13] Mithrandir: I think it's a bad idea to have a language pack replace a complete application deb [05:14] pitti: Replaces: doesn't mean that. [05:14] sabdfl: I do _not_ propose to change anything in /usr/share/locale, btw [05:14] what about this? [05:14] sabdfl: don't think /usr/share/locale/ should be taken out of dpkg's control; pitti's F4 suggests somewhere in /var [05:14] sabdfl: I only want to have additional translatiosn in /var/cache/locale [05:14] could we update the ubuntu gettext to look in *two* locations? and take the newer? [05:14] Kamion: yes [05:14] language packas would go in /usr/share/langpack/ [05:15] sabdfl: this should be easy for the majority of packages [05:15] gnome-panel has 70 locales totalling 4.2M [05:15] 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] avoiding any location that is currently used produces the huge benefit that we do not become instantly incompatible with everyone [05:15] then the local build could go into a diff location [05:15] Mithrandir: it's still distro-managed though [05:15] pitti: that makes sense anyway [05:16] Mithrandir: I would favor /var; /usr might be r/o [05:16] 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] My idea is to have a language pack which controls the downloading and installation [05:16] pitti: depends on where the langpacks comes from -- if they are .debs, then /usr is r/o => you lose. [05:16] I like pitti's idea of treating the two pools of translations separately [05:16] Mithrandir: as I said, I don't think it's a good idea to put updated translations in deb [05:17] but it highlights a question about the overall process [05:17] pitti: why not? [05:17] is our goal that these translations be passed upstream? [05:17] mdz: yes, through rosetta [05:17] Mithrandir: I explained in detail in my list [05:17] pitti: how else are you going to make sure that cruft is removed? [05:17] if so, upstream inherits a lot of these problems [05:17] Mithrandir: it's nothing but trouble [05:17] Mithrandir: this must be handled by the download manager (i. e. the language pack) [05:17] their source tarball grows, their default install size grows for source-based installs and for other packagers as well [05:17] mdz: upstream don't really, Debian does though [05:17] mithrandir: either you have LOTS of debs or your update is a 99% no-op [05:17] Mithrandir: it shouldn't be too hard to sort out cruft in gettext files [05:18] most upstreams don't seem to care about source tarball size :) [05:18] mithrandir: both is not nice [05:18] btw: bazaar 1.0 release in progress now [05:18] pitti: I'm talking about cruft as in "handling languages which are no longer on the system". You would be reinventing dpkg. [05:18] how about /usr/share/locale/extra/ or something? [05:18] Kamion: do people care about installed-size? [05:18] Mithrandir: maybe, but using dpkg is even worse... [05:19] would be nice to keep within FHS directories [05:19] Mithrandir: deleting a language pack can just remove /var/cache/locale/ [05:19] mithrandir: it's a somewhat different problem space [05:19] Mithrandir: s/delete/purge/ [05:19] or at least get this standardised somehow, since it sounds as if everyone will run into death-by-language-bloat soon [05:19] Mithrandir: if installed-size were not an issue, I think language packs would be a non-issue as well [05:19] well, almost [05:20] mdz: there are also troubles with mirrors and pacakge rebuilds [05:20] there would still be the issue of .deb size [05:20] mdz: installed-size of language packs is the least evil point [05:20] 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] Mithrandir: any whiners are hypothetical at this stage [05:20] Mithrandir: CD size is pretty hard and fast [05:20] we're extrapolating what would happen if the number of translations exploded [05:20] kamion: teaching dpkg to basically ignore some directories should be reasonably simple [05:21] smurfix: that would only address installed-size, and not .deb size [05:21] smurfix_: that approach is pretty fragile and hard to reconfigure later though [05:21] and, as mdz said [05:21] smurfix: why you want to do that? [05:21] easy, Mithrandir [05:21] smurfix_: if somebody says "please can I have French translations now", you have to reinstall everything [05:21] sabdfl: I didn't intend to stomp on any toes -- I was wondering if we were discussing a real problem or not. :) [05:21] we are [05:22] though we are trying to discuss it before we actually have it [05:22] Can we at least agree to drop the F2 options? [05:22] 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] i. e. extract translations during build into separate debs? [05:22] kamion: assuming that the files can't be downloaded from rosetta-or-whatever [05:22] fine by me [05:23] wait [05:23] F2 are the only options which address the problem of .deb size [05:23] oh, also F5 [05:23] our build process will have to be different [05:23] mdz: ? [05:23] mdz: F5 means the shipped debs are different from what you get from apt-get -b source $package, though. [05:24] in that we will not include the translations in a default .deb build [05:24] Mithrandir: yes [05:24] F5 has big problems in terms of package management [05:24] but it does address the problem of .deb size [05:24] pitti: F3, F4 doesn't shave any size off the shipped debs. [05:24] mdz: the point is that _anything_ using debs created by us makes troble [05:24] F4 could be combined with a stripping [05:24] pitti: which we want to do, in order not to hit the 650MB limit. [05:24] we could do a slight modification of F5 which results in having the same .debs in the archive and on the CD [05:24] F4+strip down to English +whatever we can fit is by far the most sane option IMHO [05:25] Mithrandir: yes, but _we_ have to create debs regularly [05:25] local builds break [05:25] Mithrandir: as opposed to F4, when the _user_ decices when to download what [05:25] sabdfl: I really think patching the source packages is the only correct way to modify the build process [05:25] Kamion: yes, i expect that [05:25] Mithrandir: this simplifies both building and downloading a lot [05:25] Kamion: I agree with you on that. [05:25] sabdfl: ok, good, alleviates my major concern :) [05:25] sabdfl: based on our experience so far with merges, that would be a prohibitively large workload for our team [05:26] mdz: okay, F4 +strip in binary and source [05:26] Kamion: but I think if we can manage without patching source packages at all, this would be even better [05:26] patching every source package is not an option for us [05:26] elmo: why both binary and source? Agreeing on either makes more sense imho [05:27] elmo: hmm [05:27] 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] mdz: it's not every source, nly what's on the CD [05:27] we can't not patch what's on the CD if you want local builds to work, AFAICS [05:27] if we're going to modify the build process then that change must be in Ubuntu [05:27] (i.e. not buildds) [05:27] elmo: I think I like that very much [05:27] 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] I'd prefer mangling the binaries when they arrive from the autobuilder. [05:27] (F4 + stripping) [05:28] smurfix_: so wrong, so wrong [05:28] that avoids the conflict issues with local builds [05:28] Am I right that stripping and F4 are actually completely orthogonal? [05:28] think I agree with elmo here [05:29] so we can discuss that independently? [05:29] mdz: and then leaving /var/cache/locales non-dpkg-managed? [05:29] pitti: yes [05:29] good plan [05:29] we can decide separately how to best remove translations from .debs, and how to provide the translations separately [05:29] elmo: why would a local rebuild create a conflict? [05:29] the former is the difficult bit [05:30] stripping how? [05:30] I think the later is tricky too :) [05:30] mdz: adding dh_striplocales (say) to debian/rules wouldn't be that bad, would it? [05:30] if it's a one-liner ... [05:30] at buildd-time, or in the source package? [05:30] 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] Kamion: aka rm -rf debian/$packagename/usr/share/locale ? :) [05:30] it should be a one-time one-liner [05:30] mdz: stripping binary debs is easy, but stipping source packages? We have to change every orig.tar.gz... [05:31] pitti: and then various upstream projects will accuse us of forking [05:31] Kamion: how would that help to reduce the source package size? [05:31] (c.f. openssh) [05:31] 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] Keybuk: yeah, but it should be mostly automergeable [05:31] 9/10 times [05:31] maybe 99/100 too [05:31] pitti: source package size is not the issue [05:32] elmo: do you actuallly mean "strip the source package" or "strip during building the debs from the source package"? [05:32] sabdfl: source CDs are a reality, various people want them [05:32] pitti: latter [05:32] sabdfl: ah, okay. I misunderstood [05:32] elmo: okay, that's easier [05:32] Keybuk: is it feasible to detect the case where we _only_ made this change, and fast-track it? [05:32] kamion: point them at > 650Mb ISOs, what do we care? [05:32] Kamion: they can be multi-cd sets [05:32] mdz: yah [05:32] dvd [05:32] sabdfl: they're already 3 CDs [05:32] sabdfl: turning them into 30 seems a bit non-trivial [05:32] true :-) [05:32] (3 CDs for hoary as it stands) [05:32] Kamion: don't you like a challenge?? [05:33] elmo: depends how fast you want auckland's disk space used up [05:33] last I heard, we weren't hurting for disk space [05:33] 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] ok, girls, focus ;-) [05:33] mdz: we will be if daily CD builds multiply by ten in size [05:33] Kamion: I don't think we quite need _daily_ source CDs [05:34] mdz: we already have them, 'cos building CDs daily is about the only sane way to make sure they keep working [05:34] before we discuss the details, is there anybody who thinks that strip+separate download is _not_ the solution? [05:34] i don't think we need to keep them around though [05:34] Kamion: if it's only as a test, we can throw away the result if the space become sa problem [05:34] what sabdfl said [05:34] mdz: true [05:34] pitti: I wish they are handled by dpkg, but it seems people disagree with that, so. [05:35] 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] (source or binary) [05:35] Mithrandir: if you find a way to sanely handle translations in deb, tell it to us :-) [05:35] +1 source [05:35] source is more correct in every way from a pure technical perspective [05:35] Mithrandir: I would prefer proper debs from a cosmetic viewpoint too === sivang [~sivang@80.179.93.130.forward.012.net.il] has joined #ubuntu-meeting [05:36] mdz: binary is easier, but source cleaner [05:36] source => change source package, binary => adjust binary package after build? [05:36] Kamion: correct [05:36] 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] source++ [05:36] definitely +1 source inasmuch as I don't get a TB vote [05:36] Mithrandir: "Dear Mirrors, hello, here's SOME DEB" [05:36] Mithrandir: either the mirrors or the number of debs would explode [05:36] however, source thrusts us into a situation of having modified several times as many packages as we currently do [05:37] hmm, if source, how do the stripped-off translations end up where people can download them? [05:37] so it is dependent on a greater level of merge automation [05:37] Keybuk: one per language; the biggest language on my system is french, that is about 8MB, compresses down to about 2.7MB. [05:37] mdz: from 233 to "all of them" ? [05:37] mdz: we can modify debhelper to do it automatically [05:37] smurfix: but them into rosetta, I think [05:37] some have claimed that we would only modify the packages on the CD [05:37] Mithrandir: 200 languages, every day, half a gigabyte to each mirror each day [05:37] which I think would be about 3x as many packages as we currently modify [05:38] Keybuk: only build if they have changed that day, then. [05:38] I think modifying dh_builddeb or something around that level in Ubuntu might be just about acceptable [05:38] Keybuk: I doubt we'll have changes to each language each day. [05:38] although it's a bit worrying [05:38] Mithrandir: we upload source every day, leading to a language-pack change every day, for every language [05:38] Kamion: except for non-debhelper packages [05:38] Kamion: do you feel the same way about modifying dpkg-deb? ;-) [05:38] mdz: yeah, pretty trivial number though [05:38] mdz: I feel deep abhorrence for that idea; layering violation [05:38] Keybuk: I thought translations were to be handled completely in rosetta? [05:39] Kamion: I agree, fwiw [05:39] Mithrandir: but you will have a daily change in at least one package, which would trigger a rebuild of the whole langpack [05:39] debhelper is allowed to know about details of Debian policy as regards package layout; dpkg-deb is just an archiver === Keybuk tightens the chastity belt on dpkg-deb, just in case mdz gets any more funny ideas :p [05:39] pitti: uhm, why would that be? [05:39] so s/Debian/Ubuntu/ and it looks barely tolerable [05:39] the problem is that that would break rebuilds of Debian packages [05:39] which would be a bad thing [05:39] 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] Mithrandir: if you have one deb per language, it just is like this [05:39] Kamion: how so? [05:39] I think all source-based solutions share that problem [05:40] Mithrandir: if you have one deb per language per package, the number of debs explodes [05:40] mdz: no they don't, modifying our source packages doesn't [05:40] i.e. our source packages say what we want them to do [05:40] Kamion: the source package modification doesn't make it into Debian [05:40] you said rebuilds of Debian packages [05:40] mdz: I wouldn't change dpkg-deb, only debhelper [05:40] mdz: uh-huh, but people rebuild Debian packages on Ubuntu [05:40] 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] mdz: e.g. backports [05:41] Mithrandir: dude, please read the logs for the last meeting, we went over this TO DEATH [05:41] 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] yeah, I think some people would panic if I uploaded dpkg with all the translations stripped out [05:41] Mithrandir: you have to push half a gig for _every_ language every day [05:41] elmo: ok [05:41] I vote for dh_striplocales [05:41] or dh_stripmessages [05:41] Mithrandir: right now my /usr/share/locale is about 200 MB, but that will increase [05:41] pitti: /query? [05:41] Keybuk++ [05:41] ok [05:42] Mithrandir: ? [05:42] so the broad solution of "modify the source package" seems to be favoured [05:42] kamion:not if we modify gettext and put the rosetta translations somewhere else [05:42] within that solution, we have some choices [05:42] - modify debian/rules [05:42] - modify a debhelper tool (and, if debhelper is not used by the package, debian/rules also) [05:42] - others? [05:42] mdz: + modify rules [05:43] - add a debhelper tool to simplify the modification of debian/rules [05:43] - something that is absolutely shared by every package? [05:43] mdz: least surprise [05:43] Kamion: let's consider the debian/rules option under the assumption that we'll make the change trivial [05:43] by whatever means [05:44] fabbione: the only thing that falls into that category is dpkg-deb, and that's been declared evil [05:44] mdz: aren't we? ;) [05:44] modifying debian/rules is going to mean adding a build-dependency as well [05:45] in order to guarantee a consistent result [05:45] mdz: or modifying build-essential === Kamion could live without the build-dep for the purposes of expediency ... [05:45] hmm, even to guarantee that it builds [05:45] modifying debhelper lets us forego the build-dep [05:45] upload debhelper, wait for elmo/lamont to install it in all chroots, upload everything else [05:45] if it's built with a debhelper that doesn't contain the change, they just don't get a stripped package [05:45] modify build-essential .. [05:46] if we add a new debhelper program then the build will fail if it's missing [05:46] which is good enough [05:46] hmmm [05:46] and then the user is left scratching their head over why the package doesn't build [05:46] lamont will kill somebody just the amount of mails he will get :-) [05:46] 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] mdz: hoary'll ship with this modified debhelper presumably [05:46] the only way to guarantee that is to modify our build-essential [05:47] we'd break building Ubuntu debs on Debian, unless our debhelper change goes upstream [05:47] we could even ask joeyh to include the tool in mainstream debhelper [05:47] we could (haha) || true it, or enclose it in a if [ -e ... ] type test [05:47] I think he'd accept the dh_striplocales variety [05:47] mdz: we've already broken building a lot of Ubuntu .debs on Debian mind you [05:48] Kamion: essentially it would just throw away any po files, right? [05:48] perhaps not the dh_builddeb variety [05:48] mdz: plenty of them require Ubuntu-specific build-deps [05:48] Kamion: really? [05:48] I think dh_striplocales is more correct anyway [05:48] mdz: sure, take GNOME [05:48] I thought there were quite few of those [05:48] mdz: or our d-i [05:48] d-i, sure [05:49] Keybuk: didn't you have some numbers on how many packages don't use debhelper in warty/main? [05:49] might be worth ignoring all packages without translations [05:49] 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] 745/1022 I it looks like [05:49] Kamion: I think the plan is to translate those, too :-) [05:49] mdz: yeah, it came down about 30 don't [05:50] we have a hard limit at this stage on those which don't use gettext at all [05:50] mdz: how about the ones without strings? :) [05:50] 745/1022 have a build-dep on debhelper [05:50] wow, that's less than I expected [05:50] mdz: build-dep-indep too [05:50] ok, i think we have an emergin consensus [05:50] grep-dctrl -FBuild-Depends,Build-Depends-Indep -nsPackage debhelper [05:50] 745 [05:51] mdz: grep-dctrl in hoary is broken [05:51] oh, sweet [05:51] grep-dctrl -s Package -FBuild-Depends,Build-Depends-Indep [05:51] debhelper /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hoary_main_source_Sources [05:51] | wc -l [05:51] 952 [05:51] Actually it catches over 90%, and of the remaining 98 packages only 28 [05:51] contain translations anyway (using the "does it depend on gettext or [05:51] po-debconf" test). [05:51] sabdfl: I think so too, since the guys are already talking about specific details [05:51] -- [05:51] sabdfl: but I think the general strategy works and is the sanest one [05:53] given some magic which saves us from the crushing merge workload, the preferred solution for stripping locales is a dh_striplocales one [05:54] agreed [05:54] ok, next! [05:54] can we really take that for granted at this stage? [05:55] language packs are a hoary goal [05:55] this level of divergence almost requires that we can put most of these merges on full automatic mode [05:55] including the upload [05:55] mdz: let's evaluate that after the first week of Mataro Sessions [05:56] we'll have a handle on hct at that point [05:56] hct doesn't help any more than mom [05:56] a little less, in fact, because it requires tla/baz to play nice [05:56] 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] yes [05:56] elmo: however, it is a high priority item on Mark's hoary list [05:57] mom works by breaking apart, mutating and driving patch itself [05:57] which is fairly close to the same semantics [05:57] we don't get that power with arch [05:57] (we have 55MB free on the powerpc CD, which is tightest) [05:57] Kamion: and we need to get a ppc64 kernel image onto it :-/ [05:57]