The task has actually never produced a mac binary: it builds a linux
one. And nothing depends on the task so it's not worth fixing.
Differential Revision: https://phabricator.services.mozilla.com/D125632
The reason the error mentioned in build-mingw32-nsis.sh happens is that
the default mode NSIS builds in is a fully-installed mode, where it
hardcodes the locations of its data files. This is why nsis needs to
be used from the same place it's built for. But there's another mode,
enabled with NSIS_CONFIG_CONST_DATA_PATH=no, that makes it relocatable,
and makes it find its data files relatively to the nsis binary.
However, there's a bug in the nsis build scripts, which makes the nsis
binary installed in the destination directory instead of a bin/
subdirectory, while the source code itself looks for data files relative
to the parent directory of the directory that contains the executable.
So we need to set PREFIX_BIN to force the executable to be installed in
a bin/ subdirectory.
There is also an issue in nsis itself when it's executed by anything
other than a shell, which we patch out.
Differential Revision: https://phabricator.services.mozilla.com/D125638
While the comment at the top of build-mingw32-nsis.sh is true, it only
applies to nsis being in the same path in the build tasks as it was
built from in the toolchain task. So we don't actually need to build
it in a mingw32/bin directory, and can ship it in a nsis/bin directory,
as long as that's where we build it.
That makes the toolchain match the expectations from bootstrap, which
also makes PATH adjustments for nsis unnecessary, no other toolchain
used in those builds providing a binary in mingw32/bin.
Differential Revision: https://phabricator.services.mozilla.com/D125637
There are complications with building a 1-stage clang with gcc, so just
use clang. Eventually, the clang-tidy toolchains will be removed in
favor of providing clang-tidy from the clang toolchain itself anyways.
Differential Revision: https://phabricator.services.mozilla.com/D125158
We set always-target: true for Python unittest tasks. This means they show up on every push (when appropriate files are modified). The reasoning behind this is that they run so fast anyway, and if you modify the relevant code then you almost always want to see the unittests for said code on your try pushes.
However on MacOS, the pool is limited. Given the differences between Linux and Mac for most Python unittests are likely extremely small, I don't think the cost of bogging down the Mac pool outweighs the benefits here.
Differential Revision: https://phabricator.services.mozilla.com/D125281
It contains a more recent version of GTK, fixing some Wayland issues
that are still present in the 20.08 version (notably degraded
performance due to missing opaque region API in GTK).
Further more it ships more recent Mesa, which should also have
a positive effect on some hardware.
Differential Revision: https://phabricator.services.mozilla.com/D124801
Here's the task diff for mozilla-central:
+test-linux1804-64-ccov-qr/opt-mochitest-browser-chrome-swr-fis-e10s
-test-linux1804-64-ccov-qr/opt-mochitest-devtools-chrome-e10s
+test-linux1804-64-ccov-qr/opt-mochitest-devtools-chrome-fis-e10s
-test-linux1804-64-ccov-qr/opt-mochitest-plain-e10s
+test-linux1804-64-ccov-qr/opt-mochitest-plain-fis-e10s
+test-linux1804-64-ccov-qr/opt-mochitest-plain-fis-xorig-e10s
-test-linux1804-64-ccov-qr/opt-web-platform-tests-e10s
+test-linux1804-64-ccov-qr/opt-web-platform-tests-fis-e10s
Note we weren't previously running any ccov browser-chrome tasks on Linux so
that's why no task was removed on that configuration.
Differential Revision: https://phabricator.services.mozilla.com/D124400
It made sense when we did have problems with the one shipped with clang
and needed an explicitly newer version, but that hasn't been true in a
while. On the contrary, we're now using a version older than clang for
no reason other than having forgotten to update it.
Differential Revision: https://phabricator.services.mozilla.com/D124886
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
The linux workers used for windows builds currently install both
win64-dump_syms and linux64-dump_syms, and the only reason it works is
that their artifacts have different names currently, which is not going
to be the case anymore.
Differential Revision: https://phabricator.services.mozilla.com/D124879
It used to be installed as a side effect of something else, but is not
installed anymore after the upgrade to Debian 11.
Differential Revision: https://phabricator.services.mozilla.com/D124984
This replaces Gecko's old '--diff' implementation with the one included with
standalone taskgraph.
Note this revision is a straight sync from standalone taskgraph and should not
contain any additional changes.
Depends on D124835
Differential Revision: https://phabricator.services.mozilla.com/D124836
It contains a more recent version of GTK, fixing some Wayland issues
that are still present in the 20.08 version (notably degraded
performance due to missing opaque region API in GTK).
Further more it ships more recent Mesa, which should also have
a positive effect on some hardware.
Differential Revision: https://phabricator.services.mozilla.com/D124801
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
The linux workers used for windows builds currently install both
win64-dump_syms and linux64-dump_syms, and the only reason it works is
that their artifacts have different names currently, which is not going
to be the case anymore.
Differential Revision: https://phabricator.services.mozilla.com/D124879
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
