Repository navigation
amd64: consume the bootstrap chain as sealed tarballs, like arm64 (interim; stops ladder rebuilds) - #825
Merged
Conversation
…terim) Every change under openssl/python/glibc rebuilt the whole amd64 hex0 chain (38 packages: stage0 ladder, glibc-bedrock, gcc/binutils-*-glibc, go-1.4..1.24.9, mrustc, rustc-1.91..1.97), because its build tools come from the live tree. That backs up build-bot on every world-touching PR. arm64 already avoids this: the chain is empty stubs there and `go` / `rust` take sha-pinned tarballs of its last rung. This does the same on amd64, behind one switch (packages/hex0/amd64-ladder.ncl, `enabled = false`): - the 38 chain packages' amd64 spec is an empty stub while the switch is off - go (amd64) takes go-1.24.9 as a prebuilt over build-bot's own output of that rung; rust (amd64) does the same for rustc-1.97.1, with the rung's runtime_deps. Both tarballs are build-bot's artifacts at 9d20a83 (commit map sha), copied to gs://minimal-staging-archives/prebuilts/bedrock/sha256/<sha>/, same layout as the rungs (usr/lib/...), so build.sh is unchanged. Flip the switch to true to build the chain from hex0 again. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Warning Review limit reached
This review includes 4 billable files and costs up to $1.00.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 40 minutes for your next included review. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check |  |
Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | |
The title clearly and concisely describes the main change: amd64 will consume the bootstrap chain as sealed tarballs, matching arm64 behavior, to stop ladder rebuilds. The interim qualifier is relevan… |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
Member
Author
|
@coderabbitai full review |
Contributor
✅ Action performedFull review finished. |
norrietaylor
reviewed
Oct 9, 2026
Member
There was a problem hiding this comment.
Verified: both bedrock tarballs resolve on storage.googleapis.com and hash to the declared sha256; BUILDINFO in each matches the rung recipe (go-1.24.9 bootstrapped from go-1.22.6; rustc 1.97.1 built by stage0 1.96.0 against external llvm 21.1.8); layout matches what the unchanged go/build.sh and rust/build.sh expect at /usr/lib/...; prebuilt rustc runtime_deps equals the rung's; DT_NEEDED on rustc/cargo all covered. All 38 chain hunks are identical modulo name. Only go and rust consume the chain on main, so nothing else changes. CI green.
Not approving yet because of merge ordering, which git will not catch:
- #775 (jvm) depends on three packages this PR stubs out on amd64. Its root rungs import
gcc-15.2.0-glibc,binutils-2.46-glibcandglibc-bedrock-2.42as build_deps and hardcodeSR=/usr/lib/glibc-bedrock-2.42in build.sh. Withenabled = falsethose are empty stubs, so the jvm ladder gets nothing hydrated and fails at its asserts. No file overlap, so no conflict warning. The body mentions #810 but not #775. Either #775 needs a bedrock tarball for those three too, or this lands after #775 (and #810). - #810 conflicts textually on the amd64 arm of
packages/rust/build.ncl, and its newrustc-1.98.1rung takesrustc-1-97-1as amd64 stage0, which this PR empties. Body acknowledges this one. - "Interim" has no tracking issue.
hex0/amd64-ladder.ncl:14-15cites branchladder-sealed-tools, which does not exist on origin, and no open issue mentions the ladder. Please file one and link it from the switch file soenabled = falseis not forgotten. - amd64 rustc tarball is more fragile than arm64's.
host-llvm: external, link-shared; it ships onlylibrustc_driver-*.soand relies on the livellvmpackage, whereas the arm64 comment says that tarball bundles itslibLLVM.so.21.1. Previously an llvm soname bump rebuilt the rung; now it breaksruston amd64 until someone flips the switch and regenerates. Worth a sentence in the comment for the next llvm bumper.
Lower priority:
- Provenance is weaker than the arm64 precedent it mirrors: arm64 cites double-run byte reproduction and minimermetic#16; these cite only a build-bot commit map a reviewer cannot see, and there is no
.intotonext to either tarball (stage0-* roots do have them). A build-bot run URL or attestation would close that. - Comments now stale while the switch is off:
go/build.ncl:5"amd64 bootstraps from the go-1.24.9 rung",rust/build.ncl:38-40, and the "This package exists on amd64 only" preambles in all 38 chain files. packages/hex0/amd64-ladder.nclis the first non-build.ncl.nclunder any package dir and governs the go/rustc/mrustc ladders too, not just hex0. Fine for an interim switch; noting the precedent.
…tc-1.98.1 rung) # Conflicts: # packages/rust/build.ncl
…m note, stale comments) - #810 moved rust's stage0 to the rustc-1.98.1 rung, so the amd64 bedrock arm moves there (mirrors its arm64 arm); rust/build.ncl is back to main's. The 1.97.1 tarball is unchanged. - llvm bumpers: the amd64 tarball links the live libLLVM, unlike arm64's. - the switch file names its consumers and the new-consumer trap (#775). - stale comments: go/build.ncl and all 38 chain preambles. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
Author
|
@norrietaylor thanks, and sorry this sat. Point by point; the changes are in 199819e: a merge of main, then the review commit, no force-push.
Lower priority:
|
…ts, not stubs gcc-15.2.0-glibc, binutils-2.46-glibc and glibc-bedrock-2.42 now take the same sha-pinned tarballs the production gcc/binutils/glibc packages already anchor on (minimermetic#16), with their own outputs. The jvm ladder (#775) imports them; it now builds either way (jikes-1.22 rebuilt and checked on the sealed trio). The switch file's new-consumer note narrows to the rest. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…spec.<field> Reading a field back out of the contracted amd64_spec record broke the whole-repo evaluation (mip dump: "not a function" in std contract/custom), which per-package checks did not hit. Hoist both into lets, as the production glibc does with all_outputs. With the switch on, all three spec hashes are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
evanspearman
approved these changes
Oct 14, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Oct 14, 2026
This was referenced Oct 19, 2026
bryan-minimal
added a commit
that referenced
this pull request
Oct 21, 2026
Review follow-ups (mitodrummer): - build.sh: the Widevine guard tests `find -print -quit` output instead of piping find into grep -q, which under pipefail could pass the guard on a SIGPIPE. Drop upstream's unused `chrome-wrapper` script with the Qt shims (layout_check asserts it is gone). - build.ncl: one per-arch `release_url` let feeds both the Source and `binary_from` (it was written out four times). - build.ncl: the provenance comment cites gominimal/pkgmgr-rs#1029 (re-identify off microsoft/playwright, after a supply-chain cpe_remap) instead of #825, which closed and covered lifecycle bounds. Co-Authored-By: Claude Opus 5.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
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.
Interim fix for build-bot backing up. Every change under openssl/python/glibc currently rebuilds the whole amd64 hex0-rooted chain, because its build tools (bash, coreutils, sed, …) come from the live tree. arm64 already avoids this: the chain is empty stubs there, and
go/rusttake sha-pinned tarballs of the chain's last rung. This PR does the same on amd64, behind one switch.Change
packages/hex0/amd64-ladder.ncl:{ enabled = false }. Flip it totrueto build the chain from hex0 again.go(amd64): go-1.24.9 comes from aprebuiltspec over build-bot's own output of that rung.rust(amd64): same for rustc-1.97.1, with the rung's runtime_deps (libffi, llvm, openssl, sqlite, gcc libs).9d20a830(sha from its commit map), copied togs://minimal-staging-archives/prebuilts/bedrock/sha256/<sha>/and verified with an anonymous readback. They have the same layout as the rungs (usr/lib/go-1.24.9,usr/lib/rustc-1.97.1), sogoandrust's build.sh are unchanged and see the same input tree.Evidence
Spec hashes from
mip dump --arch amd64(no build):min check(go, rust and the 38): parse, imports, import line, fmt, spec names and source urls all Pass.goandrustchange inputs, so 139 Go and Rust programs rebuild once. pkgs#810 (rust 1.99) rebuilds every Rust program anyway, so landing these together pays that roughly once. rust: 1.98.1 -> 1.99.0 (new rustc-1.98.1 rung; arm64 rung builds from the 1.97.1 bedrock) #810's newrustc-1.98.1rung imports rustc-1.97.1 on amd64 and needs the same tarball after this; I'll update rust: 1.98.1 -> 1.99.0 (new rustc-1.98.1 rung; arm64 rung builds from the 1.97.1 bedrock) #810.Longer term
Seal the chain's build tools so it stops depending on the tree at all, then flip the switch back. That is hash-proven separately (0/23 rungs move with all tools sealed), but it needs sealed
patch/pythonfirst.🤖 Generated with Claude Code
Summary by CodeRabbit