Until we have clang builds, we want nightlies to be built with msvc, so
configure the nightly build as msvc.
Differential Revision: https://phabricator.services.mozilla.com/D14657
--HG--
extra : moz-landing-system : lando
XZ supports rewritting addresses in executable code, which is architechture
specific. The updater is compiled with support for the target architecture
only, so we can't always compress updates passing `--x86` to XZ. This threads
the architecture through to the repackage steps, so we can pass the appropraite
flags to the update packaging scripts.
Differential Revision: https://phabricator.services.mozilla.com/D14601
--HG--
extra : moz-landing-system : lando
Although this task technically doesn't build a toolchain, the set of
steps it needs to do is very similar to what a toolchain build does, so
we're shoehorning this task into the toolchain kind. The task basically
runs `cargo vendor` on the gfx/wr/Cargo.lock file (if/when it changes)
and exports a tarball of the resulting vendored crates. This allows
downstream tasks that build stuff in gfx/wr to not have to re-fetch
these crates from crates.io on every test run.
Differential Revision: https://phabricator.services.mozilla.com/D14406
--HG--
extra : moz-landing-system : lando
This appears to "just work."
While I would like to convert this image to Debian and make it
deterministic, that is more effect than I'm willing to invest at the
moment.
The impetus for this change is unblocking partial clones. Mercurial's
SQLite storage backend apparently hits a SQLite bug in version 3.11
of SQLite (what Ubuntu 16.04 runs) where SQLite complains about
database corruption when there are readers from multiple processes.
Ubuntu 18.04 is running SQLite 3.22 and doesn't exhibit the buggy
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D14228
--HG--
extra : moz-landing-system : lando
This patch adds a toolchain task for building d8 with customized build settings and uses it in jsshell benchmark tests. A customized image with a debian9-base ('custom-v8') is added by this patch as well and is required to build the tool.
Differential Revision: https://phabricator.services.mozilla.com/D14019
--HG--
extra : moz-landing-system : lando
The SQLite in Debian 7 (3.7.13) lacks support for common table
expressions (the WITH keyword), which was introduced in SQLite
3.8.3. The Mercurial SQLite storage backend currently relies on
CTEs. Even if a future Mercurial doesn't require CTE, it is likely
that it will still use CTE if available for performance reasons.
So, it is in our best interest to give Mercurial access to a
modern SQLite. Plus, using a modern SQLite and avoiding potential
bugs in old versions seems prudent.
This commit introduces a SQLite package backport for Debian 7
so we can use the new SQLite feature. We had to minimally patch
the build to work with an older version of TCL that isn't using
multiarch.
I observed libsqlite3 being installed as part of building various
other packages (such as Python). I initially added the package as
a dependency so packages would be built against a more modern
SQLite. But glandium doesn't believe it matters, since nothing
should be doing build-time feature detection. Python is the most
important downstream package (since Mercurial uses its SQLite).
I audited the CPython build system and did not see any build-time
SQLite feature detection or version sniffing. So I think we'll be
fine building against an older SQLite.
Differential Revision: https://phabricator.services.mozilla.com/D14194
--HG--
extra : moz-landing-system : lando
This appears to "just work."
While I would like to convert this image to Debian and make it
deterministic, that is more effect than I'm willing to invest at the
moment.
The impetus for this change is unblocking partial clones. Mercurial's
SQLite storage backend apparently hits a SQLite bug in version 3.11
of SQLite (what Ubuntu 16.04 runs) where SQLite complains about
database corruption when there are readers from multiple processes.
Ubuntu 18.04 is running SQLite 3.22 and doesn't exhibit the buggy
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D14228
--HG--
extra : moz-landing-system : lando
This provides an easy way to encode an artifact URL in static data such as
taskcluster/ci/nightly-l10n/kind.yml. This could be used in
mozharness_test.py, for example, as well -- but other code (such as to support
backfilling) expects `task-reference` there. To avoid breaking such subtle
bits, those can continue using `task-reference` with URLs generated based on
TASKCLUSTER_ROOT_URL.
Differential Revision: https://phabricator.services.mozilla.com/D14197
--HG--
extra : moz-landing-system : lando
Eventually, workers will provide these variables directly
(https://bugzilla.mozilla.org/show_bug.cgi?id=1460015). But for now, this
ensures that TASKCLUSTER_ROOT_URL is set everywhere, and TASKCLUSTER_PROXY_URL
is set wherever the proxy is active.
The setup for the mach commands defaults to https://taskcluster.net for user
convenience. When the production instance's URL changes, we can simply change
that default.
This changes the docker build process to propagate TASKCLUSTER_ROOT_URL into
the docker images, and for good measure includes some code to use that value to
generate debian repo paths.
Differential Revision: https://phabricator.services.mozilla.com/D14196
--HG--
extra : moz-landing-system : lando
No functional change, since we're removing the WPT tests from the
windows-tests test-set, but thenn running the wpt test-set everywhere we
currently run windows-tests. It just annoys me that we have a separate
set for these tests but we aren't using it properly.
Differential Revision: https://phabricator.services.mozilla.com/D14866
--HG--
extra : moz-landing-system : lando
This matches more closely cross toolchains prefixes (as can be seen in
e.g. media/libvpx/libvpx/README for x86_64-darwin*-gcc), and leaves it
to the build system to figure out the right --target to pass to clang on
its own.
Differential Revision: https://phabricator.services.mozilla.com/D14376
