When an added file is not under an app or addon directory, its base
directory is ''. The code added in bug 1539355 would skip doing its
thing in that case, which it shouldn't.
Also revert the workaround from bug 1525762.
We have some convoluted packaging logic to automatically package any directory
with a manifest.json file as an XPI. Unfortunately, that logic also applies to
extensions that are supposed to be part of omni.ja.
It would be nice to have a cleaner way to filter out any resources which we've
already flagged to be part of omni.ja, but this patch takes the simpler
approach of just including anything that's in a modules/ directory, which is
whitelisted for omni.ja elsewhere.
--HG--
extra : source : d30967b60a03f8f4286c26f14342d50e03a59f9d
extra : amend_source : 2ddab7bd7ce2fb666d5335bf9941328d9dd7d66f
Practically speaking, it makes no difference, as only the calls to
add_base from tests weren't already ordered.
This allows a simpler approach for next change.
Differential Revision: https://phabricator.services.mozilla.com/D25036
--HG--
extra : moz-landing-system : lando
Bug 1533425 makes Gecko try to load from $ARCH/greprefs.js, etc on
Android. This patch teaches the packager to put preferences into
those architecture-specific locations for that code to find.
Differential Revision: https://phabricator.services.mozilla.com/D24984
--HG--
extra : moz-landing-system : lando
Before this change linting python/mozbuild brought about many errors. Some of this errors could be fixed using |mach lint --fix|. The remaining errors where fixed in this bug.
Differential Revision: https://phabricator.services.mozilla.com/D20138
--HG--
extra : rebase_source : 8bd3d622d2221b981f08b8a080c1198b002cdc49
extra : amend_source : 3f6a70c1b7104a7c2d83e11fe911942771e331ea
Fennec has a value of OMNIJAR_NAME that contains a directory, contrary
to other platforms, and relies in post-packaging, pre-unpacking steps to
accommodate with the difference.
With this change, we just make the packaging and unpacking steps aware
of this setup, and make allow them to pack/unpack resources in foo/
under foo/$OMNIJAR_NAME, whether $OMNIJAR_NAME is a file name or a path.
This will, further down the road, allow the packager code to handle jar
logs from PGO instrumentation without munging them.
Differential Revision: https://phabricator.services.mozilla.com/D21654
--HG--
extra : moz-landing-system : lando
Optimizing jars without preloading/reordering data only moves the
jar central directory to the beginning of the file, which, without
preloading information, is not very useful. Let's just stop doing it if
there's not going to be preloading/reordering information at all.
Differential Revision: https://phabricator.services.mozilla.com/D21170
--HG--
extra : moz-landing-system : lando
On CI, Windows builds start from different directories on every build,
except when sccache is enabled. This affects many build types, such as
l10n repacks, and the preprocessor likes to put full paths in its
output, which means it includes those different directories, making the
builds non reproducible.
This changes the preprocessor to replace the source and object
directories with generic strings.
Differential Revision: https://phabricator.services.mozilla.com/D20421
--HG--
extra : moz-landing-system : lando
All directories are part of the langpack that is being merged in, but
when the langpack includes the english dictionary, it is not handled
at the same time as other dictionaries, because it is also part of the
original application.
Instead of trying to catch all places where a dictionary might be added
to the final repack, we wrap the formatter so that it tracks all of them
wherever they're added from, and updates the built_in_addons.json file
accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D16785
--HG--
extra : moz-landing-system : lando
By doing this in the packager, it makes it easier to incorporate the
strip and XZ compress logic into the local Gradle build process.
To that end, this patch makes XZ compression a little more explicit in
package-manifest.in and lifts the logic next to the existing logic for
stripping. Since we only want to XZ compress assets/ (and not libs/),
we need a new flag.
Differential Revision: https://phabricator.services.mozilla.com/D7314
--HG--
extra : moz-landing-system : lando
By doing this in the packager, it makes it easier to incorporate the
strip and XZ compress logic into the local Gradle build process.
To that end, this patch makes XZ compression a little more explicit in
package-manifest.in and lifts the logic next to the existing logic for
stripping. Since we only want to XZ compress assets/ (and not libs/),
we need a new flag.
Differential Revision: https://phabricator.services.mozilla.com/D7314
--HG--
extra : moz-landing-system : lando
We don't actually ship XPT files anymore, but it's still useful for the
packager code to handle old Firefox versions. But for that, we don't
really need the complexity of "linking" XPT files in a single unit per
directory. We can just as well keep the XPT files intact, as long as we
retain individual `interfaces` manifest entries for each.
And since those entries used to be all merged into one, we now instead
group them all together in manifests (which also happens to make it
easier on unit test changes).
Differential Revision: https://phabricator.services.mozilla.com/D5221
--HG--
extra : moz-landing-system : lando
This is slightly ugly, but is unfortunately necessary due to do the nature of
l10n repacks. Hopefully this can go away once we move to bundling lancpack
add-ons rather than repacking in the future.
MozReview-Commit-ID: JZUblVsEbZI
--HG--
extra : rebase_source : 60c9ced2184a52f52c7f2a8820021b14b1a66abf
When repackaging, we want to take all localization resources from the source package,
and add all localization resources from the repackage target locale.
This patch makes packager.l10n scan for `localization` directories in l10n_finder and
add them.
MozReview-Commit-ID: CRLP3bOAyDx
--HG--
extra : rebase_source : 3b1bc098aaed2481a1cc06fc86d0865e654a1b6e
Bug 1355661 added support for brotli streams in "jar" files handled by
Gecko, and bug 1355671 made us build the `bro` command line utility that
allows to compress and decompress brotli streams.
This change uses the `bro` command line utility in the packager so that
it can create and handle "jar" files using brotli streams.
However, the `bro` command line utility is not available to l10n
repacks. As, at the moment, we're only hoping that the outcome of using
brotli will be good, we avoid doing all the work to make those work and
just hook things enough to enable brotli, while ensuring l10n repacks
don't break. This involves forcing some files to be deflated, and to
disable some optimizations from the packager.
Things will need to be figured out more properly if the experiment
proves brotli to be worthwhile.
--HG--
extra : rebase_source : a2e0cff67dcaed465fd441ed5d2a7de94b6351c5
This patch introduces a new registry for localization resources to replace
ChromeRegistry. It uses asynchronous I/O and iterators to generate
permutations of possible sources of language resources for use in the new
Localization API.
In the initial form the API handles packages resources and has API for
interacting with the AddonsManager which will report language packs.
MozReview-Commit-ID: LfERDYMROh
--HG--
extra : rebase_source : 68a664c2c59a82b4dfcae66542c315a00ddae565
This patch introduces a new registry for localization resources to replace
ChromeRegistry. It uses asynchronous I/O and iterators to generate
permutations of possible sources of language resources for use in the new
Localization API.
In the initial form the API handles packages resources and has API for
interacting with the AddonsManager which will report language packs.
MozReview-Commit-ID: LfERDYMROh
--HG--
extra : rebase_source : a6e5b790142e5afb1ce750478190e5ad87012f8d
The change to l10n packager from bug 780562 worked in practice because
no chrome category had exclusively manifest entries with flags, which
we're changing in this bug.
It turns out this was only due to a missing change in the patch for bug
780562.
--HG--
extra : rebase_source : 9f782e115f97063c97f165ed95eb4beeb72f86d0
The change to l10n packager from bug 780562 worked in practice because
no chrome category had exclusively manifest entries with flags, which
we're changing in this bug.
It turns out this was only due to a missing change in the patch for bug
780562.
--HG--
extra : rebase_source : 3c8c31c37d8fb48bb99b1758bcd8ef5f32c71fe0
Some manifest entries (e.g. skin or locale) have an attached identifier,
and there can be different entries with different identifiers for the
same chrome name. The change from bug 1366169 would consider those as
errors, while they are the expected configuration.
--HG--
extra : rebase_source : ceb08da909121a2ac0a2cdaba7970e4594dde09f
As described in changeset c94e87a18096, chrome manifest entries are
reordered and don't necessarily appear in the order they have in jar.mn.
And in some cases, the order does matter: when entries with flags are
followed by entries with more broad flags or no flags at all. Nobody
should be writing entries in that order on purpose, so error out during
packaging when we detect the pattern.
--HG--
extra : rebase_source : d9617bbcbd8560503c532a13c10c8afb0fd49411
Back when the class was written, for the packaging code, it made sense
that the default was True. But now that it's used all over the place,
and that the vast majority of uses are with find_executables=False, it
makes more sense for that to be the default.
--HG--
extra : rebase_source : ff813735fc0d53093f348f20eb77ee03e9b09d4e
And make it an error not to give it. While the default is True, we do
pass a value of False wherever it makes sense, which happens to be, in
most places.
This is an intermediate step to flip the default from True to False,
ensuring that we don't unwantedly switch some calls to False.
--HG--
extra : rebase_source : 432e03f032fef378af482581685583262e5d2661
Mike Hommey
Kris Maglione
Noemi Erli
Nick Alexander
kerlyn
Harry Twyford
Ciure Andrei
Andrew Swan
Zibi Braniecki
Chung-Sheng Fu
Sebastian Hengst
Wes Kocher
Chris AtLee
Carsten "Tomcat" Book
aleth
Chris Manchester