8000 Drop the hex0 -> stage0-* -> glibc-bedrock-2.42 chain (23 packages) by bryan-minimal · Pull Request #1465 · gominimal/pkgs · GitHub
[go: up one dir, main page]

Skip to content

Drop the hex0 -> stage0-* -> glibc-bedrock-2.42 chain (23 packages) - #1465

Draft
bryan-minimal wants to merge 5 commits into
mainfrom
bryan/drop-hex0-chain
Draft

bryan-minimal wants to merge 5 commits into
mainfrom
bryan/drop-hex0-chain

Conversation

@bryan-minimal
Copy link
Copy Markdown
Member

Stacked on #1462 and #1442 (both merged in); merge those first, then this lands as the single deletion commit.

Nothing in pkgs reads the chain any more. Its last consumer was glibc-bedrock-2.42-sysroot (gone in #1462); the three orphans above it go in #1442. Every bootstrap root pins a gominimal/bootstrap generation object by sha-keyed URL, and the chain lives on there, built and reproduced per generation.

Removed

  • hex0 (with amd64-ladder.ncl, the amd64 switch that has been enabled = false since 2026-10-07)
  • the 21 stage0-* rungs: hex1, kaem, mes, mescc, mescc-full, tcc-0.9.26, tcc-0.9.27 (+ musl-s1/s3/s4), musl-1.1.24 (+ cc2), musl-1.2.5, binutils-2.30/2.41, gcc-4.0.4/4.7.4/10.4.0/15.2.0, gmp-mpfr-mpc, linux-headers-6.12.43
  • glibc-bedrock-2.42

No package outside the chain imports any of them (checked every ../<pkg>/ reference under packages/).

CI scope test

test_ci_scope.py used hex0/amd64-ladder.ncl as its shared-helper fixture. It now uses llvm/versioned.ncl, the helper with the most importers left; the comments in ci_scope.py and blast_radius_report.py name the same example. 15/15 tests pass.

🤖 Generated with Claude Code

bryan-minimal and others added 5 commits November 11, 2026 09:33
< 8000 div data-view-component="true" class="TimelineItem-body">
…ladder comment

Follow-up to #1242 (msample's review). Since #1242, nothing in pkgs
imports gcc-15.2.0-glibc or fastjar, and binutils-2.46-glibc's only
importer was gcc-15.2.0-glibc. gominimal/bootstrap builds all three
(generations/gen-13/manifest.json), and pkgs takes their gen-13 outputs
through the gcc and binutils pins, so these copies were dead.

hex0/amd64-ladder.ncl still described the old 38-package chain with the
go/mrustc/rustc rungs. It now names what is left in pkgs (hex0, stage0-*,
glibc-bedrock-2.42: 23 packages) and the one live consumer path
(glibc-bedrock-2.42-sysroot, for ghc and the openjdks).

No spec hash changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…sroot package

gen-15 of gominimal/bootstrap builds the amd64 openjdk-21/25/26 and ghc-9.6.7 against the
system glibc with the gcc seed: PT_INTERP /usr/lib/ld-linux-x86-64.so.2, no RUNPATH beyond
their own $ORIGIN entries, and ghc-cc a plain gcc wrapper that adds that loader. The four pins
move to gen-15 on both arches (arm64's objects are the gen-13 bytes under their gen-15 names,
ghc-9.6.7's rebuilt from the shared script and identical apart from BUILDINFO) and their amd64
runtime dep becomes glibc. ghc drops the sysroot from its amd64 build deps; its check that
nothing shipped names the sysroot stays. Nothing imports glibc-bedrock-2.42-sysroot any more,
so the package goes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
(cherry picked from commit 1151b19)
The arm64 JDK objects are the gen-13 bytes re-published under gen-15
(bootstrap generations/gen-15/manifest.json lists each sha256 at its gen-15
url), so the url moves and the sha256 correctly stays. Comments only; no
spec hash changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nothing in pkgs reads it: the sysroot was its last consumer, and the
bootstrap roots pin gominimal/bootstrap generation objects instead. The
chain lives on there, built and reproduced per generation. The amd64
switch hex0/amd64-ladder.ncl goes with it.

The CI-scope test used hex0's ladder helper as its shared-helper fixture;
llvm/versioned.ncl is the one with the most importers now.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@coderabbitai
coderabbitai Bot commented Nov 12, 2026
Copy link
Copy Markdown
Contributor

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0