Repin GLM-5-Next to the commit that merges cleanly

[danielhanchen]

Repin ggml-org/llama.cpp#27754 (GLM-5-Next) from 629b5055 to b9b8207f.

Why

The nightly has failed two nights running, 34063080108 (Sep 6) and 33994788048 (Sep 5), both in Resolve tag:

ggml-org/llama.cpp#27754 (629b50552801912b3e2078f9799e4d77213197d7) does not merge
cleanly onto b10825 + the PRs listed before it; reorder or drop it in
scripts/unsloth/pr-set.json

Nothing has published since, which now also blocks the Authenticode signing from #204 from ever reaching a release.

The error suggests reordering, but that cannot work here: I checked, and 629b5055 conflicts against a bare b10825 with no other pins applied at all, producing the same two files. It is a base conflict, not an ordering one.

additive_merge.py was right to refuse. Both conflicts have a non-empty merge base, meaning each side edited an existing line, which the script never resolves by design:

base:   if (arch == LLM_ARCH_DEEPSEEK4 || (arch == LLM_ARCH_DFLASH && ...)) {
ours:   ... || arch == LLM_ARCH_HY_V4) {
theirs: ... || arch == LLM_ARCH_GLM5NEXT || ...) {

In this instance the union is unambiguous: it is a boolean disjunction and each side added one architecture. That is a human call, not something the script should be taught to guess, so the fix belongs in the PR rather than in additive_merge.py.

What changed upstream

b9b8207f ("Fix merge conflicts") merges current master into the PR branch with both conflicts resolved as the union. ggml-org#27754 has gone from CONFLICTING to MERGEABLE.

One detail worth recording, because it is the part that was easy to get wrong: llama-graph.cpp has two call sites and they are not symmetric. The base carries HY_V4 at the second site only, and the PR adds GLM5NEXT at both. So only the second site takes the union; the first merges automatically and correctly ends up with GLM5NEXT and no HY_V4. Propagating HY_V4 to both to make them look consistent would have introduced behaviour the base never had.

Verification

Against the resolved tree:

• libllama.so and llama-common build clean
• test-llama-archs builds and exits 0
• no conflict markers anywhere in the tree

Caveat, stated rather than glossed: my local replay of the full 13-pin set diverges from CI at #25731 (I hit AUTHORS and .github/workflows/* conflicts that CI does not), so I have proven this fix against the base and against master, but not that the complete pin set now merges end to end. The first nightly after this merges is what settles that.

Upstream CI is running on b9b8207f now. Worth waiting for it to go green before merging this, since the pin is only as good as that commit.

[chatgpt-codex-connector]

You have reached your Codex usage limits for security reviews. Please try again later.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-07T08:24:17.729558Z	15fe677	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.