While this looks like going backwards, it is desirable to build clang
against GCC 4.8, such that it contains its libgcc. This, in turn, will
solve problems using clang 3.9 with static-analysis builds (details in
bug 1356926). Another way to fix those problems would be to build clang
3.8 but that too would require GCC 4.8. Upgrading those builds to clang
3.9 will also allow to enable stylo on them.
It becomes a library of some sort, so that multiple scripts can benefit
from it to build different versions of GCC.
The GPG key associated with GCC is also refreshed from keys.gnupg.net,
adding a new subkey, used to sign newer versions of GCC (and
postprocessed with pgpstrip to make it smaller).
We're soon going to build multiple versions of clang and gcc for linux,
and we need to differentiate them. Furthermore, there is a need for the
base-toolchains builds to use a fixed version of clang and gcc. So
rename the clang and gcc toolchain jobs to include their version, add
aliases to satisfy all existing jobs, and adjust the base-toolchains
jobs to use the explicit version.
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-3.9-linux64.json
rename : taskcluster/scripts/misc/build-gcc-linux.sh => taskcluster/scripts/misc/build-gcc-4.9-linux.sh
Allow an extra heap write hazard introduced by enabling stylo
in default builds until it can be addressed. See bug 1384625.
MozReview-Commit-ID: 2N3z6FVHa0G
--HG--
extra : rebase_source : d4c9c18c34ab829b59b9e16ec3cd8e736c418fd3
With the support added in bug 1382564, toolchains can be downloaded
without a tooltool manifest at all, and it's desirable to get rid of
tooltool manifests on jobs that don't need one.
--HG--
extra : rebase_source : 340d935034133f4f6d8aec3d15154736092859fa
The MinGit tooltool package used for Windows builds comes straight from
https://github.com/git-for-windows/git/releases/
This builds the version currently used on automation.
--HG--
extra : rebase_source : dbc2a36b07611e673d6661032ad53123a688d422
This affects the location of the artifacts directory, so adjust the
scripts and artifact definitions as a consequence.
--HG--
extra : rebase_source : 008b8cf33957eabfcacee61de8a260b5df146ab4
Bug 1374940 adds a MOZ_TOOLCHAINS environment variable with a list of
path@task-id strings, where task-id is corresponding to the (possibly
optimized) toolchain job, and path corresponding to the
toolchain-artifact defined for that toolchain job.
We want to use that to pull artifacts instead of tooltool packages.
--HG--
extra : rebase_source : 277daa2c83d6d197975cb4ef36ee131176afa992
This is a quick work around for not blocking the progress of Bug 1380133.
We should definely investigate the real root cause sooner than later.
MozReview-Commit-ID: 8X1FH6f2GyN
--HG--
extra : rebase_source : 9edaec6a50f7251e3c05d9fbc252e1385d82a1bb
This is a quick work around for not blocking the progress of Bug 1380133.
We should definely investigate the real root cause sooner than later.
MozReview-Commit-ID: 8X1FH6f2GyN
We're about to make MOZ_AUTOMATION more strict about things like having
a source checkout.
The whole point of build-sm-package.sh is to verify that SpiderMonkey
can be built outside of Mozilla's source repo and automation from a
standalone package. Since the presence of MOZ_AUTOMATION can influence
so much behavior in the build system, unset it so that the job
tests a !Mozilla environment more accurately.
MozReview-Commit-ID: EMfyLKfY0uU
--HG--
extra : rebase_source : 3632a9abf9fac3f916ed9043f30d4b6aa4abb390
We're about to make MOZ_AUTOMATION more strict about things like having
a source checkout.
The whole point of build-sm-package.sh is to verify that SpiderMonkey
can be built outside of Mozilla's source repo and automation from a
standalone package. Since the presence of MOZ_AUTOMATION can influence
so much behavior in the build system, unset it so that the job
tests a !Mozilla environment more accurately.
MozReview-Commit-ID: EMfyLKfY0uU
--HG--
extra : rebase_source : 3632a9abf9fac3f916ed9043f30d4b6aa4abb390
The scripts that use tooltool-download.sh don't run regularly, but when
they do, they might hit some download problems (the relengapi proxy
tends to be rather unreliable for some reason), and in that case, it
would be better to retry a few times, like other job types, rather than
fail directly.
--HG--
extra : rebase_source : d85797f8eebff9be5b8bfc45fc14dfaf8d5a59f3
All the current users of tooltool-download.sh set $WORKSPACE. This will
allow to reuse the script on different types of workers, that don't have
$WORKSPACE set to $HOME/workspace, but still have the source in
$WORKSPACE/build/src.
--HG--
extra : rebase_source : c91542da70109e5708a009542a0f588e30b541a9
Using /home/worker is the build directory has a 30% talos performance
loss, because test machines has a /home mount directory.
MozReview-Commit-ID: zehcGJrUQX
--HG--
extra : source : feedcde68c2a54da210f03eb287ab5c862fc982b
extra : intermediate-source : 485d1af7805ad9fa0e701c3571fc1291fbfc6850
The toolchain build scripts are currently defining the tooltool
manifest they use on their own. We move the definitions to the
taskcluster job definitions to normalize on everything using that.
--HG--
extra : rebase_source : cbab2e32d78d711fcb595763d0c2600c7c0c423e
Hazard jobs use a specific tooltool-manifest field in their definition.
Since there is no post-processing happening on those definitions, and
since generalizing it would require adding the field to a bunch of
validation schemas, and the same code to various transforms, it's just
simpler to move to use environment variable definitions here too.
Eventually, tooltool manifests won't be necessary anyways, and those
environment variables will go away.
--HG--
extra : rebase_source : bd619024bde051424a2d811a1996caaf0f853247
The mozharness_test job was using the wrong artifact path for native-engine.
Native-engine also enforces that artifact directories exist, so include some
mkdir calls to keep it happy.
MozReview-Commit-ID: Evw34gzzLev
--HG--
extra : rebase_source : 6ecf21e7d3516b8995f73e027666b39df31b0256
This makes talos obey the `-w` try syntax flag.
MozReview-Commit-ID: 2v6X3ko2t9K
--HG--
extra : rebase_source : 6d155ae390a4e3afc6499e8cd2f6a7f5459b12b7
extra : source : 6a561e8a5c2619fa4809dab1d7a90898e551b599
It was previously renamed in the Dockerfile, and that's unnecssarily confusing
when looking for the file in hg.
MozReview-Commit-ID: 7bwD4cjk4Pj
--HG--
rename : taskcluster/scripts/tester/test-ubuntu.sh => taskcluster/scripts/tester/test-linux.sh
extra : rebase_source : f22cd0f69c21e92126cc90ea3a4355e5c3db4205
A quick fix for hazard bustage by increase the NUM_ALLOWED_WRITE_HAZARDS
from 3 to 7 is pushed in bug 1348173 comment 37. In this bug, we shall do
the actual fix and restore the NUM_ALLOWED_WRITE_HAZARDS.
The -moz-border-*-colors bindings trigger errors because they're using
outparams (nsStyleBorder) which further manipulate its member (mBorderColors)
which is a double raw pointers. Since we don't have the ability to
whitelist the indirect access to mBorderColors[x] list, we can only add
them to the ignoreContents for now.
We might be able to move these bindings to the whitelist of the above
treatAsSafeArgument function, if we could refactor mBorderColors to use
nsTArray directly.
MozReview-Commit-ID: 2cQz58K2A10
--HG--
extra : rebase_source : af2b5b944fb9d19fe28f57eaa37f77174d48bfa4
Mike Hommey
Nick Alexander
Ralph Giles
Cameron McCormack
Jeremy Chen
Sebastian Hengst
Gregory Szorc
Ryan VanderMeulen
Wes Kocher
Wander Lairson Costa
Manish Goregaokar
Dustin J. Mitchell
Steve Fink