This drops the abuse of make dependencies to factor our steps
in l10n repacks and language packs.
It's replaced with clobbers, libs, and the packaging, which
can be shared between installers and the language pack.
MozReview-Commit-ID: 2vEHp0QogXQ
--HG--
extra : rebase_source : fad397c5061fa1a613a4f4484c0d0be172116c1d
This drops the abuse of make dependencies to factor our steps
in l10n repacks and language packs.
It's replaced with clobbers, libs, and the packaging, which
can be shared between installers and the language pack.
MozReview-Commit-ID: 2vEHp0QogXQ
--HG--
extra : rebase_source : 3cfad08c20a100a50306fc44f955589c0568e29a
Introduce a new make command to produce new type of language packs based
on web extensions.
MozReview-Commit-ID: EltYtzT7ZRR
--HG--
extra : rebase_source : 6477be07c747e90992f18d8c7bff93fd48965200
Making more decisions on behalf of developers:
L10NBASEDIR is always defined, if not specified, it's ~/.mozbuild/l10n-central,
or in MOZBUILD_STATE_PATH/l10n-central if the state path in defined in the
environment.
If a locale isn't checked out, do that. The targets for which that works are
merge-%, installers-%, langpack-%
But only do that for Nightly builds, as for Beta and beyond, we have
explicit revisions to use for the builds, and we don't want to break release
builds silently with this.
MozReview-Commit-ID: EhGJPLuiyYO
--HG--
extra : rebase_source : 61a92396920965107a8811679552c1992b29155e
To not merge the en-US language pack, the merge-% steps are in
a conditional function that disables that for en-US. Using a function
here as that's easier than a shell if in the merge rule, and
Makefile conditionals don't get evaluated late enough.
To liberate the l10n builds from settings in the automation,
we move the patch logic from LOCALE_MERGEDIR to REAL_LOCALE_MERGEDIR.
To determine strongly when we're in a repack or building a langpack,
the trick here is to
export IS_LANGUAGE_REPACK
in l10n.mk, and only set that to true in the entry-point rules.
Now, we can use that value in config.mk to define the l10n-specific
rules.
I did the same thing for langpack-%, which allows us to disable
the crashreporter files for language packs, for example.
With that,
make installers-de
just works, if you have localizations checked out.
For a while, we might run l10n-merge twice in automation, but it's really not
optional, so let's just make sure we run it.
MozReview-Commit-ID: 3nr33CKxkBQ
--HG--
extra : rebase_source : 0605a4adba018fa4b85d563cdafba80b0533bc91
Set AB_CD on per-locale entry point pattern rules.
Not setting this on the repackaging top-level pattern rules, as they
need AB_CD to be en-US to find the original package to unpack.
MozReview-Commit-ID: JqrLYyEyvvb
--HG--
extra : rebase_source : 82c840f16e131fe8f340e21ff86a34c70e3f7f97
Land date changes to support windows nightlies onto central
This adds support for a seperate installer URL. We need this because in taskcluster the flow goes like this:
-|- Unsigned Build (outputs test files, unsigned .zip and similar files)
\-|- Signing (outputs .zip with signed contents and a signed setup.exe and setup-stub.exe)
\-|- Repackage (takes the signed .zip and generates unsigned update .mar and installers using the signed internal files)
\-|- Repackage Signing (Takes the installers and signs them, and signs the update mar)
L10n tasks for windows need to take the .zip and the completed installer, and want to reuse as much
of the en-US signing as we can, so we pass in the URLs to artifacts from both signing steps in the chain.
MozReview-Commit-ID: 9nIo2CCTh9h
--HG--
extra : rebase_source : 6d2e9a77c9f0cb118ff5389f584034f491bbf0ed
This is no longer relevant now that we use release promotion instead of
a separate release build with MOZ_PKG_PRETTYNAMES=1.
MozReview-Commit-ID: 11mgGJ7IDaK
--HG--
extra : rebase_source : da8fde3ae36779549b2097fc95d754f558cb88c8
Let's use a pristine unpackaged directory of the en-US package, and just
rsync that to l10n-stage. That way, all repacks start off with a copy
of en-US without modifications of the previous repack.
Removing clobber-zip, that hasn't been used in ages, on the way.
Moving the creation of the branding dir to the INNER_UNMAKE_PACKAGE,
which is the command that needs it, to simplify rulesets.
MozReview-Commit-ID: 8WJtaAqjmk1
--HG--
extra : rebase_source : 2c60a09bc09c72d5d8cf3058a66f806059c93751
Taskclusters cloud-mirror sends a url-encoded response as a redirect, which allows it to point at the absolute url to the file in another AWS region and then it fetches and caches it while returning said file to our client (wget in this case)
Wget however is performing ASCII-->UTF8 conversion on the url on windows, while at the same time also performing a urldecodeon the redirected url.
This urldecode is breaking Taskclusters cloud-mirror, so we work around that by telling wget not to perform the conversion at all (we don't need charset conversion here)
Alternative option was to set --local-encoding=ASCII, however that option doesn't work on our current linux machines (and likely OSX builders, but untested there) while --no-iri works on all 3 platforms, so we are going with that.
MozReview-Commit-ID: EXmiDpozFNr
--HG--
extra : rebase_source : 551bb299d959ac2af1f1c9511b665b7d1a0d9f2a
A few notes:
* This doesn't accommodate general OMNIJAR_NAME definitions. The
current name (assets/omni.ja) is baked into the product in a few
places, and is very unlikely to change, so we just error out if this
isn't true.
* This makes the package-manifest.in file authoritative for what goes
into assets/, libs/, and the APK root. Previously,
package-manifest.in wrote into assets/ and libs/ but
upload-files-APK.mk also had a convoluted DIST_FILES filtering
process to work through before a file actually made it into the APK.
* This is intentional about repackaging. It simplifies the repackage
step rather than trying to make unpackage-then-repackage the same as
just package. I pretty much never get repackaging correct the first
time; this should help. (I've manually tested it.)
* The ALREADY_SZIPPED during repackaging is subsumed by the previous
check if UNPACKAGE is set. The custom linker expects stored, not
deflated, libraries, so there's some small legwork to accommodate
that in mozjar.
MozReview-Commit-ID: JvVtIUSX685
--HG--
extra : rebase_source : fd8a9cfe3dc364d23b1065995db599f99e676e38
This is glandium's suggested patch. Committing under his name reviewed
by me.
--HG--
extra : commitid : 5abfwXR51iA
extra : rebase_source : d7d3658687e5b825e2095682786653cc42bf201e
extra : amend_source : fde873074c7e5d29f0fd9b5452ed5d1bed2f279d
The only difference between all of them is the application id they target.
Interestingly, the Fennec one is still targetting the XUL appid, instead
of the Android one, which doesn't seem right.
--HG--
rename : b2g/locales/generic/install.rdf => toolkit/locales/generic/install.rdf
Zibi Braniecki
Sebastian Hengst
Axel Hecht
Justin Wood
Mike Shal
Nick Alexander
Mike Hommey
Steven Michaud
Ryan VanderMeulen
Philipp Kewisch
Stephen Pohl
Robert Strong
Jim Mathies
Siddharth Agarwal
Nick Thomas
Ben Hearsum
Gervase Markham