This small change is actually very significant. Previously, |mach
package| for mobile/android had two jobs:
1) produce a final APK
2) rebuild parts of the APK that might have been silently modified by
l10n mechanisms, both from multi-locale builds and single-locale
repacks
This second part has never been sensible but has been difficult to
alter until recently, since the l10n mechanisms have been out of
mozilla-central and difficult to modify and test. That's less true
now.
This patch:
a) removes the rebuild parts (the step labeled 2) above (which I
generally refer to as the "nodeps mechanism")
b) uses the APKs produced by Gradle directly, without the copying
indirection from m/a/base/Makefile.in
c) does the rebuild for multi-locale builds as an explicit step in the
appropriate mozharness script
d) does the rebuild for each single-locale repack as another step in
the existing `installers-%` target in m/a/locales/Makefile.in (it's
not easy to remove this from the Makefile, since the repackage is
invoked immediately after (it's the `repackage-zip-$*` target))
The new m/a/gradle.py file will grow additional tasks in tickets to
follow, hence the lock file and pre-factored form.
MozReview-Commit-ID: IKflLdmHR3P
--HG--
extra : rebase_source : fdabe340b6f0896a0ebb9da2951f10753deb5ff5
You can still run them on a --disable-stylo build, as long as that works
(presumably not for long).
I think I haven't missed anything, but please double-check.
MozReview-Commit-ID: 3BIAEjgTLo5
This backs out the source readme changes, and gets us to the original source tarball, but massaged for taskcluster's signing+beetmover model.
MozReview-Commit-ID: QIaeQ9LdLb
--HG--
extra : rebase_source : 4677497da550e98a4d07c16169c0949c3ec495b9
In 605111b6f51f, we removed a bunch of unused actions. However, now that we're recreating the source tarball, some of those are no longer unused. This patch brings them back.
MozReview-Commit-ID: 5WZMEeuatup
--HG--
extra : rebase_source : f725e6cacd692357bc8e4194afb052e2c29b99b1
So, it seems we've (since I landed windows l10n in taskcluster) been using http://relengapi/tooltool/ as the tooltool url, this has only been working because if we have the relevent file in local cache we don't query against tooltool.
With TC's windows spinup process it fetches a set of tooltool files to cache locally, and this has been saving us, meaning we're very lucky.
However maple (beta-based) and central have just diverged in manifests, because central now uses a newer VS version than what we have on maple.
This patch will fix that to use the new tooltool location that we currently use for Windows builds, and aligns the repackage jobs to use the newer url too.
--HG--
extra : rebase_source : 4a50d23fcccade23a52c09265f06d978d0090608
We shouldn't really have this problem, and shouting about it early will
make sure that we address issues like multiple instances of omni.ja,
rather than not recording information that we should have been.
Unlike Android installers, installers for desktop versions of Firefox
contain two copies of omni.ja, and the code to check for omni.ja was
ignoring both copies. Let's special-case omni.ja so we get better
numbers for our desktop platforms.
The zipfile and tarfiles paths for finding interesting files in the
installer have duplicated code. We can eliminate this duplicated code
by factoring out a function to just get the paths and sizes for files
contained in the installer. If we need to make changes to how paths are
processed, we now only have to make the change in a single place, and we
can add other kinds of installers easily in the future.
