chore: bundle xlings 2026.8.27.5, and release 2026.8.28.1 - #520
Merged
Conversation
The bundled xlings is what creates `<install>/registry/subos/default` and therefore decides that subos's runtime binding. Below 2026.8.27.2 it took that binding from a COMPILED-IN CONSTANT, which stays true only while the index happens to agree with it. mcpp is the party that notices when it stops agreeing, because select_glibc_payload_lib looks the payload up by the binding's exact version and deliberately refuses to fall back (#392): error: selected RuntimeBinding glibc@2.44 requires payload '<store>/xim-x-glibc/2.44', but it is not installed Measured across four xlings versions against an index carrying glibc 2.44 and 2.44.2 with `latest = 2.44.2`: v2026.8.8.1 [constant] declares 2.39 installs 2.44.2 MISMATCH v2026.8.10.1 [constant] declares 2.44 installs 2.44.2 MISMATCH 2026.8.27.4 [reads index] declares 2.44.2 installs 2.44.2 ok 2026.8.27.5 [index + D1] declares 2.44.2 installs 2.44.2 ok 2026.8.27.4 -- what this repo bundles today -- already reads the index and is consistent, so this is not a fix for a live defect. .5 adds the part that holds when `latest` is NOT the highest entry in the table: resolution honours what the subos declares over what the index calls newest. The index has that shape right now (musl `latest = 1.2.5` with 1.2.6 in the table), so it is not a hypothetical. What it unblocks: glibc 2.44.2 -- the build that fixes the host /etc/ld.so.preload breach (#484) -- has been withdrawn from the index three times because consumers pinned the binding name and none of them moved together. This is mcpp's half of moving them. The constant's comment now says FLOOR rather than just naming a version, with the failure it floors against, so the next person to touch it can tell a routine bump from a load-bearing one. Pin guard: OK, all 17 xlings pins at 2026.8.27.5.
Sunrisepeak
added a commit
to openxlings/xim-pkgindex
that referenced
this pull request
Aug 27, 2026
Withdrawn three times, never because the artifact was bad. The binding IS the
payload directory name, and consumers held that name as a compiled-in
constant: a consumer with `glibc@2.44` baked in needs `xim-x-glibc/2.44` on
disk, while 36 range dependencies (`glibc@>=2.38/2.39`) resolve through
select_best -- MAXIMUM satisfying, which does not consult `latest` -- and
install the higher one. The consumer then refuses:
error: selected RuntimeBinding glibc@2.44 requires payload
'<home>/.../xpkgs/xim-x-glibc/2.44', but it is not installed
What changed is that every consumer now takes the binding from THIS FILE
rather than from a constant, so both questions asked of this table give the
same answer again. Measured across four client versions against exactly the
state this commit produces:
v2026.8.8.1 [constant] declares 2.39 installs 2.44.2 mismatch
v2026.8.10.1 [constant] declares 2.44 installs 2.44.2 mismatch
2026.8.27.4 [reads index] declares 2.44.2 installs 2.44.2 ok
2026.8.27.5 [index + D1] declares 2.44.2 installs 2.44.2 ok
Both mismatching versions are out of the loop: openxlings/xlings#574 moved all
seven CI bootstrap pins to 2026.8.27.5, and mcpp-community/mcpp#520 moved
mcpp's bundled xlings there too.
MOVING `latest` WITH THE ENTRY IS NOT OPTIONAL. Adding 2.44.2 while leaving
`latest` at 2.44 is strictly worse than not adding it -- select_best would
install 2.44.2 while every binding still said 2.44. That was measured too.
Why it is worth doing, `strings` on the two published loaders:
2.44 2.44.2
XLINGS_LD_PRELOAD_FILE absent present
build-machine paths 8 0
preload path /etc/ld.so.preload /nonexistent/...
The 2.44 every user is on today reads the HOST's /etc/ld.so.preload
(mcpp-community/mcpp#484) and still carries the machine it was built on.
2.44 stays in the table, append-only: subos created against it keep
resolving, and on 2026.8.27.5 the declaration outranks `latest`, so they are
not dragged forward.
sha256 recomputed from the downloaded artifact, not copied from the
withdrawal note: ed4bf048b8ed2b65433e0dd655f93133da4a9bd458276cfa986b7cccde835d08
tests/g/test_glibc.py: 11 passed, 1 failed -- the failure is bare-name
ambiguity from three namespaces providing glibc on this machine, and it fails
identically on unmodified main.
Co-authored-by: sunrisepeak <x.d2learn.org@gmail.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
2 participants
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.
The bundled xlings creates
<install>/registry/subos/defaultand therefore decides that subos's runtime binding. Below2026.8.27.2it took that binding from a compiled-in constant, which stays true only while the index happens to agree with it.mcpp is the party that notices when it stops agreeing —
select_glibc_payload_liblooks the payload up by the binding's exact version and deliberately refuses to fall back (#392):Measured
Four xlings versions against an index carrying glibc 2.44 and 2.44.2,
latest = 2.44.2:v2026.8.8.1v2026.8.10.12026.8.27.42026.8.27.52026.8.27.4— what this repo bundles today — is already consistent, so this is not a fix for a live defect..5adds the part that holds whenlatestis not the highest entry in the table: resolution honours what the subos declares over what the index calls newest.That shape exists right now — the index has
muslatlatest = 1.2.5with1.2.6in the table — so it is not hypothetical.What it unblocks
glibc 2.44.2, the build that fixes the host
/etc/ld.so.preloadbreach (#484), has been withdrawn from the index three times because consumers pinned the binding name and none of them moved together. This is mcpp's half of moving them; openxlings/xlings#574 is the other half. The index entry moves last.Also
The constant's comment now says FLOOR rather than just naming a version, and states the failure it floors against — so the next person can tell a routine bump from a load-bearing one.
Pin guard:
OK: xlings pins all at 2026.8.27.5(17 pins across 8 files).