feat(index): llamacpp b10069.1 + mcpp:plugins 0.2.1, and a CI pin that follows the engine - #359
Closed
Sunrisepeak wants to merge 3 commits into
Closed
feat(index): llamacpp b10069.1 + mcpp:plugins 0.2.1, and a CI pin that follows the engine#359Sunrisepeak wants to merge 3 commits into
Sunrisepeak wants to merge 3 commits into
Conversation
…checkpoint
A wrapper revision rather than a new checkpoint: the vendored llama.cpp is
still b10069, and `docs/upstream-update-policy.md` in that repository gives a
dotted revision to exactly this case.
What it adds is `backend-vulkan`, an additive feature over `backend-cpu`. A
consumer writes one line:
llamacpp = { version = "b10069.1", features = ["backend-vulkan"] }
and the shader compiler, the Khronos loader, the SPIR-V headers and the adapter
that lets a built artifact reach the machine's own driver all arrive with it. A
consumer that does not name the feature resolves exactly what it resolved
before -- measured in that repository: a CPU-only build writes no lock at all.
The CN mirror is published and verified byte-identical to the upstream tag
archive (36,023,391 bytes, sha256 4f30c253a700...), so the entry takes the
table form rather than the plain-string fallback this package used before.
The two workspace members move to the new version, which is what makes the
entry tested rather than merely present. Measured here:
`LLAMACPP_INDEX_TEST=PASS`.
The members were moved to b10069.1 and CI refused, correctly. Its build program
calls `mcpp::toolchain_sysroot()` and `mcpp::toolchain_binutils_dir()` (mcpp
2026.9.5.2+) to tell the shader generator's compiler where the ecosystem's C
library is; this index's CI pins 2026.8.27.2, so the build program does not
compile there:
error: 'toolchain_sysroot' is not a member of 'mcpp';
did you mean 'toolchain_dir'?
which is the diagnostic mcpp's own docs predict for this case: a qualified name
that does not exist is ill-formed rather than `false`, so no package can probe
for it, and the error names the function instead of the version.
What the index CI guarantees is what builds for users of the version it pins,
so the members stay where that guarantee holds. The new version's build is
verified where it belongs -- in llama.cpp-m's own CI, which pins 2026.9.6.2 and
runs the backend on a software Vulkan device with no GPU.
`min_mcpp` is not the lever. It states the oldest mcpp that can RESOLVE every
descriptor, and this descriptor uses no new grammar; raising it would brick
clients over a build-program API they may never reach.
`mcpp:plugins` 0.2.1 makes `mcpp.rules.sycl` name the C library. The device compiler is a second compiler: it does not inherit the toolchain the engine configured, so without `-isystem` pointing at `xim:glibc` and `xim:linux-headers` it reads the host's `/usr/include`. The rule now requires both declarations, unpinned, because the C library version is the runtime binding's choice and differs between a developer machine and a runner. The CI pin moves 2026.8.27.2 -> 2026.9.6.2. It had drifted about ten releases behind, so this index was validated against an engine no user runs. `llamacpp@b10069.1` made the drift visible rather than causing it: its build program calls `mcpp::toolchain_sysroot()` and `mcpp::toolchain_binutils_dir()` for the same reason as above, and under the old pin the workspace members could not compile it. The members build `b10069.1` again. `index.toml` min_mcpp does not move. It states the oldest mcpp able to RESOLVE every descriptor, and all 218 parse under both versions; raising it would refuse the whole index to a client on the floor over a build-program API that client may never reach. `b10069` stays published for exactly that case.
Sunrisepeak
changed the title
Member
Author
|
Restructured. The This PR keeps the two expensive halves together, because they pay the same cost once instead of twice: So it waits for mcpp 2026.9.6.3, and will then carry:
|
Sunrisepeak
marked this pull request as draft
September 6, 2026 06:06
Sunrisepeak
added a commit
that referenced
this pull request
Sep 6, 2026
The device compiler a SYCL build drives is a second compiler: it does not inherit the toolchain the engine configured, so without `-isystem` pointing at `xim:glibc` and `xim:linux-headers` it reads the host's `/usr/include`. Measured on the include search list, which is where an implicit search appears -- never on the command line. `mcpp.rules.sycl` 0.2.1 requires both declarations and refuses the build naming them when they are absent. Both are UNPINNED. The C library version is the runtime binding's choice rather than the project's -- the same tree resolves glibc 2.44 on a developer machine and 2.44.2 on a runner -- and a pinned `xpkg_dir` reference resolves for exactly that version or for nothing. Split out of #359 on purpose. That PR also moves this index's CI pin, and `validate.yml` is one of the paths that forces a FULL workspace run by design (it carries the mcpp version pins). This descriptor has no workspace member consuming it, so on its own it costs a selection that picks nothing -- and the mcpp examples that pin 0.2.1 cannot be tested until it is published. Byte-identical on both mirrors: sha256 86dcc5975f7fb17910182bc890536fa2685ef2ca947a405969bd9c74e49a48fe, 51432 bytes.
Member
Author
|
Superseded by the PR above, which carries b10069.1 and b10069.2 together with a single CI pin move to 2026.9.6.3. Splitting them would have paid the full-workspace rebuild twice. |
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
ggml-org:llamacpp@b10069.1— a wrapper revision, not a new checkpoint: thevendored llama.cpp is still
b10069, and that repository'sdocs/upstream-update-policy.mdgives a dotted revision to exactly this case.What it adds is
backend-vulkan, additive overbackend-cpu. A consumer writesone line:
and the shader compiler, the Khronos loader, the SPIR-V headers and the adapter
that lets a built artifact reach the machine's own driver arrive with it.
Additive, measured
A consumer that does not name the feature resolves exactly what it resolved
before. The criterion is not "the CPU build still works" — it is that a
CPU-only build of that package writes no lock at all, because it resolves
nothing.
Verified upstream
On a GitHub runner with no GPU, through the lavapipe payload:
The token equality is the criterion: a token merely inside the vocabulary is
produced by a backend that computed nonsense just as readily as by one that
worked, so the device decode and the host decode of one prompt must agree — and
the offload is asserted first, or two host decodes would agree trivially.
Notes
(36,023,391 bytes). This package previously had none, so the entry moves from
the plain-string form to the table form.
tested rather than merely present:
LLAMACPP_INDEX_TEST=PASS.