Repository navigation
Pin llama.cpp by number with a commit override; bump to b11632 and drop patch 0012 - #537
Merged
Merged
Conversation
Five upstream commits: four Vulkan (bf16 mulmat activations, Intel Arc shader count, the Intel Windows free-memory workaround, a compile fix) and #30480, which hands the k-pool selection of glm5-next / qwen4exp to the attention in the mask layout. No patch-target file in the range; all thirteen patches apply unchanged, ctest 608/608, the model-free native Java tests 27/27 over the b11617 library. No project source change. The 0012 drop rule now keys on the fixing commit (df18bee11 / #29677) rather than on "past b11612": b11617 is past b11612 and still lacks the fix, and no tag up to b11618 carries it. Patch header, test header, CLAUDE.md row and the TODO.md section say so. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017kVXQfPe1ACLAuk29Y4d2H
…m has not tagged yet The pin is set(JLLAMA_GIT_TAG b<nnnn>) now, and everything that names the version keeps reading the number: jllama-build.txt, LlamaCppVersion, the README badge, the WebUI job, llama-next-version.sh. A number upstream has not tagged yet -- the tags trail master, and a fix worth bumping to can sit in between -- is pinned the same way plus set(JLLAMA_GIT_COMMIT "<hash>"), the master commit the number names. Only the two fetches read the hash (FetchContent and the build-webui checkout); the configure then asserts that the fetched commit's `git rev-list --count` is the number, which is upstream's own tag-numbering rule and also how llama.cpp's build-info derives b<nnnn>-<commit>, so the Java pin check holds against a virtual number unchanged. llama-next-version.sh resolves a number to its hash (--resolve b<nnnn>), accepts a virtual current pin, and says when JLLAMA_GIT_COMMIT is stale because the tag has been published. Measured on three configures: fetched by tag (count 11617 = b11617), fetched by b11617's commit with JLLAMA_GIT_COMMIT set (same), and fetched by b11618's commit under JLLAMA_GIT_TAG b11617, which the pin check refuses naming the number the hash really is. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017kVXQfPe1ACLAuk29Y4d2H
b11632 is master's head of 2026-10-14 (62df1815b), pinned ahead of the tag: JLLAMA_GIT_TAG b11632 with JLLAMA_GIT_COMMIT naming the commit, the first use of the virtual-number pin. Upstream merged the zero-split-sum fallback as ggml-org/llama.cpp#29677 (df18bee11, b11626) on the way; patch 0012 stops applying exactly there -- upstream's line is inside the block it replaced -- so it is dropped, not refreshed, and its runnable guard test_model_split.cpp goes with it: the two functions it linked existed only through the patch, the fixed line sits in a member function with no seam, and the end-to-end route needs two GPU-type devices, which a GPU-less runner cannot provide in one process. The drop note in docs/history/dropped-llama-patches.md records all of that. The other twelve patches apply unchanged at 62df1815b. Besides the fix: cpp-httplib 0.61.0, the RPC transfer logs, --spec-draft-n-ubatch (a new speculative field, not exposed yet), a conv_1d layout fix and a CUDA GDN kernel. Through the production path (FetchContent by commit, the applier, the pin check reporting count 11632 = b11632): ctest 601/601, the model-free native Java tests 27/27 against the linked b11632-62df1815b. Clear JLLAMA_GIT_COMMIT once upstream tags b11632. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017kVXQfPe1ACLAuk29Y4d2H
bernardladenthin
had a problem deploying
to
maven-central
October 14, 2026 14:27 — with 
GitHub Actions
Failure
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
maven-central
October 14, 2026 14:27 — with
GitHub Actions
Failure
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
startgate
October 14, 2026 14:27 — with
GitHub Actions
Error
GitHub Actions
Error
|
8 of 10 tasks
This branch had an error being deployed
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
2 participants
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.
Summary
set(JLLAMA_GIT_TAG b<nnnn>)now, plus an optionalset(JLLAMA_GIT_COMMIT "<hash>")for a number upstream has not tagged yet. Only the two fetches read the hash (FetchContent, thebuild-webuicheckout);jllama-build.txt, the loader,LlamaCppVersion, README and docs keep the number, and the configure asserts that the fetched commit'sgit rev-list --countis the number (upstream's own tag-numbering rule, and how llama.cpp'sbuild-infoderivesb<nnnn>-<commit>, so the Java pin check holds unchanged).llama-next-version.sh --resolve b<nnnn>prints the hash, the helper accepts a virtual current pin and says whenJLLAMA_GIT_COMMITis stale. Measured on three configures: by tag, by the matching commit, and by a wrong commit, which the pin check refuses naming the number the hash really is.62df1815b) pinned through its commit ahead of the tag, the first use of the mechanism. All twelve remaining patches apply unchanged; the range brings cpp-httplib 0.61.0, the RPC transfer logs,--spec-draft-n-ubatch(not exposed yet), a conv_1d layout fix and a CUDA GDN kernel.0012dropped (thirteen → twelve): upstream merged the zero-split-sum fallback as model: fix "invalid vector subscript" when loading on a full GPU ggml-org/llama.cpp#29677 (df18bee11, b11626). The patch stops applying exactly there, so the drop was forced, not silent. Its guardtest_model_split.cppgoes with it: the two functions it linked existed only through the patch, the fixed line sits in a member function with no seam, and the end-to-end route needs two GPU-type devices, which a GPU-less runner cannot provide in one process (0015's server state is global). Recorded indocs/history/dropped-llama-patches.md.Test plan
11632 = b11632) ctest 601/601 (608 minus the seven oftest_model_split.cpp) and the model-free native Java tests 27/27 against the linkedb11632-62df1815b;check-patches.py12/95/0,check-natives.py,check-run-scripts.py, the buildcheck unit tests and spotless clean0012, TODO.md,llama-cpp-breaking-changes.mdrowsRelated issues / PRs
Follows #536 (b11612). Upstream: ggml-org/llama.cpp#29677 (
df18bee11). Once upstream tags b11632, clearJLLAMA_GIT_COMMIT; nothing else moves.Checklist
CONTRIBUTING.mdandCODE_OF_CONDUCT.mdSECURITY.md)🤖 Generated with Claude Code
https://claude.ai/code/session_017kVXQfPe1ACLAuk29Y4d2H
Generated by Claude Code