[rebuilder.lib.sh] Fix the cargo toolchain check, and cap librespot's build parallelism - #28
Open
Gjuju wants to merge 4 commits into
Open
[rebuilder.lib.sh] Fix the cargo toolchain check, and cap librespot's build parallelism#28Gjuju wants to merge 4 commits into
Gjuju wants to merge 4 commits into
Conversation
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
from
August 4, 2026 09:08
714b3d1 to
d402d46
Compare
…heck_cargo Two issues in rbl_check_cargo: - PATH was appended with the cargo bin dir, so on a build machine that also has the distro rust package installed, /usr/bin/rustc shadows the rustup one. The version check then never matches RUSTC_PIN_VERSION and the toolchain is uninstalled and reinstalled on every single build. Prepending the cargo bin dir makes the rustup toolchain win. - Nothing verified the result of the install. If rustup fails or ends up serving a different toolchain, the build silently continues with the wrong rustc, which is exactly what pinning 1.96.0 is meant to prevent (the 1.97 segfaults). Re-check the version after the install block and exit 1 on mismatch, as the pre-refactor code did. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…texts rbl_check_cargo looked for the toolchain under /home/pi when the build runs as a user. Since Bookworm the account is created at first boot, so on a device whose user is not pi the check never finds the install: every CLI build re-downloads the whole toolchain and cargo-deb, installs it into $HOME/.cargo, and finds nothing again on the next run. Verified on a Trixie device where /home/pi does not exist. Derive CARGO_HOME once for both contexts instead, and drive every step off it, so detection, cleanup, install and verification all agree on a single location: - user builds use $HOME/.cargo, root builds (the on-demand librespot install spawned by the moode worker) stay on /root/.cargo, spelled out because the worker does not necessarily export HOME - query $CARGO_HOME/bin/rustc by full path, so the version read is the toolchain we manage and not some other rustc on the machine, and prepend the cargo bin dir to PATH for the same reason - remove a leftover CARGO_HOME that has no rustup left in it to uninstall with, otherwise rustup-init will not install over it - re-check the version after installing and exit 1 on mismatch: the pin is there to avoid the 1.97 segfaults, so a build with the wrong toolchain should not silently proceed Behaviour verified for the states: nothing installed, pinned version already installed (no download), wrong version installed (uninstall then reinstall), leftover CARGO_HOME, and an install that yields the wrong version (exits 1). Checked as both user and root on the device. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
cargo defaults to one rustc per core. On a 1GB Pi 3B+ that stacks 4 rustc, saturates RAM and drives the board into SD I/O thrash: 81min, 1.8GB swap, load ~10, and two crash/reboots. One job per ~1GB of RAM instead: 73min, 782MB swap, load ~2, no crashes.
…SIGSEGV Set RUST_MIN_STACK in rbl_check_cargo, next to the rest of the rust environment, so every cargo build started from here gets it. Honours a value already in the environment.
Gjuju
force-pushed
the
feat/rebuilder-cargo-check
branch
from
August 5, 2026 08:49
d402d46 to
63329a0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two independent failures on the on-demand librespot build, one fix each.
Measured on Pi 3B, 3B+, 3A+, Zero 2 W, Pi 4 and Pi 5, all rustc 1.96.0.
rbl_check_cargonever finds an existing toolchainIt looked under
/home/pi. Since Bookworm the account is created at firstboot, so on a device whose user is not
pithe check finds nothing: every CLIbuild re-downloads the whole toolchain and cargo-deb, installs it into
$HOME/.cargo, and finds nothing again on the next run. Verified on a Trixiedevice where
/home/pidoes not exist.CARGO_HOMEis now derived once for both contexts —$HOME/.cargofor userbuilds,
/root/.cargofor the on-demand install spawned by the worker — andevery step works off it. Along the way:
PATH, so a distro/usr/bin/rustccannotshadow the pinned one and trigger a reinstall on every build
CARGO_HOMEthat has no rustup left in it to uninstallwith, which rustup-init refuses to install over
to avoid the 1.97 segfaults
Checked as both user and root for: nothing installed, pinned version already
installed, wrong version installed, leftover
CARGO_HOME, and an install thatyields the wrong version.
Low-RAM boards
Jobs. cargo defaults to one rustc per core. On a 1 GB Pi 3B that stacks
four rustc and drives the board into SD thrash. Budget 512 MB per parallel
rustc, clamped to
[1, nproc]; an explicitCARGO_BUILD_JOBSstill wins.One board, one variable:
Two is the knee — a third job saves 16 s and writes 29% more.
Stack. On aarch64 a codegen worker thread can overflow its stack and take
rustc down with SIGSEGV inside LLVM while compiling
librespot-protocol. It isnot the OOM killer and not governed by the job count, so it strikes at random.
RUST_MIN_STACK=16777216is the remedy rustc's own diagnostic suggests, and itcosts no measurable time: the same board run twice, once each way, gave 21m19
against 21m16 on a Pi 4 and 7m13 against 7m12 on a Pi 5.
Together they bring back builds that had stopped completing: a Pi 3A+ and a
Zero 2 W (512 MB) finish at one job, and a 1 GB Pi 3B+ that had failed several
attempts finished the same way. Not a guarantee — one 512 MB board has still
failed with both applied.
rbl_check_cargois shared, so pleezer and camilladsp get the raised stack toowhen they are built. The job budget stays in
packages/librespot/build.sh,where it was measured, and where the build runs on the user's own board.