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 will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
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
There's a bug in InstallManifest::add_entries_from: some of the
manifest entries bake their destination into both the manifest key and
the manifest value, and add_entries_from with a non-empty "base"
parameter to prepend to the destination only updates the manifest key
and not the value.
This bug causes |mach watch| to fail to _read_ the unified manifest
that aggregates all of the build manifests relevant to |mach watch|
that |mach build-backend -b FasterMake| successfully _wrote_, because
the manifest keys are validated against the manifest values written to
disk.
I see no way to address this other than to manually reach into the
manifest values and patch the internal destination parameter, which
this patch does.
MozReview-Commit-ID: FVyRB41NnHa
--HG--
extra : rebase_source : 23eb18ddc0452955539ce2e7a6d7bbfd083c940c
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
This ensures we use forward slashes, even if Mercurial emits
backslashes (which it can do on Windows).
MozReview-Commit-ID: 2dnWAEvytwn
--HG--
extra : rebase_source : 9ebb454bc9ad11b3eba334e412685e529573a0a1
These tests weren't running in automation because hglib wasn't
available. An upcoming commit will vendor hglib. This exposed that the
tests can fail if ui.username isn't set.
In this commit, we introduce a helper function to obtain an hglib
client with ui.username set. We also convert tests to use the context
manager form of the client so resources are cleaned up immediately
without relying on refcounting or garbage collection.
MozReview-Commit-ID: HRSBDlYgqpC
--HG--
extra : rebase_source : 83deb56a0c2efefa883d6df104cd67194a811907
The install manifest with the .track files uses os.path.exists() to
determine if a previously tracked file is no longer installed and needs
to be removed from the system. However, exists() returns False for
broken symlinks, so as far as the manifest is concerned, there is no
file in the filesystem that needs to be removed. We should use lexists()
so we know that the broken symlink still exists in the system so
that it can be removed when the install manifest is processed.
MozReview-Commit-ID: 6v7CYOKzjGs
--HG--
extra : rebase_source : 8aeeef59e644613f34c8458bd30a83d8299585ea
This passes `python3 -mcompileall`. Changes:
* use `0o` prefix for octal literals
* print as a function
* except .. as
* use six.reraise to replace a multi-argument raise statement
* use six.string_types and six.moves.configparser
* remove uses of `L` suffix for long integers
MozReview-Commit-ID: KLaYRNHGpay
--HG--
extra : rebase_source : 6ca1b5447cd28eff8d9f2805add6a0f07e8b4c63
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
There's a natural follow-on that I haven't time to explore right now:
I want the faster make backend to also write a "unified chrome
manifest" that maps outputs
(browser/chrome/browser/content/browser/ext-utils.js) to chrome:// or
resource:// URLs (chrome://content/browser/ext-utils.js or similar).
MozReview-Commit-ID: LDQmm8KD57I
--HG--
extra : rebase_source : 13dbeac2fbfa78741be3718fd5305a8ae0d698a8
extra : source : 2af5df7741147769a51da78770c308b370a0cded
This is necessary because the existing manifests don't expose full
dependency information. I needed to avoid the existing dependency
files because those code paths need to know the output destination of
the manifest in order to parse the Make dependency files; trying to
adapt this system is more complicated than just preprocessing each
file to extract dependency information directly.
MozReview-Commit-ID: 5m0SEqmhJMM
--HG--
extra : rebase_source : 1ff6a1a51bc76efa78eb564cd8e572777dace0f6
Also removes InstallManifestNoSymlinks which can be more simply expressed by
passing link_policy='copy' to InstallManifest.populate_registry.
MozReview-Commit-ID: Bkjc2hIub4A
--HG--
extra : rebase_source : df05080fef3baf7e6c60ff9a468e71f0b2c67462
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
This allows us to write files coming from a finder or other source
that isn't directly the filesystem.
MozReview-Commit-ID: KhPSD0JYzsQ
--HG--
extra : rebase_source : fea376f642e20e8c7723506fd4a73e3f8ac5d0e5
extra : intermediate-source : a872303fd08497bbde0e3b4cea09a88a4182810e
extra : source : ae8bce278626bc84914063f93292ac5e825eec36
This allows us to write files coming from a finder or other source
that isn't directly the filesystem.
MozReview-Commit-ID: KhPSD0JYzsQ
--HG--
extra : rebase_source : 24db84974b54a714ba82dfad7ff68fd1a5bf656a
extra : source : ae8bce278626bc84914063f93292ac5e825eec36
