From 3fa87638b2ca4af23f0e589884d29c88b3c5a7de Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 9 Sep 2026 12:03:45 +0000 Subject: [PATCH 1/2] build(deps): bump dependency-submission action from v5 to v6 Closes cross-repo drift rather than chasing a new release. Dependabot opened this bump in streambuffer only (#156, merged 2026-09-09); the other three sibling repos stayed on v5 until their own weekly Dependabot run, so the four pipelines that are meant to run the same toolchain briefly did not. v6.0.0 moves the action runtime from Node 20 to Node 24 and is already proven in this workspace: streambuffer's Report job -- the job that actually runs the action, with no continue-on-error on the step -- went green on it. Workflow-file change only; no source, no dependency, no test touched. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH --- .github/workflows/publish.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index ecb95ef..032cd27 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -568,7 +568,7 @@ jobs: # Submits the dependency graph to GitHub. Informational: it says nothing about whether the # artifacts are correct, but it sits in the `report` job, which the release path needs -- so # without this flag a third-party action having a bad day can block a publish. - - uses: advanced-security/maven-dependency-submission-action@v5 + - uses: advanced-security/maven-dependency-submission-action@v6 continue-on-error: true - name: Coveralls uses: coverallsapp/github-action@v2 From a5a4328b80c7d9ff78efccd5377e5b5c34d4bab3 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 9 Sep 2026 12:06:19 +0000 Subject: [PATCH 2/2] =?UTF-8?q?docs:=20record=20that=20main=20does=20not?= =?UTF-8?q?=20build=20=E2=80=94=20llama=205.2.0=20was=20never=20released?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found during a cross-repo dependency sweep, not by CI going red — CI has been red since 2026-09-01 and nobody could see it. srcmorph/pom.xml pins 5.2.0 (5b4abeb, "pin net.ladenthin:llama to the 5.2.0 release, not the snapshot"). That release does not exist: Central's newest net.ladenthin:llama is 5.1.0 and llama-5.2.0.pom returns HTTP 404. This reactor declares no repository besides Central, so the dependency cannot resolve anywhere except a machine where an earlier `mvn install` of java-llama.cpp left 5.2.0 in ~/.m2 -- which is exactly the state a local `mvn verify` runs in, and why commit messages from that window report a green reactor build in good faith. Why it stayed invisible for eight days: every PR run since then fails at the first Maven step (run 33962068246, job 101297417993 -- "Could not find artifact net.ladenthin:llama:jar:5.2.0 in central", BUILD FAILURE after 3.35 s), but the merge commits' main runs were all cancelled by the start gate, so the repo never showed a red main and the PR failures were attributed to whatever else was in flight at the time. Recorded rather than fixed because the fix is a real decision, not a revert: 229903c raised the pin from 5.1.0 to 5.2.0-SNAPSHOT precisely because the newer binding can express flashAttn, so dropping back to 5.1.0 may not compile. java-llama.cpp's main is at 5.2.0-SNAPSHOT, so publishing that release is the likelier fix and is the owner's call. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH --- TODO.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/TODO.md b/TODO.md index ef782cf..6b8e696 100644 --- a/TODO.md +++ b/TODO.md @@ -10,6 +10,24 @@ everything below is genuinely still open. ## Open +- **`main` does not build: `net.ladenthin:llama` 5.2.0 was never released.** `srcmorph/pom.xml` + pins `5.2.0` (commit `5b4abeb`, 2026-09-01, *"pin + net.ladenthin:llama to the 5.2.0 release, not the snapshot"*), but that release does not exist: + Central's newest is `5.1.0` and `llama-5.2.0.pom` returns HTTP 404. This reactor declares no + repository besides Central, so nothing can resolve it. **Every PR run since 2026-09-01 is red** + at the first Maven step — run `33962068246`, job `101297417993`: `Could not find artifact + net.ladenthin:llama:jar:5.2.0 in central`, BUILD FAILURE after 3.35 s — while the matching `main` + runs were all `cancelled` by the start gate, so no red `main` was ever visible and the cause went + unattributed for over a week. It also passes locally on any machine where an earlier `mvn install` + of java-llama.cpp left 5.2.0 in `~/.m2`, which is why "verified locally: reactor mvn clean verify + green" appears in commit messages from that window; reproduce the real state with + `mvn -Dmaven.repo.local=/tmp/empty dependency:get -Dartifact=net.ladenthin:llama:5.2.0`. + **Reverting to `5.1.0` is not obviously correct** — `229903c` had raised the pin to + `5.2.0-SNAPSHOT` precisely because the newer binding "can express" flashAttn, so 5.1.0 may not + carry the API `LlamaCppJniConfigFactory` uses. java-llama.cpp's `main` sits at `5.2.0-SNAPSHOT`, + so publishing that release is the likelier fix. Decide which, then re-run CI to confirm — this is + the one item here that blocks everything else in the repo. + - **The sixteen GPU classifier fat jars are verified structurally, never launched.** Since 1.2.0 `.github/verify-classifier-fatjars.sh` asserts each is the artifact its name claims (one jar per classifier, a native for the promised OS/arch, a native set that differs from the default jar's, so