)
The 0.22.0 release run died on `cp310-musllinux_riscv64` with `Command
['which', 'uv'] failed with code 1`, from my riscv64 matrix entry. All
six manylinux riscv64 wheels in that same job built, repaired and tested
fine, so it is specific to the musllinux image.
pypa/manylinux used to skip installing uv in the musllinux riscv64
image. At the commit the pinned image was built from (`8dbfa8e`, 4
June), `docker/build_scripts/finalize.sh` had:
```
musllinux*_riscv64-uv) continue;;  # uv doesn't provide musl riscv64 wheels due to Rust issues
```
That was removed by pypa/manylinux#1969 on 11 July, and their image test
suite now runs `uv venv` / `uv pip install` inside musllinux riscv64.
The comment was already out of date when it was written: uv has
published a `manylinux_2_31_riscv64.musllinux_1_1_riscv64` wheel since
0.11.18 (1 June).
The pins differ across cibuildwheel releases:
| cibuildwheel | `musllinux_1_2_riscv64` image | uv present |
|---|---|---|
| 4.1.0 | `2026.06.04-1` | no |
| 4.2.0 | `2026.08.04-1` | yes |
So `build-frontend = "build[uv]"` has nothing to find on 4.1.0. This
bumps both `uvx --from` pins to 4.2.0.
4.2.0 builds CPython 3.15 by default, but `.cibuildwheel.toml` sets an
explicit `build = "cp310-* cp311-* cp312-* cp313-* cp314-* cp314t-*"`
list, so no new target appears. The rest of that release is Pyodide
314.0.4, a GraalPy pip hold, and download retries.
I have not run this. The reasoning is from the failing job log and the
manylinux source, not from a green build. CI here will not test it
either unless someone adds the `build-riscv64` label, since the riscv64
job is excluded on unlabelled PRs, and even then `CIBW_SKIP` drops
musllinux outside a release build. So the honest state is that only a
release run proves it. If you would rather not move cibuildwheel right
before a release, `musllinux-riscv64-image` in `.cibuildwheel.toml` pins
just that one image and leaves everything else alone.
Two things worth knowing either way:
The riscv64 job is gated behind the `build-riscv64` label on PRs, and
`CIBW_SKIP` drops musllinux unless `build-all` is set. So nothing had
ever exercised musllinux riscv64 until the release turned `build-all`
on. Whatever you decide here, that combination will keep hiding riscv64
musllinux breakage until release day.
Dependabot covers `github-actions` and `uv`, but the cibuildwheel
version is an inline `uvx --from` argument rather than a tracked
dependency, which is why it sat at 4.1.0. Moving it into the uv
ecosystem somehow would stop the next one, though I do not have a clean
suggestion for how.
Refs msgspec#1134, msgspec#987
Signed-off-by: Bruno Verachten <gounthar@gmail.com>
Co-authored-by: sobolevn <mail@sobolevn.me>