Dockerfile.bins pins a Rust image below the workspace MSRV, so it cannot build. Nothing in CI builds it, so no gate reports this.
What is wrong
Dockerfile.bins:6:
FROM rust:1.85-bookworm AS builder
Cargo.toml:21 declares rust-version = "1.91", and all six crates inherit it via rust-version.workspace = true. An unmet rust-version is a hard cargo error, not a warning, so the build fails before compiling anything.
Reproduction
docker build -f Dockerfile.bins --build-arg TARGET=aarch64-unknown-linux-musl . (docker 29.1.3):
error: rustc 1.85.1 is not supported by the following packages:
gl@0.7.0 requires rustc 1.91
gitlawb-core@0.7.0 requires rustc 1.91
git-remote-gitlawb@0.7.0 requires rustc 1.91
icaptcha-client@0.4.0 requires rustc 1.91
alloy-*@1.7.3 requires rustc 1.91
...
The command '/bin/sh -c cargo build --release --locked --target "$TARGET" -p gl -p git-remote-gitlawb' returned a non-zero code: 101
Same failure with --locked removed, so the flag added in #243 is not the cause; the image has been unbuildable since the MSRV moved to 1.91.
Impact
scripts/build-bins.sh uses this file for the two Linux musl targets (build-bins.sh:29), so the linux-x86_64 and linux-arm64 paths of that script are broken. The darwin-arm64 path builds natively and is unaffected. Released binaries are not affected either: release.yml builds those itself on matching-arch runners.
No workflow references Dockerfile.bins, which is why this has stayed quiet. Grepping .github/ for it returns only the CODEOWNERS entry.
Fix
Bump the base image to a tag at or above the MSRV (rust:1.91-bookworm, matching what the main Dockerfile already uses). Worth deciding at the same time whether this file should be kept: if scripts/build-bins.sh is still a supported path, a CI job that builds it would stop the next MSRV bump from breaking it silently, and if it is not, deleting both is the smaller change.
Noticed while adding --locked to the shipping builds in #243. Filing separately rather than widening that PR.
The fix above is verified, not just proposed
Rebuilt this file unchanged except for FROM rust:1.91-bookworm, same TARGET=aarch64-unknown-linux-musl: it clears the MSRV error and completes, producing a 158 MB image. So the base-image bump is sufficient on its own; nothing else in the file needs to change to make it build.
Dockerfile.binspins a Rust image below the workspace MSRV, so it cannot build. Nothing in CI builds it, so no gate reports this.What is wrong
Dockerfile.bins:6:FROM rust:1.85-bookworm AS builderCargo.toml:21declaresrust-version = "1.91", and all six crates inherit it viarust-version.workspace = true. An unmetrust-versionis a hard cargo error, not a warning, so the build fails before compiling anything.Reproduction
docker build -f Dockerfile.bins --build-arg TARGET=aarch64-unknown-linux-musl .(docker 29.1.3):Same failure with
--lockedremoved, so the flag added in #243 is not the cause; the image has been unbuildable since the MSRV moved to 1.91.Impact
scripts/build-bins.shuses this file for the two Linux musl targets (build-bins.sh:29), so the linux-x86_64 and linux-arm64 paths of that script are broken. The darwin-arm64 path builds natively and is unaffected. Released binaries are not affected either:release.ymlbuilds those itself on matching-arch runners.No workflow references
Dockerfile.bins, which is why this has stayed quiet. Grepping.github/for it returns only theCODEOWNERSentry.Fix
Bump the base image to a tag at or above the MSRV (
rust:1.91-bookworm, matching what the mainDockerfilealready uses). Worth deciding at the same time whether this file should be kept: ifscripts/build-bins.shis still a supported path, a CI job that builds it would stop the next MSRV bump from breaking it silently, and if it is not, deleting both is the smaller change.Noticed while adding
--lockedto the shipping builds in #243. Filing separately rather than widening that PR.The fix above is verified, not just proposed
Rebuilt this file unchanged except for
FROM rust:1.91-bookworm, sameTARGET=aarch64-unknown-linux-musl: it clears the MSRV error and completes, producing a 158 MB image. So the base-image bump is sufficient on its own; nothing else in the file needs to change to make it build.