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
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 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
The change happened 2 years ago in bug 1571562, which means the script
hasn't hit a llvm-dsymutil crash since then (we would have noticed that
it doesn't produce reproducers if we had recurring llvm-dsymutil crashes).
So before removing the script, fix it, so that if we do need to dig it
up from history, we don't pull a broken version.
Differential Revision: https://phabricator.services.mozilla.com/D124884
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
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
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
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
Valgrind detects a condition depending on uninitialized value in update_texture_cache. I first ran into this in bug 1716579, and as patch had a large impact on allocation/deallocation workloads with the texture cache, I couldn't decide with confidence that the patch wasn't faulty. In bug 1728618 which causes this error again, however, the patch is much simpler, doesn't interact with unsafe code and does not affect texture cache workloads so it gives me much better confidence that this valgrind error is either a false positive or a miscompilation.
Differential Revision: https://phabricator.services.mozilla.com/D124444
We had logic in both `mach_bootstrap` and the Mach Bootstrapper to
create the state_dir.
This joins them and has the added benefit of creating the state dir
earlier in the Mach lifecycle (as will be needed for early instantiation
of the Mach virtualenv).
Differential Revision: https://phabricator.services.mozilla.com/D120400
We've overloaded "bootstrap" to mean three different things:
* The "standalone bootstrap script": `python/mozboot/bin/bootstrap.py`.
This is to freshly clone a new repo, then run `./mach bootstrap`.
* `./mach bootstrap`: Install necessary dependencies and set up the
system for development.
* "Mach bootstrap": do the in-process initialization work Mach needs
before it can run commands.
By using the term "initialize" instead, perhaps we can remove
ambiguity when discussing Mach.
I'm not attached to the name (or this change at all), but I'm interested
in reviewer thoughts :)
Differential Revision: https://phabricator.services.mozilla.com/D120410
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
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
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
We've been installing `piptools` so that we can use the `pip-compile`
binary. However, we can just as easily do
`python -m piptools compile ...` instead, which also allows us to
skip a redundant install.
Differential Revision: https://phabricator.services.mozilla.com/D123240
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
We vendor `glean_parser==3.6.0`, and that was incompatible with
`glean-sdk==36.0.0`'s requirement of `glean_parser==2.5.0`.
`glean-sdk==40.0.0` expects `glean_parser==3.6.0`, which is perfect.
Differential Revision: https://phabricator.services.mozilla.com/D122899
There are two big parts in the MSVC toolchain we use:
- the Windows 10 SDK
- Visual C++
For the former, both the 15.8.4 and 15.9.6 toolchains are using the same
version of the Win10 SDK.
For the latter, we're not using the compiler itself anymore, so the only
substantial difference is in the headers and libraries included with
Visual C++, as well as the redist libraries for the CRT. Both versions
are supposed to be compatible to the same set of OS versions, fitting
our system requirements.
This makes us use the same version of MSVC on all our Windows builds
(arm64 builds were already on 15.9.6).
Differential Revision: https://phabricator.services.mozilla.com/D123720
```
2021-08-26 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/ssl/tls13con.c:
Backed out changeset fae49696d374
[e55700ee052e] [NSS_3_70_BETA1] <NSS_3_70_BRANCH>
* tests/tlsfuzzer/config.json.in, tests/tlsfuzzer/tlsfuzzer.sh:
Backed out changeset 7c3a0a99f7fa
[e79531c04e6b] <NSS_3_70_BRANCH>
* automation/abi-check/previous-nss-release, lib/nss/nss.h,
lib/softoken/softkver.h, lib/util/nssutil.h:
Set version numbers to 3.70 Beta
[cc0d44da6a0e]
2021-08-26 John M. Schanck <jschanck@mozilla.com>
* tests/tlsfuzzer/config.json.in, tests/tlsfuzzer/tlsfuzzer.sh:
Bug 1662515 - Enable tlsfuzzer/test-tls13-zero-content-type.py
r=bbeurdouche,djackson
[7c3a0a99f7fa]
2021-08-26 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/ssl/tls13con.c:
Bug 1662515 - Fix incorrect alert after successful decryption
r=djackson
[fae49696d374]
2021-08-24 Robert Relyea <rrelyea@redhat.com>
* tests/cert/cert.sh, tests/common/init.sh, tests/sdr/sdr.sh:
Bug 1726022 Update test case to verify fix.
Updated test cases to verify pbe caching fix. NOTE: putting
passwords on databases are key to reproducing the original issue.
[ff19b674c468]
2021-08-24 John M. Schanck <jschanck@mozilla.com>
* gtests/ssl_gtest/tls_ech_unittest.cc:
Bug 1714579 - Explicitly disable downgrade check in
TlsConnectStreamTls13.EchOuterWith12Max r=nss-reviewers,bbeurdouche
Depends on D123535
[608fd450d499]
* gtests/ssl_gtest/ssl_version_unittest.cc:
Bug 1714579 - Explicitly disable downgrade check in
TlsConnectTest.DisableFalseStartOnFallback r=nss-
reviewers,bbeurdouche
Depends on D122988
[7bd94de62243]
2021-08-24 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/util/nssb64d.c:
Formatting for lib/util
[db95b15ce1ff]
2021-08-24 John M. Schanck <jschanck@mozilla.com>
* lib/util/nssb64d.c:
Bug 1681975 - Avoid using a lookup table in nssb64d r=bbeurdouche
[d454db6ad1fb]
2021-08-24 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* lib/freebl/sha512.c:
Bug 1724629 - Use HW accelerated SHA2 on AArch64 Big Endian.
r=jschanck
[7e31b8f7f741]
2021-08-24 John M. Schanck <jschanck@mozilla.com>
* lib/ssl/sslsock.c:
Bug 1714579 Change default value of enableHelloDowngradeCheck to
true r=mt
Firefox sets enableHelloDowngradeCheck to true by default, as of
[1576790](https://bugzilla.mozilla.org/show_bug.cgi?id=1576790). We
have a two year old open issue noting some issues with that
[1590870](https://bugzilla.mozilla.org/show_bug.cgi?id=1590870), but
I see no reason not to update the default in NSS.
[52137aa125f5]
2021-08-24 Benjamin Beurdouche <bbeurdouche@mozilla.com>
* gtests/pk11_gtest/pk11_hpke_unittest.cc:
Formatting for gtests/pk11_gtest/pk11_hpke_unittest.cc r=jschanck
The clang-format target was failing.
https://treeherder.mozilla.org/logviewer?job_id=348100377&repo=nss-
try
[36bc1c231bf6]
```
Differential Revision: https://phabricator.services.mozilla.com/D123784
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
By hybrid unified system we understand a system that encapsulates modules that are built in the unified mode
but also other modules, like `dom/Animation`, as an example, in the non unified environment.
This approach is desirable since we already have most of the modules transitioned to the non unified system but there are
still some that are not yet compatible, but in the long term this will be done by each module owner and can be also tested
locally using the build system.
If a module can't be built outside the unified method it's `moz.build` config file needs to have `REQUIRES_UNIFIED_BUILD = False`
To also enable this we need to have a flag from `mozconfig`, like:
```
ac_add_options --disable-unified-build
```
Differential Revision: https://phabricator.services.mozilla.com/D122328
librnp is used by Thunderbird for OpenPGP support. Until now, official builds
have been built statically linked to Clang/LLVM's libc++ to avoid problems with
libstdc++ symbols.
Recent build changes have narrowed the gap significantly, leaving out_of_range
and invalid_argument called with char const* rather than std::string.
Differential Revision: https://phabricator.services.mozilla.com/D123381
The purpose of this is to remove as many docstrings from CommandProvider
classes to make the step of moving commands out of classes simpler.
Where possible, the docstring has been moved to or merged with the function.
Differential Revision: https://phabricator.services.mozilla.com/D123288
Chrome has removed 3DES completely[0], but we're still seeing some uses of it
in telemetry. Our assumption is that this is either due to old devices that
can't be upgraded, and hence probably use TLS 1.0, or servers that bafflingly
choose 3DES when there are other, better, ciphersuites in common.
This patch allows 3DES to only be enabled when deprecated versions of TLS are
enabled. This should protect users against the latter case (where 3DES is
unnecessary) while allowing them to use it in the former case (where it may be
necessary).
NB: The only 3DES ciphersuite gecko makes possible to enable is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This patch also changes the preference
corresponding to this ciphersuite from "security.ssl3.rsa_des_ede3_sha" to
"security.ssl3.deprecated.rsa_des_ede3_sha".
[0] https://www.chromestatus.com/feature/6678134168485888
Differential Revision: https://phabricator.services.mozilla.com/D121797
It's an unnecessary difference with our other clang builds. It looks
like it was cargo-culted from some external script. It makes the
android-cross clang different in the way it finds e.g. compiler
runtimes, some of which are in lib/, and others in lib64/, and only the
latter are actually found.
Differential Revision: https://phabricator.services.mozilla.com/D123017
What currently happens when Cargo.lock doesn't match is that the first
time we run cargo to generate the cbindgen metadata, we don't run it
with --frozen (unlike subsequent calls), and that locally fixes
Cargo.lock. Instead of that, we make the build fail, which will prevent
out-of-sync Cargo.lock from slipping in the tree in the first place.
Differential Revision: https://phabricator.services.mozilla.com/D123010
This patch updates ssltunnel to have a configuration where it only uses a 3DES
ciphersuite, rather than RC4 ciphersuites. This has to be done in stages
because otherwise android tests will fail, because their hostutils doesn't
actually use what's in-tree, and has to be updated separately.
Differential Revision: https://phabricator.services.mozilla.com/D122393
Local builds don't use it, and currently the only builds that happen on
macs on automation are not using the clang toolchain, so they're not
going through the first condition, and the remainder of the mozconfig
is essentially no-ops (plus, the only builds on macs on automation that
do use mozconfigs at all are rusttests, for which those settings wouldn't
matter anyways).
Meaning in practice, the mozconfig is not doing anything useful.
Differential Revision: https://phabricator.services.mozilla.com/D122823
The sysroot setup on macOS is different from Linux, and pkg-config
files, if there are, would be coming from e.g. homebrew rather than
the macOS SDK.
Differential Revision: https://phabricator.services.mozilla.com/D122793
The Glean SDK was traditionally represented in-tree as `glean_sdk`.
However, on PyPI and in `pip list`, it appears as `glean-sdk` (`pip` was
doing the translation implicitly and internally).
This is breaking our virtualenv state-checking code, since it thinks
that `glean_sdk` isn't installed.
Since `glean_sdk` was marked as `pypi-optional`, this hasn't affected us
yet, but it will when we bump the Glean SDK version, because developers'
virtualenvs won't be detected as out-of-date.
Differential Revision: https://phabricator.services.mozilla.com/D122500
The wasi-sysroot toolchain contains both a sysroot for wasi and a
compiler-rt for clang. That makes it impractical to use as a
bootstrapped sysroot for wasm32-wasi builds of Spidermonkey.
We thus split the toolchain in two, one for the compiler-rt and one
for the sysroot. Ideally, the compiler-rt one would avoid building
clang/llvm the same way the sysroot one does, but that leads to
a case of chicken-and-egg, because the compiler-rt is needed to build
the clang toolchain. Eventually, the clang build would be split from
the addition of the compiler-rt, but we're not there yet.
Differential Revision: https://phabricator.services.mozilla.com/D122402
While some custom builds of GCC work successfully, system GCC builds
usually don't, because of several factors:
- they don't use the C++ headers or libstdc++.so from the sysroot
- they don't necessarily know to use the multiarch directories in the
sysroot
Differential Revision: https://phabricator.services.mozilla.com/D121946
We're currently using -isysroot as a preprocessor flag and
-Wl,--syslibroot/-Wl,--sysroot as a linker flag, but --sysroot is
generalization of both, so we can use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D121943
They are equivalent, except for the fact that MACOSX_DEPLOYMENT_TARGET
may apply to more processes in a normal build. In practice, all the
processes that matter are covered through compiler flags.
On the opposite end, MACOSX_DEPLOYMENT_TARGET isn't necessary passed in
all cases (like clangd, mach static-analysis, etc.), while compiler
flags are.
Differential Revision: https://phabricator.services.mozilla.com/D122145
As this means stdc++compat also would need to be built when
cross-building for Windows on Linux, we also recurse in the stdc++compat
directory in that case. It was already possible to use
--enable-stdcxx-compat in that configuration, and that wasn't working
(there are other problems that prevent it from working, but we're going
to fix them shortly).
Differential Revision: https://phabricator.services.mozilla.com/D122195
Since the minimum required version of gcc and libstdc++ is 7.1 as of bug
1536848, the _GLIBCXX_RELEASE macro is available on all supported
versions. Which means instead of grabbing the largest version of the
libstdc++ symbols and tweaking for that, we can just tweak for
_GLIBCXX_RELEASE. We also remove the conditions that are always true due
to the versions involved.
Differential Revision: https://phabricator.services.mozilla.com/D122194
Chrome has removed 3DES completely[0], but we're still seeing some uses of it
in telemetry. Our assumption is that this is either due to old devices that
can't be upgraded, and hence probably use TLS 1.0, or servers that bafflingly
choose 3DES when there are other, better, ciphersuites in common.
This patch allows 3DES to only be enabled when deprecated versions of TLS are
enabled. This should protect users against the latter case (where 3DES is
unnecessary) while allowing them to use it in the former case (where it may be
necessary).
NB: The only 3DES ciphersuite gecko makes possible to enable is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This patch also changes the preference
corresponding to this ciphersuite from "security.ssl3.rsa_des_ede3_sha" to
"security.ssl3.deprecated.rsa_des_ede3_sha".
[0] https://www.chromestatus.com/feature/6678134168485888
Differential Revision: https://phabricator.services.mozilla.com/D121797
We're currently using -isysroot as a preprocessor flag and
-Wl,--syslibroot/-Wl,--sysroot as a linker flag, but --sysroot is
generalization of both, so we can use that instead.
Differential Revision: https://phabricator.services.mozilla.com/D121943
A lot of work happens on the wayland backend, and it regularly breaks tier-3
systems where wayland is not supported. Setting up X11-only builds will help
catch those breakages earlier.
Differential Revision: https://phabricator.services.mozilla.com/D121691
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
There are two different codepaths in old-configure for AS, and one of
them uses ac_cv_prog_AS and the other ac_cv_path_AS. We thus need to set
both.
Differential Revision: https://phabricator.services.mozilla.com/D121828
We do so as a side effect of using system_lib_option for all *-system-*
options for old-configure, all but one of which are for system
libraries.
Differential Revision: https://phabricator.services.mozilla.com/D121690
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
Originally, we only were using bindgen for stylo, and we also went a bit
overkill by including a lot of extra CFLAGS in there, which end up
being unnecessary. So we now only pass a more minimal set of flags, and
add some extra CFLAGS in cases where they are necessary.
Differential Revision: https://phabricator.services.mozilla.com/D121043
While the use of toml allows the flags to be separated, the split is
done via some shell shenanigans anyways, and servo's build.rs can
handle the same just fine.
Differential Revision: https://phabricator.services.mozilla.com/D121042
We do that with everything else (i.e. clang, cbindgen, etc.). We weren't
doing it for sysroots because the support was experimental and the path
was independent of the target, so there was no guarantee that the
sysroot would actually work for the target. As that's not the case
anymore, we can go with more consistency with the bootstrapped
toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D120417
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
After removing `optional` in Bug 1712804, we need to add a variant back
here because there's fallible dependencies. However, I've tweaked the
re-introduction of the feature to require a specific repercussion
message as well. This seemed like a decent tradeoff - the developer
becomes aware that the failure is bad, it has repercussions, but it's
not a blocking issue. Additionally, since we're printing pip's output,
the developer will be able to see the underlying error causing the
warning.
I also added comment functionality to requirements definitions to allow
adjacent documentation of why some requirements are fallible. (Related:
I'm looking forward to `mach_bootstrap` not needing to parse
requirements definitions. Almost there!)
Note that we'll temporarily lose the "pinned" nature of the
three moved dependencies until dependency locking is implemented
for Mach requirements definitions. Also note that the pinned
`zstandard_requirements.txt` can't be removed like the other
files because it still has a dangling usage.
Finally, in preparation for review: I didn't make
`PypiOptionalSpecifier` extend `PypiSpecifier` because I figured that
the benefit of flexibility (easier to allow implementations to diverge
without needing to untangle an inheritance relationship) was larger than
the cost of needing to add properties to both specifiers.
If we wanted re-use, I'd probably have `PypiOptionalSpecifier` _contain_
a `PypiSpecifier`, but then you have to reach deeper into the object to
get data, so *shrug*.
Differential Revision: https://phabricator.services.mozilla.com/D119835
The three removed paths don't exist in-repo, and after a cursory glance
they don't appear to be populated dynamically.
Note that the removal of the `six` path for WPT is different: it's
technically just incorrect, and should amended to point to
`$WPT/tools/third_party/six`. However, Python only allows a single
instance of a library to exist in import scope, and we're already
consuming `six` from the Firefox-wide vendored 3rd-party libs.
Differential Revision: https://phabricator.services.mozilla.com/D119825
The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
We will only run the processes in CET compatible modules only mode when not
using the JIT code. So marking xul.dll as compatible should be OK.
Differential Revision: https://phabricator.services.mozilla.com/D117551
Clang >= 11 ignores PYTHON_EXECUTABLE entirely (and uses python3, which
is not even what we pass, but that's actually fine), and all the build
tasks we have on older versions find the python executable they need on
their own.
Differential Revision: https://phabricator.services.mozilla.com/D120049
I'm guessing that the code moved to the bootstrap command but the
associated comment was forgotten and left abandoned, which is very sad.
Differential Revision: https://phabricator.services.mozilla.com/D120098
There's a "minimum Python check" that happens when Mach
bootstraps that makes the bootstrap command's check obsolete.
Since we want to use modern Python features throughout Mach, we need to
move Python-out-of-date logic up to the front of the process.
We're duplicating the OS-detection logic a bit, but now we regain
per-platform Python instructions.
Differential Revision: https://phabricator.services.mozilla.com/D120093
Bug 1692137 added code that would end up calling
toolchain_task_definitions twice, once for each of host and target.
With the recent changes from bug 1719229, that is not useful anymore.
We also don't need the toolchain prefixes for toolchains on unsupported
hosts (which were useful before bug 1719229 for the target sysroots).
Differential Revision: https://phabricator.services.mozilla.com/D120044
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
It turns out calling gdk_display_close gets us a rematch of bug 1626536,
so remove the call that was added in bug 1718131, and adjust valgrind
suppressions accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D120037
After changeset 5e4b33fe9218703f0b29e2446159bcf4202d15fa the Attributes.cpp file was
changed so our patched version was not sticking on top of it. This patch does the proper
rebase.
Differential Revision: https://phabricator.services.mozilla.com/D119951
In cross-compilation setups (x86_64 host, i686 or aarch64 target), we're
going to need two sysroots. Obviously, we need the sysroot paths to be
different in that case, so the sysroot path themselves need to contain
some distinctive name, and we'll use the `target.toolchain` name for
that (the target triplet with the vendor/machine stripped out).
Because the path name needs to be reflected in the artifact name as well
as the toolchain name, we also change them.
And because the current prefix in the toolchain name is now redundant
with the suffix, we remove the prefix, and allow the bootstrapping
mechanism to try toolchains without the prefix.
Differential Revision: https://phabricator.services.mozilla.com/D119846
Emilio Cobos Álvarez
Tetsuharu Ohzeki
Kris Wright
Marian-Vasile Laza
Mitchell Hentges
Andreea Pavel
Mike Hommey
Iulian Moraru
Cosmin Sabou
Noemi Erli
Nicolas Silva
Chris H-C
Sandor Molnar
Andrew Osmond
Dzmitry Malyshau
Andrew Sutherland
Florian Quèze
Benjamin Beurdouche
championshuttler
Andi-Bogdan Postelnicu
Narcis Beleuzu
Rob Lemley
Alex Lopez
Dana Keeler
Brindusan Cristian
Csoregi Natalia
Mike Kaply
Butkovits Atila
Gerald Squelart
Brad Werth
Bob Owen
Andi-Bogdan Postelnicu
lyavor