Commit 8538bc6
authored
register openkal-llvm-runtime 0.13.0 (#449)
* the measured graph becomes the one every implementation declares in
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.
* the pin move is withdrawn from this change; the registration must ship 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.1 parent 2167824 commit 8538bc6
1 file changed
Lines changed: 21 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
38 | 38 | | |
39 | 39 | | |
40 | 40 | | |
| 41 | + | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
| 46 | + | |
| 47 | + | |
41 | 48 | | |
42 | 49 | | |
43 | 50 | | |
| |||
201 | 208 | | |
202 | 209 | | |
203 | 210 | | |
| 211 | + | |
| 212 | + | |
| 213 | + | |
| 214 | + | |
| 215 | + | |
| 216 | + | |
| 217 | + | |
204 | 218 | | |
205 | 219 | | |
206 | 220 | | |
| |||
364 | 378 | | |
365 | 379 | | |
366 | 380 | | |
| 381 | + | |
| 382 | + | |
| 383 | + | |
| 384 | + | |
| 385 | + | |
| 386 | + | |
| 387 | + | |
367 | 388 | | |
368 | 389 | | |
369 | 390 | | |
| |||
0 commit comments