If configure has defined VCS binaries, we should use those.
MozReview-Commit-ID: DVnsSaJC8eN
--HG--
extra : rebase_source : 64e944841817e7fa0300bc6ed3bce3325e93781a
The --track flag provides a more accurate accounting of what files were
installed by the manifest, so they can be appropriately removed. For
example, test files are now removed from _tests if an entry in a test
file is deleted.
The --no-remove flag is removed as an alternative, and the --track flag
is now mandatory.
MozReview-Commit-ID: Wiup4Gzwkb
--HG--
extra : rebase_source : 4a44c7fe066ba9b5f1e37ec682464f7f4f6cb2cf
This patch removes the ability to select which protocols you want
included in necko, a wholly untested configuration that is broken in
practice. We have no need of this kind of configurability in necko.
In addition, this removes the final vestiges of rtsp support, which was
originally removed in bug 1295885 but still had some stuff hanging
around behind some ifdefs (that were never true).
MozReview-Commit-ID: KOEaDmit2IL
--HG--
extra : rebase_source : f6c2fdb972aaba46e922cda801252dc953550b94
This change adds an upload-generated-sources task kind that runs after nightly
builds, fetches their `target.generated-files.tar.gz` artifact, and uploads
all the contained files to an S3 bucket. For actual nightly and release builds
on SCM level 3 trees, the S3 bucket is configured to be publicly accessible,
so that tools like Socorro will be able to fetch generated source files that
appear in crash reports, and debuggers will be able to fetch generated sources
when they show up while debugging Nightly or Release builds.
There are also level-2 and level-1 S3 buckets configured for builds happening
on trees of other levels such as try. They are not configured as publicly
accessible, but they exist so that these tasks can be tested in try.
MozReview-Commit-ID: Js1HRftbtep
--HG--
extra : rebase_source : b1172c9cc8b8be437d3b94a6bf0ff6b2f7d3508b
extra : source : 73bf88110b3821d62a3d393e85b56896a12f2930
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
Ensure stream only has a single LZMA block.
Ensure that dictionary size is always 8 MiB.
MozReview-Commit-ID: A0CV6M3LIf9
--HG--
extra : rebase_source : e5e35a33dd34a9eebae46f94c1c0fabf74038946
Tooltool manifests contain digests that have been used to validate
tooltool downloads. Toolchain artifacts don't benefit from that, and as
a result, an incomplete download can be considered as finished, and
unpack fail after that, without retrying, even with --retry.
Fortunately, the chain of trust artifacts do contains digests for
taskcluster artifacts, as long as the jobs that created the artifacts
have chain of trust enabled.
As of now, the goal is not cryptographic validation of the download, but
to ensure that we got the complete file, and to trigger a new download
if we haven't.
--HG--
extra : rebase_source : cdf4b4ec0c99db1f671db799f3941804f2bcbaf9
We define extra_toolchain_flags for passing extra flags to the target
compiler during configure. But the way things are currently set up, we
pass those flags to the host compiler during configure as well. This
behavior is incorrect, and we should only be passing the flags from
extra_toolchain_flags if we're compiling for the target.
When the tooltool manifest contains e.g. clang.tar.bz2 and it's also
provided by some toolchain job artifact, we still download both. In
fact, depending how things go, the tooltool one could take precedence.
In practice, this hasn't caused problems so far because we've removed
tooltool manifest items early on, and when we didn't, it was still the
same version as provided by toolchain jobs.
It is still necessary to fix for the future, though.
--HG--
extra : rebase_source : 1d187333ee6149f72e3f9ed91eb1a6a78ad9197f
Other related changes:
* Only target.{zip,tar.gz,tar.bz} get the widevine signature (not the various installers).
* Linux{32,64}-nightly are now repackaged. Their mar files are not signed during signed step anymore. It now happens after the repackage.
* As a consequence, funsize routes for linux are now set to repackage-signing (instead of signing)
* Signed upstream artifacts are now defined in a dedicated module (to avoid duplication)
* Platforms defined in beetmover_repackage now allow regex (to reduce duplication too)
* Mozharness configs: Delete unused (and misleading) `src_mozconfig` for windows. This value is actually not used when `run_configure` (in the same dict) is set to False.
MozReview-Commit-ID: COKqevW9Mzn
--HG--
extra : source : ffc2e43aa834e05f0d51d68dfb36317c1b408b08
Various people want to start experimenting with Python 3 in the build
system and in related tools (like mach).
We want to make it easy to find and use an appropriate Python 3
binary.
This commit introduces a generic function for finding a Python 3
binary and resolving its version.
We use the new code in configure to set PYTHON3 and PYTHON3_VERSION
subst entries for later consultation.
We also expose a cached attribute on the base class used by many
mach and build system types to return a Python 3 executable's info.
By default, we only find Python 3.5+. From my experience, Python 3.5
was the first Python 3 where it was reasonable to write code that
supports both Python 2 and 3 (mainly due to the restoration of the
% operator on bytes types). We could probably support Python 3.4
in the build system. But for now I'd like to see if we can get
away with 3.5+.
MozReview-Commit-ID: BlwCJ3kkjY9
--HG--
extra : rebase_source : b00464972183ef1a97a0b5d888520be425717ae7
A recent mercurial update changed the order of revisions returned by the
"last" revset. The expected revisions are still output, so the artifact
code is updated in this change to impose its own order based on the local
revision order to accommodate any output order.
MozReview-Commit-ID: 7Zka0kQtxJO
--HG--
extra : rebase_source : 415077a806053c0452e4f9dec997a0e40934e51d
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
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
This mechanically replaces nsILocalFile with nsIFile in
*.js, *.jsm, *.sjs, *.html, *.xul, *.xml, and *.py.
MozReview-Commit-ID: 4ecl3RZhOwC
--HG--
extra : rebase_source : 412880ea27766118c38498d021331a3df6bccc70
Update scripts to support both lzma and bzip2
Update unused python script to support lzma. This also adds python 3.0 support to the script while still supporting pythin 2.7
Update test scripts to support lzma
f497b6194e9f bumped the minimum Java version requirement in configure
from 1.7 to 1.8. It forgot to update tests that were pinning the
Java version at 1.7. The tests then failed.
We bump the versions in tests to restore order.
CLOSED TREE
MozReview-Commit-ID: 1zm5L1QQy7a
--HG--
extra : rebase_source : 8868224b5a1a8ffbb633b638df9485760f84fd8a
extra : amend_source : 3faa435ab5478c62aefb3dc18de19256ce0d906e
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
Prefs can be set with `./mach run --setpref foo=bar` or in the ~/.mozbuild/machrc file as:
[runprefs]
foo=bar
MozReview-Commit-ID: HO3tdFi9ffi
--HG--
extra : rebase_source : 3c2e6f33567448c19defafb656e6cb9f3a729391
Capture the list of generated source files derived from moz.build data
and save it in a generated-sources.json in the objdir so that we can upload
generated source files for use in crash reports and when debugging release
builds.
MozReview-Commit-ID: FrHcyFo0rBF
--HG--
extra : rebase_source : 09a5a38d22430e9a2c8121ddc8d47fabdd3be705
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
