Bug 1107628 (l10nrepacks)

Make l10n repacks not as much of a disaster as they currently are

NEW
Unassigned

Status

Release Engineering
General Automation
3 years ago
2 days ago

People

(Reporter: ted, Unassigned)

Tracking

(Depends on: 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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

3 years ago
Blocks: 588746, 657885, 848284
Depends on: 1107630, 1107635
Alias: l10nrepacks

Updated

2 years ago
Depends on: 1174229

Updated

2 years ago
No longer blocks: 848284
Depends on: 848284
(Reporter)

Comment 1

2 days 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

2 days 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

2 days 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.
(Reporter)

Updated

2 days ago
Depends on: 1409721
You need to log in before you can comment on or make changes to this bug.