Closed Bug 668586 Opened 10 years ago Closed 10 years ago
Language packs haven't been built since Jun 27
STR: 1) Open http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/ 2) Date of all *.langpack.xpi is 27-Jun-2011 It affects all branches: central/aurora/2.0/1.9.2/1.9.1
They are being put under $platform/xpi For instance http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/linux-i686/xpi/ Sorry this should have been better communicated. This is from the work in bug 517428. We should remove the older xpi files.
(In reply to comment #1) > We should remove the older xpi files. Please, remove old xpi files. I've got at least one report from user, who installed old xpi and got yellow xml error screen.
I'll clean out the old xpis.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
I notice that: - Firefox-Nightly langpack.xpi files for linux-i686 and linux-x86_64 are (AFAICT) the same length. Are these actually the same addons? - In fact, why separate versions per platform? Doesn't one say, "File → Open Web Location" the same way in Lithuanian (and similarly for other strings and languages) regardless of whether you're on win32, linux32, linux64, or Mac-32/64? - SeaMonkey uses the same scheme except that there are no linux-x86_64 directories AFAICT. Maybe (if the answer to my first question is yes) http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-comm-central-trunk-l10n/linux-x86_64/ should be created as a softlink to linux-i686 in the same directory? (It's OK by me if localized builds of trunk SeaMonkey for linux64 aren't built, as long as one can download an en-US tar.bz2 plus a langpack.xpi for the desired locale.)
Also, I suppose this bug and bug 668365 are dupes of each other. Shall we make the newer one a dupe of the older (as is standard practice), or the one still open a dupe of the one already resolved?
Tony, that langpacks are platform independent but built on all is a long-standing artifact, and not really an issue for this bug. Changing the resolution of this bug is not contributing any value either.
(In reply to comment #6) > Tony, that langpacks are platform independent but built on all is a > long-standing artifact, and not really an issue for this bug. Axel, my point is that if they are platform-independent it doesn't make sense to move them to a platform-*dependent* directory. As it was before, if there were scattered oranges and reds, but not for *all* platforms of any locale, langpacks for all platforms could still be had in one place. With this newfangled system, I may have to hunt in three different places (four for Firefox) for the langpack I want.
oops: (current nightly) langpacks for all *locales* could still be had in one place.
(In reply to comment #8) > Axel, my point is that if they are platform-independent it doesn't make > sense to move them to a platform-*dependent* directory. We're not moving them. We're actually doing *less* work now because we don't have to move the xpis to the same dir. We also avoid the collisions (and associated TBPL bustage) this used to cause. I would also note that this only affects mozilla-central. Other branches have symlinks for an xpis dir, e.g.: http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/xpis/ > As it was before, if there were scattered oranges and reds, but not for > *all* platforms of any locale, langpacks for all platforms could still be > had in one place. With this newfangled system, I may have to hunt in three > different places (four for Firefox) for the langpack I want. We're trying to avoid *any* oranges and reds. While I agree that in an ideal system, we would not have multiple copies of the "same" xpi, as Axel mentioned the langpacks are still built on every platform. There are also some langpacks (e.g. ja-JP-mac) that only get built on one platform. The overhead required to either adapt the current system to build langpacks on a single platform, or to recognize when all the langpacks are done for a current round of nightlies (buildbot doesn't let us do that, currently) so we can move them all at once, is prohibitive relative to just putting the xpis into separate dirs.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.