From 2317fef67d8062fc49d7de6e7ad54d08232a5272 Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Mon, 21 Sep 2026 00:05:22 +0800 Subject: [PATCH 1/2] 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. --- .github/workflows/openkal-compat.yml | 2 +- .github/workflows/validate.yml | 2 +- index.toml | 22 +++++++++++++++++++++- pkgs/o/openkal-llvm-runtime.lua | 21 +++++++++++++++++++++ tests/openkal/pins.toml | 17 ++++++++++++++--- 5 files changed, 58 insertions(+), 6 deletions(-) diff --git a/.github/workflows/openkal-compat.yml b/.github/workflows/openkal-compat.yml index b5625702..4e9bf3fd 100644 --- a/.github/workflows/openkal-compat.yml +++ b/.github/workflows/openkal-compat.yml @@ -33,7 +33,7 @@ env: # run if this drifts from pins.toml. See the comment beside `mcpp` in # pins.toml for why this pin, not just validate.yml's, is gated by the # index floor. - MCPP_VERSION: "2026.9.18.3" + MCPP_VERSION: "2026.9.20.1" XLINGS_NON_INTERACTIVE: "1" jobs: diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 59f866b1..18d973a2 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -301,7 +301,7 @@ env: # is a cold one (mcpp's build-cache epoch moved from 2 to 3 in this same # release, because the old cache key did not cover the realised [c-abi] # environment). - MCPP_VERSION: "2026.9.18.3" + MCPP_VERSION: "2026.9.20.1" jobs: lint: diff --git a/index.toml b/index.toml index 6182e10a..9d054acf 100644 --- a/index.toml +++ b/index.toml @@ -79,7 +79,27 @@ # raising the floor was gated on the engine, not on those two packages, and # gating on both at once would have held this raise hostage to something it # does not need. +# ── 2026-09-20: latest_mcpp -> 2026.9.20.1, min_mcpp DELIBERATELY UNCHANGED ── +# +# That release adds two manifest keys, `[kernel-abi]` and `[c-abi-absent]`, +# and neither asks anything of this floor. mcpp IGNORES a top-level table it +# does not know and REFUSES an unknown MEMBER of a table it does know; both +# keys are top-level, so a client stopped at 2026.9.18.3 loads the manifests +# that carry them and loses only the check. +# +# Measured, not assumed. The absence table was first written as +# `[c-abi].absent`, and the published 2026.9.18.3 archive refused +# openkal-musl's whole manifest on every target with `[c-abi] has no member +# 'absent'`; moved to the top level, that same published binary builds it. +# openkal-musl's own CI pins 2026.9.18.3 and is green on 0.17.0 and 0.18.0, +# which is that statement end to end. All 231 descriptors parse with +# 2026.9.18.3 as well, so the DESCRIPTOR grammar --- the thing this floor +# actually governs --- did not change either. +# +# Raising it would have cost every client below the floor the WHOLE index +# (E0006 at the index-open choke point) for a diagnostic note they merely +# would not have received. [index] spec = "1" min_mcpp = "2026.9.18.3" -latest_mcpp = "2026.9.18.3" +latest_mcpp = "2026.9.20.1" diff --git a/pkgs/o/openkal-llvm-runtime.lua b/pkgs/o/openkal-llvm-runtime.lua index a5a85b2e..fa1abe7a 100644 --- a/pkgs/o/openkal-llvm-runtime.lua +++ b/pkgs/o/openkal-llvm-runtime.lua @@ -38,6 +38,13 @@ package = { xpm = { linux = { + ["0.13.0"] = { + url = { + GLOBAL = "https://github.com/mcpplibs/openkal-llvm-runtime/archive/refs/tags/0.13.0.tar.gz", + CN = "https://gitcode.com/mcpp-res/openkal-llvm-runtime/releases/download/0.13.0/openkal-llvm-runtime-0.13.0.tar.gz", + }, + sha256 = "56b9dc2b756d78aa2eafed2e2219b81931d12c29efdb68d6b1fc8730f62ff96d", + }, ["0.12.0"] = { url = { GLOBAL = "https://github.com/mcpplibs/openkal-llvm-runtime/archive/refs/tags/0.12.0.tar.gz", @@ -201,6 +208,13 @@ package = { }, }, macosx = { + ["0.13.0"] = { + url = { + GLOBAL = "https://github.com/mcpplibs/openkal-llvm-runtime/archive/refs/tags/0.13.0.tar.gz", + CN = "https://gitcode.com/mcpp-res/openkal-llvm-runtime/releases/download/0.13.0/openkal-llvm-runtime-0.13.0.tar.gz", + }, + sha256 = "56b9dc2b756d78aa2eafed2e2219b81931d12c29efdb68d6b1fc8730f62ff96d", + }, ["0.12.0"] = { url = { GLOBAL = "https://github.com/mcpplibs/openkal-llvm-runtime/archive/refs/tags/0.12.0.tar.gz", @@ -364,6 +378,13 @@ package = { }, }, windows = { + ["0.13.0"] = { + url = { + GLOBAL = "https://github.com/mcpplibs/openkal-llvm-runtime/archive/refs/tags/0.13.0.tar.gz", + CN = "https://gitcode.com/mcpp-res/openkal-llvm-runtime/releases/download/0.13.0/openkal-llvm-runtime-0.13.0.tar.gz", + }, + sha256 = "56b9dc2b756d78aa2eafed2e2219b81931d12c29efdb68d6b1fc8730f62ff96d", + }, ["0.12.0"] = { url = { GLOBAL = "https://github.com/mcpplibs/openkal-llvm-runtime/archive/refs/tags/0.12.0.tar.gz", diff --git a/tests/openkal/pins.toml b/tests/openkal/pins.toml index 529f4d3c..51026b10 100644 --- a/tests/openkal/pins.toml +++ b/tests/openkal/pins.toml @@ -4,7 +4,7 @@ # `runtime` is the C++ runtime for openkal; it pins openkal-musl exactly, and # openkal-musl selects the openkal implementation for each target, so this one # version names the whole graph. -runtime = "0.12.0" +runtime = "0.13.0" toolchain = "llvm@22.1.8" # `mcpp` here moves together with index.toml's `min_mcpp` and # .github/workflows/openkal-compat.yml's own MCPP_VERSION (that workflow @@ -18,7 +18,18 @@ toolchain = "llvm@22.1.8" # index requires mcpp >= 2026.9.18.1 but this is mcpp 2026.9.17.3 [E0006]" # before a single line of the member's own source is read. # -# `runtime` MOVES HERE NOW, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH +# 2026-09-20: `runtime` MOVES TO 0.13.0, WHICH IS THE FIRST GRAPH IN WHICH +# EVERY IMPLEMENTATION DECLARES ITS INTERFACES. 0.13.0 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 last of those is the release that closed the +# gap. Below it a member's `[kernel-abi] requires-interfaces` was answered on +# two of the three implementations and silently unanswered on the third, and +# a measurement taken there would have recorded "builds" for a member nothing +# had checked. `mcpp` moves with it because the set difference this measures +# is what 2026.9.20.1 added. +# +# (the note below is from the previous move, and its reasoning still holds) +# `runtime` MOVED, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH # WITH NO `[c-abi]` IN IT. openkal-llvm-runtime 0.12.0 (openkal-musl 0.16.0, # openkal 0.14.0) is the first pinned graph in which a package declares the # block, so it is the first in which mcpp realises `presents = "posix"` at all: @@ -33,7 +44,7 @@ toolchain = "llvm@22.1.8" # openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0), because a pin that # moves onto an unreachable or divergent asset fails every member at once and # reports it as a compatibility result. -mcpp = "2026.9.18.3" +mcpp = "2026.9.20.1" targets = ["x86_64-linux-gnu", "x86_64-windows-gnu"] From 19237d97a7b1461d5a0e3e8f368dbc4f5deebe65 Mon Sep 17 00:00:00 2001 From: sunrisepeak Date: Mon, 21 Sep 2026 00:25:36 +0800 Subject: [PATCH 2/2] 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 = }` 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. --- .github/workflows/openkal-compat.yml | 2 +- .github/workflows/validate.yml | 2 +- index.toml | 22 +--------------------- tests/openkal/pins.toml | 17 +++-------------- 4 files changed, 6 insertions(+), 37 deletions(-) diff --git a/.github/workflows/openkal-compat.yml b/.github/workflows/openkal-compat.yml index 4e9bf3fd..b5625702 100644 --- a/.github/workflows/openkal-compat.yml +++ b/.github/workflows/openkal-compat.yml @@ -33,7 +33,7 @@ env: # run if this drifts from pins.toml. See the comment beside `mcpp` in # pins.toml for why this pin, not just validate.yml's, is gated by the # index floor. - MCPP_VERSION: "2026.9.20.1" + MCPP_VERSION: "2026.9.18.3" XLINGS_NON_INTERACTIVE: "1" jobs: diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 18d973a2..59f866b1 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -301,7 +301,7 @@ env: # is a cold one (mcpp's build-cache epoch moved from 2 to 3 in this same # release, because the old cache key did not cover the realised [c-abi] # environment). - MCPP_VERSION: "2026.9.20.1" + MCPP_VERSION: "2026.9.18.3" jobs: lint: diff --git a/index.toml b/index.toml index 9d054acf..6182e10a 100644 --- a/index.toml +++ b/index.toml @@ -79,27 +79,7 @@ # raising the floor was gated on the engine, not on those two packages, and # gating on both at once would have held this raise hostage to something it # does not need. -# ── 2026-09-20: latest_mcpp -> 2026.9.20.1, min_mcpp DELIBERATELY UNCHANGED ── -# -# That release adds two manifest keys, `[kernel-abi]` and `[c-abi-absent]`, -# and neither asks anything of this floor. mcpp IGNORES a top-level table it -# does not know and REFUSES an unknown MEMBER of a table it does know; both -# keys are top-level, so a client stopped at 2026.9.18.3 loads the manifests -# that carry them and loses only the check. -# -# Measured, not assumed. The absence table was first written as -# `[c-abi].absent`, and the published 2026.9.18.3 archive refused -# openkal-musl's whole manifest on every target with `[c-abi] has no member -# 'absent'`; moved to the top level, that same published binary builds it. -# openkal-musl's own CI pins 2026.9.18.3 and is green on 0.17.0 and 0.18.0, -# which is that statement end to end. All 231 descriptors parse with -# 2026.9.18.3 as well, so the DESCRIPTOR grammar --- the thing this floor -# actually governs --- did not change either. -# -# Raising it would have cost every client below the floor the WHOLE index -# (E0006 at the index-open choke point) for a diagnostic note they merely -# would not have received. [index] spec = "1" min_mcpp = "2026.9.18.3" -latest_mcpp = "2026.9.20.1" +latest_mcpp = "2026.9.18.3" diff --git a/tests/openkal/pins.toml b/tests/openkal/pins.toml index 51026b10..529f4d3c 100644 --- a/tests/openkal/pins.toml +++ b/tests/openkal/pins.toml @@ -4,7 +4,7 @@ # `runtime` is the C++ runtime for openkal; it pins openkal-musl exactly, and # openkal-musl selects the openkal implementation for each target, so this one # version names the whole graph. -runtime = "0.13.0" +runtime = "0.12.0" toolchain = "llvm@22.1.8" # `mcpp` here moves together with index.toml's `min_mcpp` and # .github/workflows/openkal-compat.yml's own MCPP_VERSION (that workflow @@ -18,18 +18,7 @@ toolchain = "llvm@22.1.8" # index requires mcpp >= 2026.9.18.1 but this is mcpp 2026.9.17.3 [E0006]" # before a single line of the member's own source is read. # -# 2026-09-20: `runtime` MOVES TO 0.13.0, WHICH IS THE FIRST GRAPH IN WHICH -# EVERY IMPLEMENTATION DECLARES ITS INTERFACES. 0.13.0 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 last of those is the release that closed the -# gap. Below it a member's `[kernel-abi] requires-interfaces` was answered on -# two of the three implementations and silently unanswered on the third, and -# a measurement taken there would have recorded "builds" for a member nothing -# had checked. `mcpp` moves with it because the set difference this measures -# is what 2026.9.20.1 added. -# -# (the note below is from the previous move, and its reasoning still holds) -# `runtime` MOVED, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH +# `runtime` MOVES HERE NOW, AND UNTIL IT DID THE WINDOWS LEG MEASURED A GRAPH # WITH NO `[c-abi]` IN IT. openkal-llvm-runtime 0.12.0 (openkal-musl 0.16.0, # openkal 0.14.0) is the first pinned graph in which a package declares the # block, so it is the first in which mcpp realises `presents = "posix"` at all: @@ -44,7 +33,7 @@ toolchain = "llvm@22.1.8" # openkal-musl 0.16.0 and openkal-llvm-runtime 0.12.0), because a pin that # moves onto an unreachable or divergent asset fails every member at once and # reports it as a compatibility result. -mcpp = "2026.9.20.1" +mcpp = "2026.9.18.3" targets = ["x86_64-linux-gnu", "x86_64-windows-gnu"]