register openkal-llvm-runtime 0.13.0 - #449
Merged
Merged
Conversation
openkal-llvm-runtime 0.13.0 is registered, and `tests/openkal/pins.toml` moves onto it. That version pins openkal-musl 0.18.0, which pins openkal-linux 0.15.0, openkal-windows 0.10.0 and openkal-macos 0.12.0 --- so it is the first graph in which ALL THREE implementations declare which interfaces of the layer they provide. WHY THAT MATTERS FOR A MEASUREMENT AND NOT ONLY FOR A BUILD. Below this pin a member's `[kernel-abi] requires-interfaces` was answered on two of the three implementations and silently unanswered on the third: openkal-macos carried no array, and mcpp treats a provider that states nothing as stating nothing rather than as providing nothing. A measurement taken there records "builds" for a member whose requirement nothing checked, which is the one reading this file must never produce. `mcpp` moves to 2026.9.20.1 in the same change, because the set difference being measured is what that release added, and `openkal-compat.yml`'s own pin moves with it --- that workflow fails the run when the two disagree. `validate.yml` moves too: an index that lints itself with an engine ten releases behind is validating against something no user runs. `latest_mcpp` moves. `min_mcpp` DOES NOT, and the reason is written beside it: both new manifest keys are top-level tables that an older engine ignores, and all 231 descriptors parse with 2026.9.18.3, so the descriptor grammar this floor governs did not change. Raising it would take the whole index from every client below it for a diagnostic note they merely would not receive. Verified: 231 descriptors parse with the newly pinned 2026.9.20.1 as well; the sha256 was recomputed from a fresh download and the CN asset compared byte for byte against it; five descriptor lints pass; compat.py's selftest passes.
…p first
This branch registered openkal-llvm-runtime 0.13.0 AND moved
`tests/openkal/pins.toml` onto it in one change. Every member of the
measurement then failed at once, on both targets:
error: xlings install_packages failed (exit 1) for
'openkal-llvm-runtime@0.13.0' with an unknown index-repo configuration
`compat.py` gives each copied member an `[indices] compat = { path = <this
checkout> }` so that a CHANGED DESCRIPTOR in this tree is what gets measured.
That serves resolution from the working tree; it does not serve INSTALLATION,
which is delegated to xlings and reaches only the repositories xlings has
synced. A version that exists solely in this checkout therefore parses and
then fails to install --- and because the runtime pin is in every member's
manifest, it fails in every member, which reads as a compatibility result
rather than as a missing registration.
The repository already knew this. `443b974` moved the pin to runtime 0.12.0
and touched no descriptor file: 0.12.0 had been registered and published in an
earlier change. Registration first, published, and only then the pin.
So this change is the registration alone. The pin move, `latest_mcpp`, and the
two MCPP_VERSION pins follow in a second change once the artifact carrying
this descriptor is out.
Sunrisepeak
changed the title
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.
What this registers
openkal-llvm-runtime 0.13.0, in all three platform blocks. It pins openkal-musl 0.18.0, which pins openkal-linux 0.15.0, openkal-windows 0.10.0 and openkal-macos 0.12.0 — the first graph in which all three implementations declare which interfaces of the layer they provide.
The pin move was withdrawn from this PR, and why
This branch first registered 0.13.0 and moved
tests/openkal/pins.tomlonto it in one change. Every member then failed at once, on both targets:compat.pygives each copied member an[indices] compat = { path = <this checkout> }so a changed descriptor in this tree is what gets measured. That serves resolution from the working tree; it does not serve installation, which is delegated to xlings and reaches only the repositories xlings has synced. A version existing solely in this checkout parses and then fails to install — and since the runtime pin is in every member's manifest, it fails in every member, which reads as a compatibility result rather than as a missing registration.The repository already knew this:
443b974moved the pin to runtime 0.12.0 and touched no descriptor file, because 0.12.0 had been registered and published earlier.Registration first, published, then the pin. The pin move,
latest_mcppand the twoMCPP_VERSIONpins follow in a second PR.