BrandProductName is a recently-introduced branding string which is intended to
not change with the channel of the product; e.g., for a Nightly Firefox build,
BrandShortName is not "Firefox", it's "Nightly", but BrandProductName is still
"Firefox". Some of the new stub installer copy needs a name string like this.
Depends on D31140
Differential Revision: https://phabricator.services.mozilla.com/D31141
--HG--
extra : moz-landing-system : lando
The current implementation of GetTextWidthHeight attempts to guess how much
height a string needs to fit into a given width based on how long the string
is when rendered onto one line of unlimited width. This doesn't work because
breaking up the string into lines introduces additional space at the end of
the lines that the single-line method doesn't account for.
This patch replaces all of that logic with asking DrawText to render the
string into the width of interest and then just seeing how much height it
ended up needing in order to do that.
We also take the opportunity to clarify what GetDlgItemBottomDU was doing,
because it isn't exactly what it claimed to be doing.
Depends on D31139
Differential Revision: https://phabricator.services.mozilla.com/D31140
--HG--
extra : moz-landing-system : lando
For bug 726781, the Windows installer was patched to begin creating a special
registry key when installing an ESR build, to provide a convenient indication
that the product that's installed is an ESR version of the product.
This key contains only the version number of the application being installed;
it is separate from the keys that are always created, for all types of
builds, and that contain the installation path, etc.
During an uninstall or a paveover install, the registry is cleaned by looking
for any keys which contain the path to the application being uninstalled and
removing those; the RegCleanMain function handles this, and for non-ESR builds
it works well. However, there is nothing that tries to remove or update the
special ESR key when an ESR build is being uninstalled or paved over with a
non-ESR build. This patch adds that code to RegCleanMain.
Differential Revision: https://phabricator.services.mozilla.com/D26625
--HG--
extra : moz-landing-system : lando
Result of running:
$ mach eslint -funix toolkit/ | sed -Ee 's/:.+//' - | xargs sed -E \
-e 's/throw ((["`])[^"]+\2);/throw new Error(\1);/g' \
-e 's/throw ((["`])[^"]+\2 \+ [^ ";]+);/throw new Error(\1);/g' \
-e 's/throw \(/throw new Error(/g' -i
...and then reverting a couple of places where comments were touched,
as well as changes to toolkit/components/ctypes/tests/unit/test_jsctypes.js
that required expectation changes to
toolkit/components/ctypes/tests/chrome/test_ctypes.xul
Differential Revision: https://phabricator.services.mozilla.com/D27448
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
The jar log is used for optimization of the packaged jar files according
to their usage patterns during a profile run. The current content of the
file currently come with 2 caveats:
- it contains entries for jar archives that aren't relevant to
packaging, which is not a problem in itself, but see below.
- it contains full paths for jar archives that may not correspond to the
location of the packaged directory (on e.g. Android, where the build
almost certainly doesn't happen in the same directory on the host as
Fennec runs in the emulator/on the device).
The current JarLog code does somehow handle the various ways paths are
currently presented, but it's clearly missing code to map the paths in
the log to packaged paths. Instead of requiring manual work and extra
build options to handle this mapping, and considering the caveats above,
it's just simpler to log archive paths as if they were relative to the
packaged application directory in a build, and use that during
packaging.
Depends on D21655
Differential Revision: https://phabricator.services.mozilla.com/D21656
--HG--
extra : moz-landing-system : lando
Always uppercase the first char of the path in GetLongPath
Remove GetLongPathNameW since it isn't setting the proper case for the path segments below the leaf name
Differential Revision: https://phabricator.services.mozilla.com/D21873
--HG--
extra : moz-landing-system : lando
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
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
In bug 1514288 we started to save the output from running Firefox during
PGO builds into log files, but they aren't correctly uploaded if the run
fails. This presents a problem for categorizing failed PGO builds if the
profileserver returns an error code (eg: bug 1517939), since the error
messages could be hidden away in log files that aren't uploaded.
Instead, we can generate them directly into the artifacts directory so
that they are always uploaded. Additionally, the log files are displayed
if the run fails so that the error messages are displayed in the log for
easier bug categorization.
Differential Revision: https://phabricator.services.mozilla.com/D15881
--HG--
extra : moz-landing-system : lando
The output from running the browser during PGO builds can have innocuous
error messages in them, but show up in treeherder as potential messages
to include when filing bugs. We can just save the output from these runs
as files and upload them as artifacts instead, so they don't show up in
the build log but are available for inspection if necessary.
MozReview-Commit-ID: 3VdVCKVkZNI
Differential Revision: https://phabricator.services.mozilla.com/D15154
--HG--
extra : moz-landing-system : lando
This change applies to Windows only.
Firefox will need to migrate the directory from the old location to the new location. This will be done only once by setting the pref `app.update.migrated.updateDir2.<install path hash>` to `true` once migration has completed.
Note: The pref name app.update.migrated.updateDir has already been used, thus the '2' suffix. It can be found in ESR24.
This also removes the old handling fallback for generating the update directory path. Since xulrunner is no longer supported, this should no longer be needed. If neither the vendor nor app name are defined, it falls back to the literal string "Mozilla".
The code to generate the update directory path and the installation hash have been moved to the updatecommon library. This will allow those functions to be used in Firefox, the Mozilla Maintenance Service, the Mozilla Maintenance Service Installer, and TestAUSHelper.
Additionally, the function that generates the update directory path now has extra functionality. It creates the update directory, sets the permissions on it and, optionally, recursively sets the permissions on everything within.
This patch adds functionality that allows Firefox to set permissions on the new update directory on write failure. It attempts to set the permissions itself and, if that fails and the maintenance service is enabled, it calls into the maintenance service to try from there. If a write fails and the permissions cannot be fixed, the user is prompted to reinstall.
Differential Revision: https://phabricator.services.mozilla.com/D4249
--HG--
rename : toolkit/mozapps/update/updater/win_dirent.cpp => toolkit/mozapps/update/common/win_dirent.cpp
rename : toolkit/mozapps/update/tests/unit_aus_update/cleanupSuccessLogMove.js => toolkit/mozapps/update/tests/unit_aus_update/updateDirectoryMigrate.js
extra : moz-landing-system : lando
This patch also changes how pdbs for the ASAN job are copied:
we relax restrictions so that pdbs if present) are always copied out
and add an environment variable MOZ_COPY_PDBS to indicate when we
want to produce pdbs for copying.
There are two significant parts to this commit. The first avoids
scanning for duplicates in the omnijar when packaging locally. The
Fennec/GeckoView local development edit-test-compile loop _always_
includes packaging, so these developers always pay to scan for
duplicates. And, for historical reasons (Bug 1351000), we build both
a Fennec and a GeckoView omnijar, so these developers pay to scan
twice! Since scanning for duplicates isn't something that local
developers are likely to act on, let's not do this at all (rather
than, say, only once for Fennec).
The second avoids stripping and XZ compressing Fennec/GeckoView asset/
libraries twice. A little path hacking allows to exploit the fact
that the executable processing is idempotent, saving a significant
amount of time during |mach package|.
The final part of this commit just reduces the verbosity of a
`zipalign` invocation.
Depends on D7314
Differential Revision: https://phabricator.services.mozilla.com/D7315
--HG--
extra : moz-landing-system : lando
There are two significant parts to this commit. The first avoids
scanning for duplicates in the omnijar when packaging locally. The
Fennec/GeckoView local development edit-test-compile loop _always_
includes packaging, so these developers always pay to scan for
duplicates. And, for historical reasons (Bug 1351000), we build both
a Fennec and a GeckoView omnijar, so these developers pay to scan
twice! Since scanning for duplicates isn't something that local
developers are likely to act on, let's not do this at all (rather
than, say, only once for Fennec).
The second avoids stripping and XZ compressing Fennec/GeckoView asset/
libraries twice. A little path hacking allows to exploit the fact
that the executable processing is idempotent, saving a significant
amount of time during |mach package|.
The final part of this commit just reduces the verbosity of a
`zipalign` invocation.
Depends on D7314
Differential Revision: https://phabricator.services.mozilla.com/D7315
--HG--
extra : moz-landing-system : lando
This merely centralizes logic that was formerly used at multiple sites
into the single remaining use site.
None of the JAVA* flags have been used for a long time.
Differential Revision: https://phabricator.services.mozilla.com/D7313
--HG--
extra : moz-landing-system : lando
We need to sign parts of the contents of the archives, so the mar's that we
ship get built as part of the repackage task. Thus, there is no reason to also
create and upload as part of the build, just to throw them away.
Differential Revision: https://phabricator.services.mozilla.com/D6213
--HG--
extra : moz-landing-system : lando
The macro expansion of ExecAndWaitForInputIdle consumes the quotes
around the macro argument. The argument has an extra layer of quotes
around the executable name, which keeps it together even if it has
spaces, but we need yet another layer around the whole command line or
else each component of the command line appears as another argument to
StrCpy.
Standard practice is to quote args in the macro definition, I overlooked
this in the initial implementation.
Differential Revision: https://phabricator.services.mozilla.com/D6111
--HG--
extra : moz-landing-system : lando
In theory, the third parameter (dualMode) to the NSIS ApplicationID plugin's
Set function is optional, but the plugin assumes that either it's there or
there's nothing else on the NSIS stack, so it pops three items from the stack
unconditionally. This means that supplying only two parameters results in
one item silently being dropped from the NSIS stack. Fortunately this one
function is the only place where we were doing that, so it only became a
problem if there were an awful lot of shortcuts (around 7) to the same
installation.
Differential Revision: https://phabricator.services.mozilla.com/D4009
--HG--
extra : moz-landing-system : lando
Bug 1454912 added a new argument to the file_generate action to
correspond to the make target in the generated dependencies file. These
multilocale.txt targets in packager.mk need to add a parameter for this
argument, otherwise the first locale will be silently used as the target
and won't be included in the resulting multilocale.txt file.
MozReview-Commit-ID: 3nW5Twj89VH
--HG--
extra : rebase_source : d179f7d6aa7a2f608114bc8f2672a45f99dfc0e5
I'm also adding a "StartMenuShortcut" option as an alias for "StartMenuShortcuts",
because I could not stop leaving off the 's' while testing this patch, so I
figure I'm not the only one making that mistake and getting frustrated.
MozReview-Commit-ID: Fdsc6CTBJr4
--HG--
extra : rebase_source : c57295e0936b6721bc75d6f11f33bad6691b96de
buildhub is a service that stores a list of nightly and release builds and
can be queried to find specific builds. Currently it ingests data by scraping
info from ftp.mozilla.org. This patch makes it so we generate a buildhub.json
during packaging with the data that buildhub wants.
There are a few pieces of data that we can't accurately provide from the
build system such as the URL to the build, so we provide some stub data
there with the expectation that a release engineering process will fill
them in later.
MozReview-Commit-ID: 266BnZZBFoL
--HG--
extra : rebase_source : 23d05a9a0dc95ff3705551a5d85d90d6ed8f950f
extra : histedit_source : 166a8dbf4fb63de7e926fb292de07c550db96d78
Currently we have a mess of targets in packager.mk which doesn't really help
much. This patch removes the make-buildinfo-file and make-mozinfo-file targets
and just puts their commands inline in the make-package target.
MozReview-Commit-ID: 7j83dC4QoZY
--HG--
extra : rebase_source : b9aa73f5839903a68e2cbfe88a964519f395060a
extra : histedit_source : 7208f20b3437f47d3f8fcdd734fe40b602be28f5
This script is already doing most of the work, so make it write the text
file instead of using shell commands.
MozReview-Commit-ID: HfFTlNaPSst
--HG--
extra : rebase_source : 30bb2670f24b495809bfaca4a7c63f478291d5ab
extra : histedit_source : 343c70f4d2c0ebc6b7e01f5d0a19cd3853b15739
The `make-buildinfo-file` target is called as part of `make package` to
generate a json file and a text file with some info about the build. Because
a few of those things like the Build ID and source repo / changeset are not
guaranteed to be set at configure time it has to pass them down from the make
environment.
In CI all of these things are passed in the environment, populated at task
graph generation time, so doing this work only in automation builds lets
us simplify things a bit.
MozReview-Commit-ID: 5Ygd3XmSA8x
--HG--
extra : rebase_source : 233f88e436bbf6c3a57d8495f0d92f0aedf98ec5
extra : histedit_source : 735e40632e4b697b6bc32dd15f194e9f02a66f7f
The argument is never used in the local file copying function. So let's
nuke the argument.
MozReview-Commit-ID: JeU4LaVvGD7
--HG--
extra : rebase_source : 0e305c5bff0e3871fd11a554d75e7f53ceea4bdd
This was only used for the remote server case. That code was recently
deleted.
MozReview-Commit-ID: 7usqWZ7CuBR
--HG--
extra : rebase_source : f27b37391802a2980feffa5d88c92228d137824f
extra : source : 46b8a00288c8d7b88fd9b7aee20e88ddfd96d57b
We currently generate these to dist/ and then use upload.py to copy
them into UPLOAD_PATH. This is wasteful. Let's generate the test
archives into UPLOAD_PATH directly, if the variable is defined.
MozReview-Commit-ID: BHoxZYdxzq4
--HG--
extra : rebase_source : f6d80adb4e1eb7333f0cd3f847fd92cbb75c33bc
checksums.py is now run after upload.py, as part of the "upload" make
target.
As part of the refactor, checksums.py now takes as arguments a list of
directories containing files to checksum. It will recursively checksum
all files in listed directories.
This means we no longer have to pass an explicit list of files into
checksums.py. Instead, we can pass the artifact directory and
automatically checksum everything within. This will allow us to
generate files directly into the artifact directory instead of
having to run upload.py to copy files there.
MozReview-Commit-ID: 6ntnXU2Pp0E
--HG--
extra : rebase_source : 7e019b366f14b3692ec702ff331a1e0306dc3805
The argument is never used in the local file copying function. So let's
nuke the argument.
MozReview-Commit-ID: JeU4LaVvGD7
--HG--
extra : rebase_source : a898814f4084288200928f062fbb06ffbbae60bd
This was only used for the remote server case. That code was recently
deleted.
MozReview-Commit-ID: 7usqWZ7CuBR
--HG--
extra : rebase_source : 39c33057aab6773f8f85b1294e4965965954d9e6
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
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 65bac47c2cd1a20b3c675a01b44a25a1d2d3ab7a
Now that XPT files are not loaded from files at runtime, code for
packaging XPT files can be removed.
This means that a couple of test XPIDL interfaces will get shipped in
builds to users that weren't before, but I don't think that matters
much.
This also puts XPT files into the local objdir for the XPIDL makefile,
instead of dist/bin, because they are no longer part of the
distribution.
MozReview-Commit-ID: 7gWj8KWUun3
--HG--
extra : rebase_source : 6f7d4fd1d6cdea2c14866705a2dc972eb5f43382
Currently, clicking the close button or otherwise trying to exit the Windows
stub installer always ends up canceling the installation. This patch prompts
the user to either continue or cancel the installation.
MozReview-Commit-ID: 4KMgCcyjTnv
--HG--
extra : rebase_source : 0c0636c9c02fabd32df37471033d8e847caea5d3
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
This is a non-elegant solution to get a simple source.tar.xz package name.
Any pretty-naming is done on the beetmover side, although as of this writing
we'll upload source.tar.xz there, as well:
https://github.com/mozilla-releng/beetmoverscript/pull/106
MozReview-Commit-ID: 83Xz5Bxl7WA
--HG--
extra : rebase_source : 49942f3722de5f4a721536b0f6cb592ee3d68ac3
This is the easy stuff -- everything but mobile/android/base/Makefile.in.
MozReview-Commit-ID: 5x2z97AHUrR
--HG--
extra : rebase_source : 531fd41d367cad071b209b85ca5b5602fd7cbf7b
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This requires unlocking the unstable features in the rust compiler
by using RUSTC_BOOTSTRAP=1
MozReview-Commit-ID: 1uUG1Ekp1YH
--HG--
extra : rebase_source : d8a5aa5d13f3ee055de8a544b0d5ca8af0aab751
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
Right now, we only expect classes.dex, and even --with-gradle we copy
it out of $topobjdir/mobile/android/base. This commit changes that
for --with-gradle: we only take classes.dex from the given .ap_ file,
and we also handle multiple classesN.dex files (for future multi-dex
support). The moz.build system stays the same.
This avoids an issue with newer Android-Gradle plugins, where the
classes.dex produced could be either in dex/ or in dexMerger/,
depending on whether any external libraries needed merging. By
extracting classes.dex from the .ap_ file, we don't need to know what
Gradle build steps actually occur.
The classes.dex in the package-manifest.in has been irrelevant since
Bug 1260241.
MozReview-Commit-ID: FozKwjTcMzU
--HG--
extra : rebase_source : 62b18c7ffe596be73cec4c9565333eac222b018e
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Bug 1024110 changed the WM class, and bug 1333826 removed the SDK and
the createdevel and related variables.
--HG--
extra : rebase_source : 599ab1998a5d6d471ab7928d782dde1c79ad4734
These magic locations evolve over time. Baking them into
moz.configure is the easiest way to share them across the build
system, and pushing them into a new |mach android *| command continues
a pattern that has been very successful.
MozReview-Commit-ID: CyxVQ0LHHgl
--HG--
extra : rebase_source : 8350d71665f0126aa4ee2c8fec32c4b8e34dc772
These magic locations evolve over time. Baking them into
moz.configure is the easiest way to share them across the build
system, and pushing them into a new |mach android *| command continues
a pattern that has been very successful.
MozReview-Commit-ID: CyxVQ0LHHgl
--HG--
extra : rebase_source : 8350d71665f0126aa4ee2c8fec32c4b8e34dc772
Single-locale repacks do the following:
Download existing APK; unzip APK; update l10n resources; |mach package| with IS_LANGUAGE_REPACK=1.
This is pretty hard to accommodate, but we can try. The key issues
here are to recognize when IS_LANGUAGE_REPACK=1 and not ask for l10n
resources (in particular, strings.xml) to be generated.
We do need to include the freshly built classes.dex when repackaging,
because newer Gradle/aapt doesn't preserve the R.java IDs.
MozReview-Commit-ID: 9FvQtmPOUjg
--HG--
extra : rebase_source : b0440ceb318662bf3c08f2139c51dae5775a6b38
Single-locale repacks do the following:
Download existing APK; unzip APK; update l10n resources; |mach package| with IS_LANGUAGE_REPACK=1.
This is pretty hard to accommodate, but we can try. The key issues
here are to recognize when IS_LANGUAGE_REPACK=1 and not ask for l10n
resources (in particular, strings.xml) to be generated.
We do need to include the freshly built classes.dex when repackaging,
because newer Gradle/aapt doesn't preserve the R.java IDs.
MozReview-Commit-ID: 9FvQtmPOUjg
--HG--
extra : rebase_source : 6a34a8c299138ea39c6703f334c8fd5f49b03237
This commit adds two new xpcshell tests, both of them testing whether the
security state in TransportSecurityInfo includes the new
STATE_CERT_DISTRUST_IMMINENT flag under the correct circumstances.
The first test, test_symantec_apple_google.js, tests the four combinations of
certs that chain to an affected Symantec root: with/without a whitelisted
intermediate, and before/after the notBefore cutoff date.
The second test, test_symantec_apple_google_unaffected.js, tests an unrelated
ca->intermediate->ee chain that does not chain to an affected root, and ensures
the flag is not set.
This patch adds SymantecSanctionsServer to the mozbuild and xpcshell test
infrastructure files to ensure it runs properly on TaskCluster, too.
MozReview-Commit-ID: GtUXH2VFFh
--HG--
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.key => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.key
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.key.keyspec => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.key.keyspec
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.pem => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.pem
rename : security/manager/ssl/tests/unit/bad_certs/default-ee.pem.certspec => security/manager/ssl/tests/unit/test_symantec_apple_google/default-ee.pem.certspec
rename : security/manager/ssl/tests/unit/tlsserver/cmd/BadCertServer.cpp => security/manager/ssl/tests/unit/tlsserver/cmd/SymantecSanctionsServer.cpp
extra : rebase_source : f399bca5a13db3efa5bbaa5136c8effc3948ed5e
The goal is to use a newer Android-Gradle build plugin version (2.3.3
is latest stable). That requires a modern Gradle (anything 3.3+, but
3.4.1 is the default from my Android Studio), and also a newer
build-tools (25.0.3 is latest stable).
The locations of lint output changed, and we want to use the standard
output location because it's difficult to accommodate variant details
in custom names. We change the location of findbugs output to follow
suit.
This requires either:
- fixing lint errors
- adding to the lint whitelist
- using the new lint baseline
It's best to use the new lint baseline, which will happen in the next commit.
MozReview-Commit-ID: D19FzIDCJrE
--HG--
extra : rebase_source : 12d132c0c3e0dbe2b8873b31360ea96d612de44c
By using the PartialConfigEnvironment, the clients of buildconfig will
depend on config.statusd/ files instead of config.status directly.
Clients can access substs and defines using buildconfig.substs['FOO'] or
buildconfig.defines['BAR'], and then collect file-level dependencies for
make using buildconfig.get_dependencies(). All GENERATED_FILES rules
already make use of this because file_generate.py automatically includes
these dependencies (along with all python modules loaded).
As a result of this commit, re-running configure will no longer cause
the world to be rebuilt. Although config.status is updated, no build
steps use config.status directly and instead depend on values in
config.statusd/, which are written with FileAvoidWrite. Since those
files are not official targets according to the make backend, make won't
try to continually rebuild the backend when those files are out of date.
And since they are FileAvoidWrite, make will only re-run dependent steps
if the actual configure value has changed.
As a result of using JSON to load data from the config.statusd
directory, substs can be unicode (instead of a bare string type).
generate_certdata.py converts the subst manually to a string so the
value can be exported to the environment without issue on Windows.
Additionally, patching the buildconfig.substs dict no longer works, so
the unit-symbolstore.py test was modified to patch the underlying
buildconfig.substs._dict instead.
The other files that needed to be modified make use of all the defines
for the preprocessor. Those that are used during 'mach build' now use
buildconfig.defines['ALLDEFINES'], which maps to a special
FileAvoidWrite file generated for the PartialConfigEnvironment.
MozReview-Commit-ID: 2pJ4s3TVeS8
--HG--
extra : rebase_source : d6bb0208483f9f043e7be1b36907ca13243985f8
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
The hyphenation dictionaries we ship as part of the build don't depend
on the UI locale, let's stop treating them as localizable content during
repacks.
MozReview-Commit-ID: FTrw4KDtops
--HG--
extra : rebase_source : f6ddb22154fc66da0a7cdc56a4cecb58c9e3d54b
This change makes us upload an `$(PKG_BASENAME).generated-files.tar.gz` archive
alongside other build artifacts which contains all the generated source files
from the build. A change after this will introduce an `upload-generated-sources`
task to take this artifact and upload the individual files to an S3 bucket.
This will be used to provide links to generated source files when they appear
in stack traces in crash reports.
MozReview-Commit-ID: 6yQAdlZ5q3O
--HG--
extra : rebase_source : d92fb17ae737d1360e9724997f6688e29bedef12
extra : source : 14d18d7cf454c4c3d0f6d49d1d01660e06e4be4b
This change makes us upload an `$(PKG_BASENAME).generated-files.tar.gz` archive
alongside other build artifacts which contains all the generated source files
from the build. A change after this will introduce an `upload-generated-sources`
task to take this artifact and upload the individual files to an S3 bucket.
This will be used to provide links to generated source files when they appear
in stack traces in crash reports.
MozReview-Commit-ID: 6yQAdlZ5q3O
--HG--
extra : rebase_source : 3f6ef734c062e0f5e9c2ca433ffad51fdf14b1ad
We should now only maintain Photon flavor. Remove all Australis related configuration in build scripts.
MozReview-Commit-ID: H4LE8LAso42
--HG--
extra : rebase_source : 2d5a05e43b261d573677834210a7b3fb18aebcac
Matt Howell
Kartikaya Gupta
Mike Hommey
Adam Gashlin
Ian Moody
Nick Alexander
Francesco Lodolo (:flod)
Gurzau Raul
Robert Strong
Kris Maglione
Chris Manchester
Aaron Klotz
Cosmin Sabou
Mike Shal
William Lachance
Ed Lee
Kirk Steuber
Bogdan Tara
Tom Ritter
Ciure Andrei
Tom Prince
Nathan Froyd
Christian Holler
Chris AtLee
Michael Kaply
shindli
Ted Mielczarek
David Major
Xidorn Quan
Gregory Szorc
Brindusan Cristian
MatthieuBaratte
Andrew McCreight
Dorel Luca
Emilio Cobos Álvarez
Csoregi Natalia
Aki Sasaki
Philipp Kewisch
Zibi Braniecki
Sebastian Hengst
Hector Zhao
Sylvestre Ledru
Ting-Yu Chou
Bill McCloskey
J.C. Jones
maliu
Axel Hecht
Eric Rahm
Wes Kocher
Jing-wei Wu