Conversation
Upgraded rust version to 1.98.1
Reviewer's guide (collapsed on small PRs)Reviewer's GuideUpdates the Python builder’s Rust bootstrap configuration to download and verify Rust 1.98.1 instead of 1.95.0, while preserving the existing download source and build-script flow. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
Author
|
closing, will be done in different PR along with updates to other libs we're building from source |
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 14, 2026
build_rust fetched the installer from https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init, a path with no version anywhere in it: it always serves the newest rustup. RUST_HASH is the sha256 of that file, so it pinned the bytes of a moving target and broke the moment the rustup project cut a release: + curl -fsSL --retry 10 -o rustup-init \ https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init rustup-init: FAILED sha256sum: WARNING: 1 computed checksum did NOT match The pinned hash 4acc9acc is rustup 1.29.0 exactly; dist/ now serves 1.29.1 (dda72343). Nothing was tampered with -- the checksum did its job and refused a file that had legitimately changed underneath a version-less URL. Fetch from the immutable .../rustup/archive/1.29.1/ path instead, so RUST_HASH pins something that cannot move, and record in a comment that RUST_HASH covers the installer and not the toolchain. That distinction is easy to miss: RUST_VERSION is passed to --default-toolchain and selects the compiler, while the rustup version only decides which installer runs. Every other fetch_source in builder/build_scripts/ interpolates a *_ROOT variable that carries the version in the filename, so rustup-init was the only download exposed to this. Also bump RUST_VERSION 1.95.0 -> 1.98.1, carried over from calungaproject#418, which was closed so it could be folded in here. Verified with podman build --target build_rust: exit 0, "rustup-init: OK", and "rustc 1.98.1 (48a229cea 2026-09-01)" installed in the resulting stage. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 14, 2026
Every plumbing-builder PR pipeline has failed since 2026-09-01, in two
different places. Both are URL bugs in builder/Containerfile, and both fail the
same way: a URL that does not address a fixed artifact.
1. GNU autoconf/automake/libtool (install-autoconf.sh, step 5 of 29)
curl -fsSL --retry 10 -o autoconf-2.72.tar.gz \
https://ftpmirror.gnu.org/gnu/autoconf/autoconf-2.72.tar.gz
curl: (22) The requested URL returned error: 404
ftpmirror.gnu.org's root already is the GNU archive root -- it appends the
request path to each mirror's GNU directory -- so the extra /gnu/ produced a
doubled path segment:
.../mirrors/gnu//gnu/autoconf/autoconf-2.72.tar.gz -> 404
.../mirrors/gnu/autoconf/autoconf-2.72.tar.gz -> 200
Only ftp.gnu.org takes the /gnu/ prefix, because there the archive sits in a
/gnu/ subdirectory; the Containerfile was using ftp.gnu.org's layout against
the redirector. The URLs were inherited verbatim from pypa/manylinux
(docker/Dockerfile:65,72,79), which carries the same mistake.
Drop the redundant segment. Probed 18 times afterwards, six per tool:
18/18 HTTP 200. --retry never helped here, since curl's transient-error set
excludes 404 entirely.
2. rustup-init (build-rust.sh, step 12 of 29)
rustup-init: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
RUST_DOWNLOAD_URL pointed at https://static.rust-lang.org/rustup/dist, and the
fetched filename is a bare "rustup-init" -- no version anywhere in the path.
That endpoint always serves the newest rustup, so RUST_HASH pinned the bytes of
a moving target and broke as soon as rustup cut a release. The pinned hash
4acc9acc is rustup 1.29.0 exactly; dist/ now serves 1.29.1 (dda72343). Nothing
was tampered with: the checksum correctly refused a file that had legitimately
changed.
Fetch from the immutable .../rustup/archive/1.29.1/ path so RUST_HASH pins
something that cannot move, and record in a comment that RUST_HASH covers the
installer rather than the toolchain. That distinction is easy to miss:
RUST_VERSION is passed to --default-toolchain and selects the compiler, while
the rustup version only decides which installer runs. Cargo is not pinned
separately; it ships with the toolchain and follows RUST_VERSION.
Also bump RUST_VERSION 1.95.0 -> 1.98.1, carried over from calungaproject#418, which was
closed so it could be folded in here.
Every other fetch_source in builder/build_scripts/ interpolates a *_ROOT
variable that carries the version in the filename, so these were the only two
downloads exposed. Both tarball sets remain checksum-verified by
check_sha256sum after download.
The CI workflow comment in .github/workflows/test.yml attributed --skip-build
to download flakiness; that reason was this bug. Drop it. The remaining reasons
for pulling the published image -- Konflux builds the real one, and denylist
coverage is the job above -- stand on their own.
Verified in two parts. The rustup change and all 29 build stages ran clean on
the Konflux PR build -- zero curl errors across 18k log lines, and
"rustc 1.98.1 (48a229cea 2026-09-01)" installed. The corrected GNU URLs were
verified with podman build --no-cache --target runtime_base: all three tarballs
fetched from ftpmirror.gnu.org and checksummed OK, giving autoconf 2.72,
automake 1.18.1 and libtool 2.5.4 in the image.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 14, 2026
Every plumbing-builder PR pipeline has failed since 2026-09-01, in two
different places. Both are URL bugs in builder/Containerfile, and both fail the
same way: a URL that does not address a fixed artifact.
1. GNU autoconf/automake/libtool (install-autoconf.sh, step 5 of 29)
curl -fsSL --retry 10 -o autoconf-2.72.tar.gz \
https://ftpmirror.gnu.org/gnu/autoconf/autoconf-2.72.tar.gz
curl: (22) The requested URL returned error: 404
ftpmirror.gnu.org's root already is the GNU archive root -- it appends the
request path to each mirror's GNU directory -- so the extra /gnu/ produced a
doubled path segment:
.../mirrors/gnu//gnu/autoconf/autoconf-2.72.tar.gz -> 404
.../mirrors/gnu/autoconf/autoconf-2.72.tar.gz -> 200
Only ftp.gnu.org takes the /gnu/ prefix, because there the archive sits in a
/gnu/ subdirectory; the Containerfile was using ftp.gnu.org's layout against
the redirector. The URLs were inherited verbatim from pypa/manylinux
(docker/Dockerfile:65,72,79), which carries the same mistake.
Drop the redundant segment. Probed 18 times afterwards, six per tool:
18/18 HTTP 200. --retry never helped here, since curl's transient-error set
excludes 404 entirely.
2. rustup-init (build-rust.sh, step 12 of 29)
rustup-init: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
RUST_DOWNLOAD_URL pointed at https://static.rust-lang.org/rustup/dist, and the
fetched filename is a bare "rustup-init" -- no version anywhere in the path.
That endpoint always serves the newest rustup, so RUST_HASH pinned the bytes of
a moving target and broke as soon as rustup cut a release. The pinned hash
4acc9acc is rustup 1.29.0 exactly; dist/ now serves 1.29.1 (dda72343). Nothing
was tampered with: the checksum correctly refused a file that had legitimately
changed.
Fetch from the immutable .../rustup/archive/${RUSTUP_VERSION}/ path so
RUST_HASH pins something that cannot move, with the rustup version held in its
own variable alongside RUST_VERSION rather than buried in the URL, and record
in a comment that RUST_HASH covers the installer rather than the toolchain. That distinction is easy to miss:
RUST_VERSION is passed to --default-toolchain and selects the compiler, while
the rustup version only decides which installer runs. Cargo is not pinned
separately; it ships with the toolchain and follows RUST_VERSION.
Also bump RUST_VERSION 1.95.0 -> 1.98.1, carried over from calungaproject#418, which was
closed so it could be folded in here.
Every other fetch_source in builder/build_scripts/ interpolates a *_ROOT
variable that carries the version in the filename, so these were the only two
downloads exposed. Both tarball sets remain checksum-verified by
check_sha256sum after download.
The CI workflow comment in .github/workflows/test.yml attributed --skip-build
to download flakiness; that reason was this bug. Drop it. The remaining reasons
for pulling the published image -- Konflux builds the real one, and denylist
coverage is the job above -- stand on their own.
Verified in two parts. The rustup change and all 29 build stages ran clean on
the Konflux PR build -- zero curl errors across 18k log lines, and
"rustc 1.98.1 (48a229cea 2026-09-01)" installed. The corrected GNU URLs were
verified with podman build --no-cache --target runtime_base: all three tarballs
fetched from ftpmirror.gnu.org and checksummed OK, giving autoconf 2.72,
automake 1.18.1 and libtool 2.5.4 in the image.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 14, 2026
Every plumbing-builder PR pipeline has failed since 2026-09-01, in two
different places. Both are URL bugs in builder/Containerfile, and both fail the
same way: a URL that does not address a fixed artifact.
1. GNU autoconf/automake/libtool (install-autoconf.sh, step 5 of 29)
curl -fsSL --retry 10 -o autoconf-2.72.tar.gz \
https://ftpmirror.gnu.org/gnu/autoconf/autoconf-2.72.tar.gz
curl: (22) The requested URL returned error: 404
ftpmirror.gnu.org's root already is the GNU archive root -- it appends the
request path to each mirror's GNU directory -- so the extra /gnu/ produced a
doubled path segment:
.../mirrors/gnu//gnu/autoconf/autoconf-2.72.tar.gz -> 404
.../mirrors/gnu/autoconf/autoconf-2.72.tar.gz -> 200
Only ftp.gnu.org takes the /gnu/ prefix, because there the archive sits in a
/gnu/ subdirectory; the Containerfile was using ftp.gnu.org's layout against
the redirector. The URLs were inherited verbatim from pypa/manylinux
(docker/Dockerfile:65,72,79), which carries the same mistake.
Drop the redundant segment. Probed 18 times afterwards, six per tool:
18/18 HTTP 200. --retry never helped here, since curl's transient-error set
excludes 404 entirely.
2. rustup-init (build-rust.sh, step 12 of 29)
rustup-init: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
RUST_DOWNLOAD_URL pointed at https://static.rust-lang.org/rustup/dist, and the
fetched filename is a bare "rustup-init" -- no version anywhere in the path.
That endpoint always serves the newest rustup, so RUST_HASH pinned the bytes of
a moving target and broke as soon as rustup cut a release. The pinned hash
4acc9acc is rustup 1.29.0 exactly; dist/ now serves 1.29.1 (dda72343). Nothing
was tampered with: the checksum correctly refused a file that had legitimately
changed.
Fetch from the immutable .../rustup/archive/${RUSTUP_VERSION}/ path so
RUST_HASH pins something that cannot move, with the rustup version held in its
own variable alongside RUST_VERSION rather than buried in the URL, and record
in a comment that RUST_HASH covers the installer rather than the toolchain.
That distinction is easy to miss: RUST_VERSION is passed to --default-toolchain
and selects the compiler, while the rustup version only decides which installer
runs. Cargo is not pinned separately; it ships with the toolchain and follows
RUST_VERSION.
Also bump RUST_VERSION 1.95.0 -> 1.98.1, carried over from calungaproject#418, which was
closed so it could be folded in here.
Every other fetch_source in builder/build_scripts/ interpolates a *_ROOT
variable that carries the version in the filename, so these were the only two
downloads exposed. Both tarball sets remain checksum-verified by
check_sha256sum after download.
The CI workflow comment in .github/workflows/test.yml attributed --skip-build
to download flakiness. Drop it -- the remaining reasons for pulling the
published image, that Konflux builds the real one and denylist coverage is the
job above, stand on their own.
Verified in two parts. The rustup change and all 29 build stages ran clean on
the Konflux PR build -- zero curl errors across 18k log lines, and
"rustc 1.98.1 (48a229cea 2026-09-01)" installed. The corrected GNU URLs were
verified with podman build --no-cache --target runtime_base: all three tarballs
fetched from ftpmirror.gnu.org and checksummed OK, giving autoconf 2.72,
automake 1.18.1 and libtool 2.5.4 in the image.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 14, 2026
Every plumbing-builder PR pipeline has failed since 2026-09-01, in two
different places. Only the second one is ours to fix.
The first, GNU autoconf/automake/libtool at step 5 of 29, was a fault in
ftpmirror.gnu.org itself and has resolved on its own:
curl -fsSL --retry 10 -o autoconf-2.72.tar.gz \
https://ftpmirror.gnu.org/gnu/autoconf/autoconf-2.72.tar.gz
curl: (22) The requested URL returned error: 404
The redirector had started appending the request path to each mirror's GNU
directory rather than to its parent, producing a doubled segment
(.../mirrors/gnu//gnu/autoconf/autoconf-2.72.tar.gz). Our URLs were correct
throughout; --retry could not help, since curl's transient-error set excludes
404 and the mirror choice is a pure function of the request path, so every
attempt landed on the same broken mirror.
We were not alone: chimera-linux/cports#6169, fedora-infra/anitya#2073 (which
quotes the identical doubled path on the identical mirror we were assigned),
LibreELEC/LibreELEC.tv#11754 and #11759, and easybuilders/easybuild-framework
#5283 all report it over the same window. GNU published no announcement, but
the last third-party 404 is timestamped 2026-09-14T13:13Z and the path serves
correctly again now -- reconfirmed over six probes across all three tools,
6/6 HTTP 206 on /gnu/<tool>/ and 6/6 404 on the bare form. So the
Containerfile's GNU URLs are left exactly as they are; the mirrors are the
availability risk here, not the paths, and every tarball is
check_sha256sum-verified after download regardless.
That leaves the real bug, rustup-init (build-rust.sh, step 12 of 29):
rustup-init: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
RUST_DOWNLOAD_URL pointed at https://static.rust-lang.org/rustup/dist, and the
fetched filename is a bare "rustup-init" -- no version anywhere in the path.
That endpoint always serves the newest rustup, so RUST_HASH pinned the bytes of
a moving target and broke as soon as rustup cut a release. The pinned hash
4acc9acc is rustup 1.29.0 exactly; dist/ now serves 1.29.1 (dda72343). Nothing
was tampered with: the checksum correctly refused a file that had legitimately
changed.
Fetch from the immutable .../rustup/archive/${RUSTUP_VERSION}/ path so
RUST_HASH pins something that cannot move, with the rustup version held in its
own variable alongside RUST_VERSION rather than buried in the URL, and record
in a comment that RUST_HASH covers the installer rather than the toolchain.
That distinction is easy to miss: RUST_VERSION is passed to --default-toolchain
and selects the compiler, while the rustup version only decides which installer
runs. Cargo is not pinned separately; it ships with the toolchain and follows
RUST_VERSION.
Also bump RUST_VERSION 1.95.0 -> 1.98.1, carried over from calungaproject#418, which was
closed so it could be folded in here.
Every other fetch_source in builder/build_scripts/ interpolates a *_ROOT
variable that carries the version in the filename, so rustup-init was the only
download exposed to this class of failure.
Verified on the Konflux PR build: all 29 stages ran clean, zero curl errors
across 18k log lines, and "rustc 1.98.1 (48a229cea 2026-09-01)" installed.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 15, 2026
The variable holds the sha256 of rustup-init, the installer, but sat next to RUST_VERSION and read as though it belonged to it. That misreading is not hypothetical: calungaproject#418 bumped RUST_VERSION and replaced this hash together, described as "update the Rust release checksum", when the new value was in fact the rustup 1.29.1 installer. It went green for the wrong reason. RUSTUP_HASH pairs the hash with RUSTUP_VERSION, which is what actually determines it. check_var already fails the build loudly if the variable is unset, so a missed rename cannot pass silently. Five call sites: the export and comment in builder/Containerfile, check_var and check_sha256sum in build-rust.sh, and the reference in VERSION_UPDATES.md. That document is stale on the version it quotes (1.94.0, against 1.95.0 on main) but that drift is not this commit's to fix. The comment above the RUN shrinks from five lines to two. Most of it existed to explain that the hash was not the toolchain's, which the name now says. What remains is the part no name can carry: why the rustup version is pinned in the URL at all. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
to smatula/plumbing
that referenced
this pull request
Sep 15, 2026
Both describe rustup-init, the installer, but sat beside RUST_VERSION and read as though they belonged to it. That misreading is not hypothetical: calungaproject#418 bumped RUST_VERSION and replaced the hash together, described as "update the Rust release checksum", when the new value was in fact the rustup 1.29.1 installer's. It went green for the wrong reason. RUSTUP_HASH and RUSTUP_DOWNLOAD_URL pair both with RUSTUP_VERSION, which is what actually determines them -- the URL now points at rustup/archive/${RUSTUP_VERSION} and has nothing to do with the Rust release. RUST_VERSION keeps its name; it still selects the toolchain, via --default-toolchain. check_var already fails the build loudly on an unset variable, so a missed site cannot pass silently. Eight in total: two exports and a comment in builder/Containerfile, two check_var calls plus check_sha256sum and fetch_source in build-rust.sh, and a reference in VERSION_UPDATES.md. That document is stale on the version it quotes (1.94.0, against 1.95.0 on main) but that drift is not this commit's to fix. Neither name collides. RUSTUP_* is rustup's own environment namespace (RUSTUP_HOME, RUSTUP_DIST_SERVER, ...) and these are exported in the shell rustup-init runs in, but it reads neither of these names. The comment above the RUN shrinks from five lines to two. Most of it existed to explain that the hash was not the toolchain's, which the names now say. What remains is the part no name can carry: why the rustup version is pinned in the URL at all. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
that referenced
this pull request
Sep 15, 2026
Every plumbing-builder PR pipeline has failed since 2026-09-01, in two
different places. Only the second one is ours to fix.
The first, GNU autoconf/automake/libtool at step 5 of 29, was a fault in
ftpmirror.gnu.org itself and has resolved on its own:
curl -fsSL --retry 10 -o autoconf-2.72.tar.gz \
https://ftpmirror.gnu.org/gnu/autoconf/autoconf-2.72.tar.gz
curl: (22) The requested URL returned error: 404
The redirector had started appending the request path to each mirror's GNU
directory rather than to its parent, producing a doubled segment
(.../mirrors/gnu//gnu/autoconf/autoconf-2.72.tar.gz). Our URLs were correct
throughout; --retry could not help, since curl's transient-error set excludes
404 and the mirror choice is a pure function of the request path, so every
attempt landed on the same broken mirror.
We were not alone: chimera-linux/cports#6169, fedora-infra/anitya#2073 (which
quotes the identical doubled path on the identical mirror we were assigned),
LibreELEC/LibreELEC.tv#11754 and #11759, and easybuilders/easybuild-framework
#5283 all report it over the same window. GNU published no announcement, but
the last third-party 404 is timestamped 2026-09-14T13:13Z and the path serves
correctly again now -- reconfirmed over six probes across all three tools,
6/6 HTTP 206 on /gnu/<tool>/ and 6/6 404 on the bare form. So the
Containerfile's GNU URLs are left exactly as they are; the mirrors are the
availability risk here, not the paths, and every tarball is
check_sha256sum-verified after download regardless.
That leaves the real bug, rustup-init (build-rust.sh, step 12 of 29):
rustup-init: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match
RUST_DOWNLOAD_URL pointed at https://static.rust-lang.org/rustup/dist, and the
fetched filename is a bare "rustup-init" -- no version anywhere in the path.
That endpoint always serves the newest rustup, so RUST_HASH pinned the bytes of
a moving target and broke as soon as rustup cut a release. The pinned hash
4acc9acc is rustup 1.29.0 exactly; dist/ now serves 1.29.1 (dda72343). Nothing
was tampered with: the checksum correctly refused a file that had legitimately
changed.
Fetch from the immutable .../rustup/archive/${RUSTUP_VERSION}/ path so
RUST_HASH pins something that cannot move, with the rustup version held in its
own variable alongside RUST_VERSION rather than buried in the URL, and record
in a comment that RUST_HASH covers the installer rather than the toolchain.
That distinction is easy to miss: RUST_VERSION is passed to --default-toolchain
and selects the compiler, while the rustup version only decides which installer
runs. Cargo is not pinned separately; it ships with the toolchain and follows
RUST_VERSION.
Also bump RUST_VERSION 1.95.0 -> 1.98.1, carried over from #418, which was
closed so it could be folded in here.
Every other fetch_source in builder/build_scripts/ interpolates a *_ROOT
variable that carries the version in the filename, so rustup-init was the only
download exposed to this class of failure.
Verified on the Konflux PR build: all 29 stages ran clean, zero curl errors
across 18k log lines, and "rustc 1.98.1 (48a229cea 2026-09-01)" installed.
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
smatula
added a commit
that referenced
this pull request
Sep 15, 2026
Both describe rustup-init, the installer, but sat beside RUST_VERSION and read as though they belonged to it. That misreading is not hypothetical: #418 bumped RUST_VERSION and replaced the hash together, described as "update the Rust release checksum", when the new value was in fact the rustup 1.29.1 installer's. It went green for the wrong reason. RUSTUP_HASH and RUSTUP_DOWNLOAD_URL pair both with RUSTUP_VERSION, which is what actually determines them -- the URL now points at rustup/archive/${RUSTUP_VERSION} and has nothing to do with the Rust release. RUST_VERSION keeps its name; it still selects the toolchain, via --default-toolchain. check_var already fails the build loudly on an unset variable, so a missed site cannot pass silently. Eight in total: two exports and a comment in builder/Containerfile, two check_var calls plus check_sha256sum and fetch_source in build-rust.sh, and a reference in VERSION_UPDATES.md. That document is stale on the version it quotes (1.94.0, against 1.95.0 on main) but that drift is not this commit's to fix. Neither name collides. RUSTUP_* is rustup's own environment namespace (RUSTUP_HOME, RUSTUP_DIST_SERVER, ...) and these are exported in the shell rustup-init runs in, but it reads neither of these names. The comment above the RUN shrinks from five lines to two. Most of it existed to explain that the hash was not the toolchain's, which the names now say. What remains is the part no name can carry: why the rustup version is pinned in the URL at all. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
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.
Upgraded rust version to 1.98.1
Summary by Sourcery
Upgrade the Rust toolchain used by the Python builder to 1.98.1.
Enhancements:
Build: