Skip to content

Prebuilt: repin Inkling after merging b10229 into the branch - #50

Merged
danielhanchen merged 1 commit into
masterfrom
prebuilt-repin-inkling-b10229
Aug 3, 2026
Merged

Prebuilt: repin Inkling after merging b10229 into the branch#50
danielhanchen merged 1 commit into
masterfrom
prebuilt-repin-inkling-b10229

Conversation

@danielhanchen

Copy link
Copy Markdown
Member

Last night's schedule (30767267935) failed in Resolve tag:

ggml-org/llama.cpp#25731 (02142bbc33d477880a89dc5854a2c611d36e3494) does not merge
cleanly onto b10229 + the PRs listed before it; reorder or drop it in
scripts/unsloth/pr-set.json

This is not the pin rot that broke 07-31 and 08-01. All four pins passed the membership gate this time, and each was still at its PR head. Straightforward upstream drift instead.

Cause

Between b10226 and b10229, upstream added LLM_ARCH_DEEPSEEK4 to the same fallthrough group in src/llama-arch.cpp that Inkling registers in:

        case LLM_ARCH_QWEN35:
        case LLM_ARCH_QWEN35MOE:
<<<<<<< HEAD
        case LLM_ARCH_INKLING:
=======
        case LLM_ARCH_DEEPSEEK4:
>>>>>>> b10229
            return true;

The resolver merges pins onto the base tag and has no conflict resolution, so it refused. b10225-mix-345e1e3 published fine yesterday because the base was b10225, before DEEPSEEK4 landed.

Fix

Resolved on the branch, not here. b10229 is merged into add-inkling and both cases are kept, since both arches belong in that group. That is the last-writer problem this repo keeps hitting: whoever merges second has to know about the first.

The pin moves 02142bbc -> 1e6f9e4a. Nothing else changes:

PR pin change
ggml-org#24423 DiffusionGemma c3fb9724 unchanged
ggml-org#25731 Inkling 1e6f9e4a was 02142bbc
#48 Kimi-K3 fixes + MoonViT-3d daef2b3e unchanged
ggml-org#26185 Kimi-K3 text 04d6828b unchanged

#48 needed nothing. It already carries b10223, and DEEPSEEK4 does not land anywhere Kimi-K3 registers.

Side benefit: ggml-org#25731's own mergeable state against master had gone red for exactly this conflict. It is back to true.

Verification

Replayed the resolver's merge sequence against b10229:

OK   c3fb972412  (24423)
OK   1e6f9e4a59  (25731, new pin)
OK   daef2b3e1b  (48)
OK   04d6828b2b  (26185)   <- still a no-op
UNMERGED PATHS: 0

Merged tree builds clean with -DGGML_CUDA=ON -DLLAMA_BUILD_TESTS=ON. test-chat passes; test-llama-archs -a kimi-k3 is OK on CUDA and CPU (NMSE 8.77e-08).

The new Inkling head also merge-trees clean against upstream master, which is six commits past b10229, so tonight's tag should resolve without another repin.

The 2026-08-02 schedule (run 30767267935) failed in resolve:

  ggml-org#25731 (02142bb) does not merge cleanly onto b10229
  + the PRs listed before it

Not the pin rot that broke the previous two nights -- all four pins
passed the membership gate this time. Upstream added LLM_ARCH_DEEPSEEK4
to the same fallthrough group in src/llama-arch.cpp that Inkling
registers in, between b10226 and b10229, and the resolver has no
conflict resolution.

Fixed on the branch rather than here: b10229 is merged into add-inkling
and both cases are kept, since both arches belong in that group. That
also clears ggml-org#25731's own mergeable state against master, which
had gone red for the same reason.

No other pin moves. #48 needed nothing -- it already carries
b10223 and the new arch does not collide with Kimi-K3.

Verified against b10229: the four merge in order with zero unmerged
paths, and the merged tree builds with -DGGML_CUDA=ON. test-chat passes
and test-llama-archs -a kimi-k3 is OK on CUDA and CPU (NMSE 8.77e-08).
The new Inkling head also merge-tree's clean against upstream master,
which is six commits past b10229, so the next tag should resolve too.
@danielhanchen
danielhanchen merged commit a070fb4 into master Aug 3, 2026
2 checks passed
@danielhanchen
danielhanchen deleted the prebuilt-repin-inkling-b10229 branch August 3, 2026 07:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant