Brings a few important fixes:
- better WGSL support
- Solaris build (1729751)
- crash in "_MTLCommandEncoder dealloc" (1729648)
Differential Revision: https://phabricator.services.mozilla.com/D125103
Rather than deleting the expected target directory of each package
that's being vendored, clear the whole `third_party/python` directory
and re-populate it from scratch.
As part of this, there's an "exclusion" list for packages that can't
be vendored from PyPI.
This has some benefits:
* It'll be harder to forget scraps of files and directories and leave
them in `third_party/python`.
* The exclusion list makes it more clear which packages are managed
manually, and the friction it adds to the workflow will guide
developers to use "requirements.in" instead.
The `test_up_to_date_vendor` test will verify that the vendor directory
is always clean.
Differential Revision: https://phabricator.services.mozilla.com/D123124
Note that, as part of adding this packages to the automated vendoring
system, some dependencies were automatically added - most notably,
dependencies of `taskcluster` that become visible with Python 3.6+.
Also, adds `**/.git` to the exclusions because:
* `.git` is part of our `.hgignore`, but
* `.git` is part of the `aiohttp` `tar.gz` file.
Since the file isn't needed for `pip install`-ing `aiohttp`,
and since we want `./mach vendor python` to be a no-op when there's
no requirement changes, we exclude it.
Differential Revision: https://phabricator.services.mozilla.com/D123122
Note that this patch makes modifications to the vendored
`virtualenv` package by removing the modern `setuptools`
packages, replacing them with `51.2.0`. This is because
`51.3.0` somehow causes xpcshell failures with the following
Python bug: https://bugs.python.org/issue37380
This upgrades:
* `pip` 20.3.1 => 21.2.3
* `setuptools` 51.0.0 => 51.2.0
* `wheel` 0.36.1 => 0.37.0
Differential Revision: https://phabricator.services.mozilla.com/D123120
Add pystache to vendor `requirements.in` so that it's vendored according
to `./mach vendor python` "ignore" rules.
This ensures that sufficient files are vendored such that installing the
package from it's `setup.py` file is possible.
Differential Revision: https://phabricator.services.mozilla.com/D122898
The existing version of `pyasn1-modules` (`0.1.5`) is incompatible with
our version of `pyasn1` (`0.4.8`).
By bumping `pyasn1-modules` to `0.2.8`, we now meet its compatibility
requirements.
Differential Revision: https://phabricator.services.mozilla.com/D122897
It was downgraded to investigate some windows crashes which ended up
being a crossbeam issue. So update it again to get fixes to some
crossbeam races.
Differential Revision: https://phabricator.services.mozilla.com/D125051
Rather than deleting the expected target directory of each package
that's being vendored, clear the whole `third_party/python` directory
and re-populate it from scratch.
As part of this, there's an "exclusion" list for packages that can't
be vendored from PyPI.
This has some benefits:
* It'll be harder to forget scraps of files and directories and leave
them in `third_party/python`.
* The exclusion list makes it more clear which packages are managed
manually, and the friction it adds to the workflow will guide
developers to use "requirements.in" instead.
The `test_up_to_date_vendor` test will verify that the vendor directory
is always clean.
Differential Revision: https://phabricator.services.mozilla.com/D123124
Note that, as part of adding this packages to the automated vendoring
system, some dependencies were automatically added - most notably,
dependencies of `taskcluster` that become visible with Python 3.6+.
Also, adds `**/.git` to the exclusions because:
* `.git` is part of our `.hgignore`, but
* `.git` is part of the `aiohttp` `tar.gz` file.
Since the file isn't needed for `pip install`-ing `aiohttp`,
and since we want `./mach vendor python` to be a no-op when there's
no requirement changes, we exclude it.
Differential Revision: https://phabricator.services.mozilla.com/D123122
Add pystache to vendor `requirements.in` so that it's vendored according
to `./mach vendor python` "ignore" rules.
This ensures that sufficient files are vendored such that installing the
package from it's `setup.py` file is possible.
Differential Revision: https://phabricator.services.mozilla.com/D122898
The existing version of `pyasn1-modules` (`0.1.5`) is incompatible with
our version of `pyasn1` (`0.4.8`).
By bumping `pyasn1-modules` to `0.2.8`, we now meet its compatibility
requirements.
Differential Revision: https://phabricator.services.mozilla.com/D122897
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
This patch bumps the minidump_writer_linux crate but does not import any new
changes, the only difference is that it now depends on nix 0.15
Differential Revision: https://phabricator.services.mozilla.com/D124175
We already requested the FD from the portal but then just opened a
normal connection. The screen cast portal explicitly states that
the FD returned by `OpenPipeWireRemote()` should be used with
`pw_remote_connect_fd()` - the later is Pipewire 0.2 API that got
replaced by `pw_context_connect_fd()`.
Depends on D122903
Differential Revision: https://phabricator.services.mozilla.com/D122904
It is needed for restricted pipewire access. The FD is provided
by xdg-desktop-portals such as the one for screen casting.
Not using the portal provided FD means we need full Pipewire
access, even in a Flatpak sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D122903
Update mp4parse_capi API to receive pixi data from parser
There are some necessary changes in nsAVIFDecoder.cpp to accommodate the mp4parse_capi changes. Aside from the addition of `BitsPerChannelToBitDepth`, to facilitate a bit of logging, there should be no functional changes. This is a prerequisite to [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1696045 | bug 1696045 ]], which will add telemetry around the `pixi` box.
Differential Revision: https://phabricator.services.mozilla.com/D123273
