I've left the monitor disabled for now, so that we can have a smaller pushes for enabling and disabling it if needed. It should allow more fine grained control.
We may also want to include extracting the monitor tool from a github version instead, and also removing the assumption and it being forked from the parent, so that it's instead given a process ID to treat as the parent it should watch.
Differential Revision: https://phabricator.services.mozilla.com/D84374
This adds a makecab toolchain for Linux. It's not hooked anywhere
because bug 1654994 will also move the use of makecab to upload-symbols
tasks, so hooking the toolchain up with builds would be a waste of
time.
Differential Revision: https://phabricator.services.mozilla.com/D84789
We don't need this for our (current) builds, which are cross-builds, but we
would need this at some future date if we ditched the breakpad `dump_syms`.
Depends on D83528
Differential Revision: https://phabricator.services.mozilla.com/D83529
These scripts don't call `build-clang.py`, they just repackage artifacts from other tasks that do.
I went with `repack` over `repackage` since that seems to be the established pattern in `taskcluster/scripts/misc/`.
Differential Revision: https://phabricator.services.mozilla.com/D83532
Currently the macosx-cross toolchain build pulls in a linux64-clang toolchain, uses it to build a Mac native toolchain, and then clobbers the result with pieces of the Linux toolchain. This means that the same version of LLVM is used to build the Mac pieces and be part of the final artifact. This will become a problem with upcoming LLVM 11 where we'll want to build the Mac pieces with LLVM 9 but otherwise repackage an LLVM 11 Linux toolchain.
So this commit makes the macosx-cross workflow look more like the win-cross one: take two compilers built elsewhere and just merge them.
Differential Revision: https://phabricator.services.mozilla.com/D83378
CLOSED TREE
Backed out changeset 93b955e5c048 (bug 1637544)
Backed out changeset be0717d76643 (bug 1637544)
Backed out changeset 447fea64b68d (bug 1637544)
The current version hits OOM errors when dsymutil-ing files created by clang 10 and 11.
The choice of clang-10 here is somewhat arbitrary in that it's a fetch job that we conveniently already had in the tree. It doesn't have to be exactly version 10 specifically.
Differential Revision: https://phabricator.services.mozilla.com/D82453
We already do this for e.g. `linux64-clang-9`; this patch extends that pattern everywhere.
This will make it easy to do try runs with other clangs: just move the `toolchain-alias` lines from the `9` tasks to the `trunk` tasks.
Also, this makes dependencies more explicit: for example the gn task specifically requests a clang-9 compiler, so it will also need a clang-9-based cctools-port, rather than whatever moving value the alias represents.
Differential Revision: https://phabricator.services.mozilla.com/D82441
Some cleanup before I add more copies of this task.
Since this is based on a repo called `cctools-port` it seems like it would be better to keep that substring intact.
Differential Revision: https://phabricator.services.mozilla.com/D82439
This brings the `android-build` image very close to other build
images, paving the way for it to be folded in completely. It also
makes us more resilient in the face of upstream service interruptions.
Differential Revision: https://phabricator.services.mozilla.com/D78945
Toolchains that are used for local development need to be built on a level-3
branch to installable via `mach bootstrap`. Add an attribute to track the fact
that a toolchain is used that way, and:
- ensure that everything installed via `mach boostrap` has that attribute set
- ensure that everything with that attribute set is built on trunk projects
We could additionally verify that attribute is only set on things used by
bootstrap, but bootstrap doesn't currently have an exhaustive list of things
that it might install, making that difficult.
Differential Revision: https://phabricator.services.mozilla.com/D77706
This is the logic of tracing the WebGPU API calls at the level of wgpu-core,
serialized into a folder of choosing on the user drive. Traces are extremely portable,
they can be shared (on BugZilla) and then replayed on the developer machine,
which can have a different architecture from the users machine.
The standalone player is introduced in `gfx/wgpu/player`, similar to WebRender's Wrench.
The output dir is controlled by "dom.webgpu.traceDir" pref. No tracing happens if it's empty.
Differential Revision: https://phabricator.services.mozilla.com/D73333
This is the logic of tracing the WebGPU API calls at the level of wgpu-core,
serialized into a folder of choosing on the user drive. Traces are extremely portable,
they can be shared (on BugZilla) and then replayed on the developer machine,
which can have a different architecture from the users machine.
The standalone player is introduced in `gfx/wgpu/player`, similar to WebRender's Wrench.
The output dir is controlled by "dom.webgpu.traceDir" pref. No tracing happens if it's empty.
Differential Revision: https://phabricator.services.mozilla.com/D73333
We originally switched it to use just `public/` becuase iscript broke with the
extra path, but that broke out-of-tree consumers. Now that iscript is fixed,
switch it back.
Differential Revision: https://phabricator.services.mozilla.com/D76409
If a task has explicitly specified artifact paths, don't additionally specify
the default paths. If the task has private artifacts, having a directory
that uploads public artifacts seems like an attractive nuissance.
Differential Revision: https://phabricator.services.mozilla.com/D74200
They are not doing anything as try will choose jobs anyway.
And this is misleading for developers on what it is doing.
Differential Revision: https://phabricator.services.mozilla.com/D75490
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
