Open
Bug 1107628
(l10nrepacks)
Opened 10 years ago
Updated 1 year ago
Make l10n repacks not as much of a disaster as they currently are
Categories
(Release Engineering :: Release Automation: L10N, defect)
Release Engineering
Release Automation: L10N
Tracking
(Not tracked)
NEW
People
(Reporter: ted, Unassigned)
References
(Depends on 2 open bugs)
Details
Right now l10n repacks are very complicated and fragile and nobody has a good understanding of how all the bits work. We had a meeting today about how we can fix that, and I think we all agreed on a set of steps (which I will file as bugs): 1) Create a mach command that encapsulates all the steps necessary to take an en-US build and a set of locales and produce repacked builds in those locales. 2) Change the RelEng repack invocation to use that mach command (via mozharness) instead of the tangle of commands it currently uses. 3) Rewrite the mess of make logic that actually does the repacking into a simple Python script. It's not doing a lot of hard work, it's just doing it in a weird way tied into the build system. Please correct me if I've misrepresented any of the takeaways from that meeting (also please CC anyone that's interested that I left out).
Reporter | ||
Updated•10 years ago
|
Updated•10 years ago
|
Alias: l10nrepacks
Updated•9 years ago
|
Reporter | ||
Comment 1•7 years ago
|
||
I was writing this in a comment in another bug, but I think it's too much detail for that bug, so I'm going to put it here since I took the time to write it: Repacks run configure, make a few little bits, and then run `make installers-ab-cd` in $objdir/browser/locales for each locale they repack (this is for desktop, mobile is similar): https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/testing/mozharness/scripts/desktop_l10n.py#859 The `installers-%` target then depends on a bunch of other targets: https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/browser/locales/Makefile.in#163 One of which is the `langpack-%` target defined in toolkit/locales/l10n.mk: https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/toolkit/locales/l10n.mk#211 ...which in turn depends on the `libs-%` target: https://dxr.mozilla.org/mozilla-central/rev/20d57b9c4183973af4af5e078dff2aec0b74f928/browser/locales/Makefile.in#92 ...which runs make in a bunch of directories, overriding $(AB_CD) to get them to copy localized files to the right places.
Comment 2•7 years ago
|
||
Note, the dependencies right now are flawed, they're trying to make things happen in order, which they don't. I set most of that straight in bug 1385227, but that failed with the windows installer bits. The zip packages up `firefox` as root, and the installer uses `core`, which I haven't figured out. http://searchfox.org/mozilla-central/source/toolkit/mozapps/installer/packager.mk#23 is where it does that in the packaging logic for the en-US build.
Comment 3•7 years ago
|
||
Also, for multi-locale builds, we have the chrome-% target which is the same thing as libs-% w/out the XPI_NAME. We should be able to get along with just one of the two now, and pass around XPI_NAME always, potentially empty.
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
Updated•6 years ago
|
Component: General → Release Automation: L10N
QA Contact: catlee → bugspam.Callek
Updated•1 year ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•