As discussed on zulip we would like to rename `libservo` to `servo`
(again) before a future crates.io release.
Servo is a library, so the `lib` prefix is somewhat redundant. We
already renamed the binary of ServoShell to `servoshell`, to reduce
confusion of users of what servo is.
Note: This PR does not touch all occurrences of `libservo`. Specifically
CI job names remain untouched, since the risk of breaking something is
higher here, harder to test for and the name not user facing.
Testing: CI testing of this change should give us good confidence.
Manual testing of `./mach doc` and `./mach build` showed no issues on
macos. [Full try
run](https://github.com/jschwe/servo/actions/runs/22909562747)
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
on NixOS, under X11 at least, many libservo tests panic:
```
$ ./mach test-unit -p libservo test_create_webview
[...]
thread 'test_create_webview' (3589026) panicked at /home/delan/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wayland-sys-0.31.8/src/client.rs:110:103:
Library libwayland-client.so could not be loaded.
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
this patch fixes that by adding `wayland` to the LD_LIBRARY_PATH in
shell.nix.
Testing: tested manually as above
Signed-off-by: delan azabani <dazabani@igalia.com>
The versions of `cargo-deny` older than 0.18.6 have a bug which causes
the executions of `cargo-deny check` to prematurely fail when reading
the advisory db
(https://github.com/EmbarkStudios/cargo-deny/issues/804).
This error is ignored by `test-tidy` since the error message doesn't
have the expected JSON fields, causing `test-tidy` to succeed even when
there are valid issues in `deny.toml` or `Cargo.lock`.
So upgrade the `cargo-deny` version installed by `mach` to be the latest
version and ensure that at least the version with the fix is installed
on the system. Also fix the `test-tidy` code to always fail when the
exit code from `cargo-deny` is non-zero.
This patch also updates `deny.toml` to include exceptions to allow
`./mach test-tidy` to pass. Some of these need to be investigated
separately from this change.
Fixes#41845.
Fixes#38945.
Testing: Tested locally on NixOS.
---------
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
On NixOS, dynamically linked binaries from the Python venv (installed
via uv/pip) cannot run directly because they expect standard Linux
library paths that don't exist on NixOS.
This commit adds FHS wrappers that allow these binaries to run in an
FHS-compatible environment at runtime, without patching them.
I considered using the nixpkgs versions of ruff and pyrefly directly, or
overriding their derivations to match the versions in requirements.txt.
However, decided against it because:
- Version mismatches between nixpkgs and requirements.txt caused type
checking incompatibilities (pyrefly 0.34.0 vs 0.23.1)
- Building these tools from source in nix is slow and adds significant
time to nix-shell initialization (both are rust packages that take quite
some time to build)
Testing: just improvements to the NixOS development environment, no test
needed
**Before:**
```
➜ servo (main) ✔ nix-shell
➜ servo (main) ✔ ./mach fmt
Could not start dynamically linked executable: /home/dyego/coding/random/servo/.venv/bin/ruff
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld
➜ servo (main) ✔ ./mach test-tidy
➤ Checking config file (./servo-tidy.toml)...
➤ Checking directories for correct file extensions...
Could not start dynamically linked executable: ruff
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld
Error running mach:
['test-tidy']
The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.
You can invoke |./mach busted| to check if this issue is already on file. If it
isn't, please use |./mach busted file| to report it. If |./mach busted| is
misbehaving, you can also inspect the dependencies of bug 1543241.
If filing a bug, please include the full output of mach, including this error
message.
The details of the failure are as follows:
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
File "/home/dyego/coding/random/servo/python/servo/testing_commands.py", line 322, in test_tidy
tidy_failed = tidy.scan(not all_files, not no_progress, github_annotations)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/dyego/coding/random/servo/python/tidy/tidy.py", line 919, in scan
for error in errors:
File "/home/dyego/coding/random/servo/python/tidy/tidy.py", line 401, in check_ruff_lints
for error in json.loads(e.output):
^^^^^^^^^^^^^^^^^^^^
File "/nix/store/2g9b898aq9kmizmhmhbdip5mixrc5wrk-python3-3.11.14/lib/python3.11/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/2g9b898aq9kmizmhmhbdip5mixrc5wrk-python3-3.11.14/lib/python3.11/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/nix/store/2g9b898aq9kmizmhmhbdip5mixrc5wrk-python3-3.11.14/lib/python3.11/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
➜ servo (main) ✔
```
(note that the `JSONDecodeError` is because we're trying to parse the
"NixOS cannot run dynamically linked executables intended..." string as
JSON)
**Now:**
```
➜ servo (fix-nix-mach) ✔ nix-shell
➜ servo (fix-nix-mach) ✔ ./mach fmt
➜ servo (fix-nix-mach) ✔ ./mach test-tidy
➤ Checking config file (./servo-tidy.toml)...
➤ Checking directories for correct file extensions...
➤ Checking type annotations in python files ...
➤ Skipping WPT lint checks, because no relevant files changed.
➤ Running `cargo-deny` checks...
➤ Checking formatting of Rust files...
➤ Checking formatting of python files...
➤ Checking formatting of toml files...
✅ test-tidy reported no errors.
➜ servo (fix-nix-mach) ✔
```
Signed-off-by: Dyego Aurélio <dyegoaurelio@gmail.com>
Nextest is a powerful test runner, with many advantages over cargo test.
Among others it will run each test in a separate process, provide a
summary of the completed test execution, supports output formats like
JUnit, and can handle flaky test by retrying. This PR does not use most
of these advanced features yet though, that will be left to future PRs.
The change also uncovered racy tests in `net` which rely on someone
initializing the `ASYNC_RUNTIME` before the test in questions is run. By
explicitly accessing the lazy static in a common setup routine, we make
sure it is initialized.
CLI differences of `cargo test` vs `cargo nextest`:
- The `--profile` option in nextest is not the cargo profile, but refers
to nextest configuration profiles.
- `--nocapture` is a direct argument to nextest, not to the testharness,
so we can remove the preceding `--` seperator.
Testing: Tested by running unit-tests in CI
Fixes: #39797
---------
Signed-off-by: Jonathan Schwender <schwenderjonathan@gmail.com>
Servo now requires r28 of the NDK. This needs to land after #39625 as
the newer NDK is not available in the current pinned version of nixpkgs.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
this patch bumps nixpkgs to [the
tip](5b5be50345)
of [nixos-25.05](https://github.com/NixOS/nixpkgs/commits/nixos-25.05).
this is still not new enough for X11-based machines on NixOS 25.11
(#39623), so i’ve added a note explaining what to do in that situation.
LLVM 14 will be removed in NixOS 25.11, so this patch also bumps LLVM to
the latest available stable (14 → 20). #30587 and #31054 are no longer
relevant, and #31059 is hopefully no longer relevant.
we also remove wireshark from the buildInputs, since it installs a
broken tshark(1) that lacks the necessary capabilities to capture
packets from loopback interfaces. to use etc/devtools_parser.py, install
wireshark with your system package manager, or for NixOS, enable the
option: `programs.wireshark.enable = true;`
Testing: no tests needed, since it only affects the NixOS dev
environment
Fixes: #39624Fixes: #31059
Related: #39623
---------
Signed-off-by: Delan Azabani <dazabani@igalia.com>
I get the following warning message I run ./mach build:
```console
Could not generate notification: No module named 'dbus'
```
I asked in the Zulip chat[1] if anyone was still using the feature and
it sounds like most people do not use it anymore. It has been broken a
while too and no one has stepped up to fix it.
Gnome Terminal will automatically show a notification when a long
running command is done. Some other terminals can also be configured to
automatically show a notification when a long running command is done.
I think it is safe to remove the feature.
[1]
https://servo.zulipchat.com/#narrow/channel/263398-general/topic/DBus.20warning.20when.20running.20.60.2E.2Fmach.20build.60
Testing: I manually tested it on Linux by running ./mach bootstrap
followed by ./mach build
Signed-off-by: Michael Mc Donnell <michael@mcdonnell.dk>
This fixes an issue with cargo-deny 0.16.3 that causes all crates to be
reported as "yanked" even though they are not. This patch upgrades
cargo-deny to 0.18.2 which works correctly.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
PR #35628 bumped the rustc version to 1.85, but this broke nix-based
systems as these also require bumping the channel for the 'rust-overlay'
module to a commit that includes support for that version of rustc.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
The new images published in servo/ci-runners#12 should have `uv`
installed already and the initial build of servo triggered during the
base image construction will force the installation of the Python
version mentioned at the time of the image construction (3.12). When
.python-version changes, we can no longer use the .venv baked into the
image and must recreate the it to avoid activating the environment.
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
This allows us to use `uv` for:
1. Installing a pinned Python version
2. Installing the dependency packages using `uv`'s pip compatible interface.
4. Bootstrapping `mach` without a Python installion on the host, using `uv
run`
This change also introduces a new 'composite' GitHub action to setup
python in the different CI workflows. There is no support for externally
managed python installations and virtual environments. These could be
added in the future.
Fixes#34095, #34547
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
This patch switches servo to use `uv` for both installing a pinned
Python version as well as installing the dependency packages using
`uv`'s pip compatible interface. It also introduces a new 'composite'
GitHub action to setup python in the different CI workflows.
There is no support for externally managed python installations and
virtual environments. These could be added in the future.
Fixes#34095
Signed-off-by: Mukilan Thiyagarajan <mukilan@igalia.com>
