This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153
The interesting wrinkle here are the `MSIX(*-multi)` repackaging
tasks, which depend on (signed) langpacks. Said langpacks are
cross-platform and are produced on linux64 at this time.
Differential Revision: https://phabricator.services.mozilla.com/D119670
The interesting wrinkle here are the `MSIX(*-multi)` repackaging
tasks, which depend on (signed) langpacks. Said langpacks are
cross-platform and are produced on linux64 at this time.
Differential Revision: https://phabricator.services.mozilla.com/D119670
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
This patch allows the desktop recorder to be run manually. A subsequent patch
will enable it for every m-c push once the hardware is deployed.
Differential Revision: https://phabricator.services.mozilla.com/D117367
CLOSED TREE
Backed out changeset d8f2f3cc4da7 (bug 1709640)
Backed out changeset 3a6a274dae0d (bug 1709640)
Backed out changeset decc4edd47f9 (bug 1709640)
Not sure how it happened (probably copy-paste?) but a lot of Android jobs are
marked for "Android 4.0" (API 14) or "Android 4.2" (API 18) while really they
are all for Android 4.1 (API 16). This patch fixes that.
Differential Revision: https://phabricator.services.mozilla.com/D117050
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
We don't offer API splits any more, and with the separation of GeckoView with
the rest of the front-end it's increasingly unlikely that we will in the
future.
This change makes it so that the build name doesn't contain the API version so
that we can update it without breaking all the automation that relies on the
build name.
Differential Revision: https://phabricator.services.mozilla.com/D114369
I have manually pinned the requirements, and partials are working. We'll lose a way to auto-update our dependencies, but a) it's perma-busted, so realistically we're just losing a busted task, and b) mhentges is working on a way to auto-update pinned dependencies in-tree.
Differential Revision: https://phabricator.services.mozilla.com/D110148
To identify regressions and existing exceptions in Sentry, we tag them
with their mach release (the current base revision).
To ensure that Sentry knows the correct order of revisions, we need to
tell it about each one that lands in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D109681
This implements a --diff flag on the suite of |mach taskgraph| commands. E.g:
./mach taskgraph target -p project=autoland -J --diff
The above will update to the base revision of your stack (e.g the public
revision), generate the taskgraph, update to the current revision, generate the
taskgraph again, then display a diff of the two.
You can also specify a specifier to arg, e.g:
./mach taskgraph target -J --diff .~1
This will diff against the parent revision in mercurial (use 'HEAD~1' for git).
Differential Revision: https://phabricator.services.mozilla.com/D107274
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
The links and instructions in the page have been updated to reflect the
changes in the symbol server and the old copy was removed. Images have been
recompressed to reduce size.
Differential Revision: https://phabricator.services.mozilla.com/D92878