The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 05fe935c1d2a9fbfeef786819bfe5913ed8ef862
extra : source : d6bf22099e2195dcb64c3c3d7700d3edd0850a3a
The uninstaller was being built as a side-effect of building `setup.exe`. In
Bug 1385227, that was moved from "somewhere" to part of the windows installer
packaging, which happens after the zip and mar are generated. Since the
installer we ship is actually repackaged from the zip[1], we stopped shipping
translated uninstallers.
This changes things around so that the uninstaller gets translated:
- Explicitly build the uninstaller as part of the L10n repack step.
- Use the same logic to build the installer locally as we do to create the ones
we ship.
[1] Except on Thunderbird
Differential Revision: https://phabricator.services.mozilla.com/D672
--HG--
extra : rebase_source : 2b28b9ff7196d12f4a188c8dddf750b9a5efac5b
extra : histedit_source : 9bc28891950ae8c226cfdefef6f8121ce0b51f58
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 : c14f0b17904f8f9e0e3f004384c2a292ceeafe4f
extra : source : e95f8bd7b5190bf1d3fae75a88a15ebbe6613809
Undoing some of my ideas to support l10n-merge for defines.inc.
We'll add that once compare-locales can actually merge them.
The culprit why this didn't work is that there's one level
of $(MAKE) invocation missing between the rule that
defines IS_LANGUAGE_REPACK and config.mk actually taking
that into account.
MozReview-Commit-ID: 2JJZrvAPhG0
--HG--
extra : rebase_source : 7984a98611b40d35c58b65194cedf1ac20127293
We added a return error value for compare-locales so that it
can be used in automated checks more easily. For builds, though,
ignore that return value.
Also, mach doesn't like utf-8 encoded output, so let's print
unicode.
MozReview-Commit-ID: L4lzqhBE0By
--HG--
extra : rebase_source : 3a9c612dc99b0f0417eb02c4d8478f1a2f245436
Vendor new dependency for compare-locales, python-fluent.
This is the 0.4.2 release of python-fluent.
Also, make mach command a bare minimum wrapper.
The compare-locales mach command used to own a couple of defaults
and opinions.
Now that those opinions and defaults are in the Makefiles, this
command can be much simpler. As a side effect, this should
make the thunderbird port easier, where none of the mach defaults
worked.
Update l10n.mk for compare-locales 2.x:
The command line interface is different now, with positional arguments.
Also, the l10n config file isn't a default anymore (that never worked
for thunderbird).
And the merge dir is now the parent of the locale dir, much like
we already anticipated in the code.
MozReview-Commit-ID: DxVVKyVSt5y
--HG--
extra : rebase_source : 7c591fea8c7d9ecef615fb56f9359d4f1bd4b340
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