You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The bump is correct and this release cannot carry it. Measured on CI rather than
predicted:
Downloading xim:glibc@2.44
error: toolchain post-install fixup: selected RuntimeBinding glibc@2.44.2
requires payload '…/xpkgs/xim-x-glibc/2.44.2', but it is not installed
Two versions of one decision meet inside a single run. The mcpp that BUILDS this
one is the released 2026.8.25.2, whose compiled-in pin is 2026.8.17.2, and it
installs the payload its own binding names: 2.44. The vendored xlings that
COMPUTES the binding is the one this branch pins, which asks the index and gets
2.44.2. The request is then newer than what is installed.
That is the direction `payload_dir_for_version` refuses, and it must: accepting a
payload older than the request would silently use the one the index states is not
the one to install --- the preload defect of mcpp#484.
⚠️ THIS IS NOT A STALE CACHE. The sandbox cache key includes the xlings version
for exactly this reason, so the bump is a cache miss and the sandbox was fresh.
The mismatch is between the engine doing the building and the xlings it was told
to vendor.
⭐ IT IS SELF-HEALING, AND ONLY IN ONE ORDER. Once 2026.8.27.1 is released, a
bootstrap from it carries the new pin, computes 2.44.2, and installs 2.44.2. The
bump therefore belongs in the release AFTER this one, which is the rule the index
states in its own source: "The index is DATA and the client is a PROGRAM: the
consumer ships first."
The engine-side half of the same problem stays in this release:
`payload_dir_for_version` accepts an installed payload whose version REFINES a
request an older client already compiled in, so older clients stop being stranded
by an index move in the safe direction.
0 commit comments