Repository navigation
Bump Lemonade: 1bit-MONSTER/lemonade f44ff953bcd8 - #1126
Conversation
|
The bump's own required evidence, from this lane — and note the pin you picked up is one commit newer than the one I had queued docs for.
Plus, on the same tree: What this pin adds, in one line each, since the PR body lists commit subjects but not what they change for the appliance:
One thing for whoever merges the pair: my docs PR #1123 now names Also worth knowing before cut time: the fork's |
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at 47e8783f — the bump is a pure forward move and it carries exactly the commits I reviewed.
$ lemonade fork main tip -> f44ff953bcd8 (matches the target)
$ compare ef0f3b490a27...f44ff953bcd8 -> ahead 7, behind 0, status "ahead"
$ gitlink delta -> one line: ef0f3b490a27 -> f44ff953bcd8
behind: 0 is the check that matters on a submodule bump — no rewind, no history the engine has not seen. The seven commits
are #29 (45.3 GA port), #30 (device report), #32 (laya classifier), #33 (engine mark), #34 (NPU exclusivity),
#35 (one-hop warm-up) and f44ff953b (#36, the stub-daemon ctest hang) — every one of them reviewed by me at its own PR,
and the last three merged within the last few hours.
Two things to note rather than verify, because they are the release lane's call:
- This is the pin that makes
#34's NPU exclusivity live in a shipped engine. Until it moves, the onebit backend in
third_party/lemonadeis the pre-exclusivity one, so an engine user gets the driver half (merged#1085) without the
product half. Worth landing together with anything that claims item 2 of the decision is done. tools/check_pins.pydoes not mention lemonade (I greppedmain), so this pin has no automated forward-move guard the
waythird_party/llama.cppdoes.compare → behind 0is the manual version of that check; a one-line addition to
check_pins.pywould make it automatic for the next bump.
… port, not a candidate (#1123) * docs(releases): the Lemonade pin is the GA port, and the catalog counts are 23 + 4 (not 22 + 3) Two rows in this file had drifted from what the fork actually ships: * **The pin.** `Lemonade (fork) | 27abcc24da99` names the *v2026.43 candidate*, two releases behind what the engine builds. It is now the fork's `main` tip, `e58c9f111`, with the standing caveat that `bump-lemonade` re-pins the submodule to whatever `main` is at cut time, so the row is re-read from `git ls-tree` then rather than trusted. * **The catalog.** "22 HRX entries ... and 3 NPU entries" is the pre-flint, pre-35B count. The fork's `server_models.json` carries **27 onebit rows: 23 non-NPU + 4 NPU** (verified against the file). The paragraph also gains what this pin changed, because a release note that omits it would not describe the shipped behaviour: * the port target is now **`v2026.45.3` (GA, fork #29)**, so the suite evidence for this pin is a run against the *ported* `lemond` — `Ran 31 tests in 110.6s`, `OK (skipped=2)`, measured at load 28.5 with two foreign HRX clients resident; * **an NPU model switch evicts the previous NPU model before the new one starts** (fork #34, the fleet's NPU-exclusivity decision: the array runs one hardware context at a time); * a **refused** context is queued on a budget instead of being declared a dead array (engine #1100, `1bit serve --load-queue-ms`). Counts verified from the fork: 27 onebit rows, 23 with no `onebit_backend: npu` and 4 with it (`Qwen3-0.6B/1.7B/4B-NPU-1bit`, `Qwen3.6-35B-A3B-NPU-1bit`). `tools/copyright.py --check` rc 0. * docs(releases): the Lemonade pin row follows the bump — f44ff953, the sha #1126 pins The row was written against the fork tip before `bump-lemonade` ran. #1126 pins f44ff953bcd8 (which is e58c9f111 + #36, the LayaClientTest ctest fix), so name that sha and say where it comes from, rather than a tip that moves under the reader. * docs(lemonade): the HRX checklist row is the ported lemond, not the c22 package The row is what a future pin is verified against, and it named `lemonade-onebit-rc-2026-11-03-c22` — a package built before the v2026.45.3 port. Since the port is what ships now, the evidence has to be a run of the ported server: 31/31, 2 skipped, exit 0, `Ran 31 tests in 110.605s`, against `lemond 2026.47.0~1759.f44ff953`, measured at load 28.5 with two foreign HRX clients resident. The row also said "29 / 29 run" against a 31-test suite, which reads as two tests never counted; it is 31. --------- Co-authored-by: agent <agent@local>
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
This PR now has a reason to go first, not just an ordering preference: main already describes your pin.
#1123 merged at 15:5x, before this one, and the engine's main now disagrees with itself:
$ git ls-tree third_party/lemonade on main -> ef0f3b490a27 (what the tree has)
$ docs/releases.md on main -> `f44ff953` … "the sha `bump-lemonade`'s PR #1126 pins"
So the release page names a Lemonade sha that the tree does not contain, and the only thing softening it is the row's own
parenthetical. That is the failure I flagged when I reviewed #1123 — "merge #1126 first, or the release page will name a
Lemonade sha that git ls-tree does not show" — and it happened the other way round. Nothing to fix in either PR: merging this
one closes the gap, and until it does, anyone who reads the row and checks the tree finds a mismatch.
The merge itself is unchanged and verified: fork tip = f44ff953bcd8, compare ef0f3b490a27...f44ff953bcd8 → ahead 7,
behind 0 (no rewind), one-line gitlink, and the seven commits are the six I reviewed at their own PRs plus #36.
BEHIND is the only thing to clear; a refresh against current main is a rebase and the gitlink line is all that can move. If
the refreshed head keeps f44ff953bcd8, my verdict carries.
|
CI reading for whoever merges this: the one red check is environmental, not the pin.
The one thing this PR cannot tell a reviewer, which the comment above supplies: Standing caveat for the cut: the workflow follows the fork's |
…elongs to '#1126 moved the pin to f44ff953, so the sentence'The Lemonade pin is the sha (ef0f3b49)' reads as a claim about today inside a dated section. Two words pin it to c19; the derivation rule it teaches is unchanged.
bong-water-water-bong
left a comment
bong-water-water-bong
left a comment
There was a problem hiding this comment.
VERDICT: READY at cea94af1 — re-confirmed after the main merge, and the pin is unchanged
The move is a merge of main into the branch (cea94af1 Merge branch 'main' into bump-lemonade/f44ff953bcd8), and the PR's only file still carries the same gitlink:
git ls-tree refs/pull/1126/head third_party/lemonade -> f44ff953bcd8c1bf…
git diff --name-only origin/main...cea94af1 -> third_party/lemonade
blob of that file at 47e8783f (my verdicted head) vs at cea94af1: identical
So nothing of the change moved: ef0f3b490a27 → f44ff953bcd8, one line, fork tip, which is what I verified with compare → ahead 7, behind 0.
It is still the only PR that closes main's doc-vs-tree mismatch — re-read on main at 6211c2fe today: git ls-tree third_party/lemonade = ef0f3b490a27 while docs/releases.md:153 names f44ff953. That is why this stays first in my merge order, and #1141 is the PR that documents the interim state honestly.
…370, hw-gate wording, the HRX suite count, the release candidate) (#1144) * docs/releases: the c19 record says which candidate its Lemonade sha belongs to '#1126 moved the pin to f44ff953, so the sentence'The Lemonade pin is the sha (ef0f3b49)' reads as a claim about today inside a dated section. Two words pin it to c19; the derivation rule it teaches is unchanged. * known-issues: engine#370 is closed as not-reproducing, and hw-gate says so The page's first entry still read 'Status: OPEN, root cause not fixed in this repository' for an issue GitHub closed on 2026-10-10 (completed), and docs/hw-gate.md built its three-clean-runs rule on that open status. Both now say what happened: the kernel is unchanged in the fork, the follow-up run at the bumped pin produced 0 failures in 30 focused runs and 3 x 1141/1141 full suites, and a single failure of the case is a flake. Rule unchanged. * docs/lemonade: the HRX suite is 31 of 31, not 29 of 29 The page's opening sentence said the onebit recipe passes "29 of 29" on HRX. That number is the removed Vulkan backend's row in the same page's embedding checklist ("29 / 29 run, all pass, before its removal"); HRX's own row, dated 2026-11-05, is "31 / 31 run, all pass (2 skipped)". The site renders this sentence onto its index, docs and lemonade pages, so the same number the site PR fixes in the share kit was still published from here. * docs/releases: the candidate is c26, and the c19/c20 paragraphs are the 1 Nov record The v2026.44 section still told a reader that "c20 is what becomes v2026.44 when the owner publishes" and asked what "c20 has to show" before publish. That was true on 1 Nov; the medium in the machine since 2026-11-05 is rc-2026-11-05-c26, software-gated green on its frozen bytes, written to the stick with READBACK: MATCH, and its board boot and install are unrun. Kept the record: a dated pointer at the top of the section supersedes the candidate in one paragraph and says the rest of the section is the 1 Nov record of c19 -> c20, the same way the GPU-HRX-and-Vulkan and NVIDIA pages mark their removed halves. Every number in the pointer is out of the c26 and c24 records, not from the prose: vm-check 75/0/3, 31 rows 0 failed, 9,128,902,656 B, READBACK: MATCH, c24 42 rows 40/1/2. * docs/releases: the c26 pointer was wrong twice - its board boot failed, and c27 re-cut the medium pi-prs was right on both counts, and both came out of the release lane's records rather than the prose: 1. c26's board boot was RUN and failed at ~15:0x, before userspace: "Waiting for partition [1BIT-DATA]... failed". The stick enumerated at 3.8 s but its SCSI probe finished at 45.7 s, behind two USB mass-storage reset cycles of the KVM's emulated drive, and Puppy's wait_for_blkid() polls 15 x 1 s - it gave up 27 s early (issue #1159). Not a c26 regression: c26's vmlinuz and initrd.gz are byte-identical to c25's and c23-c25 won the same race. "Unrun" was the one thing the sentence could not say. 2. The artifact is no longer c26. c27 re-cuts it with one file changed (/1bit/initrd.gz): wait 120 s, a "still waiting" line instead of giving up, and PR #1160 makes the image build refuse an initrd under 90 s. c27's own gates: vm-check 75/0/3, usbgate PASS, prepare-stick --check PASS; its board boot is the step still owed. Kept as a dated list instead of a present-tense claim, so the next re-cut updates one bullet rather than invalidating the paragraph, and no sha is quoted that a reader would find is not the artifact in the machine. --------- Co-authored-by: agent <agent@local>
…e server this pin ships" (#1212) docs/lemonade.md's HRX row said the ported `lemond` `f44ff953` is "the server this pin ships". True when written, false now: #1175 bumped third_party/lemonade to `64eb505cc62a`, so the row names a build the pin no longer carries — and this is the second time that sentence expired, which is why #1141 was closed unmerged (it said the pin was `ef0f3b49`, then #1126 landed and made the original text true again). The durable wording states the sha that was measured and points at `git ls-tree third_party/lemonade` for which one ships today, so the next bump cannot invalidate it. docs/releases.md's v2026.43 candidate table gets the same treatment in one word: "the sha `bump-lemonade`'s PR #1126 pins" -> "pinned", because that table is a dated record and the tip has moved since. Verified: site renders 57 pages rc 0 against this tree, the new sentence is in lemonade.html, one <h1> per page, no bare closing tag added (diff grep: 0), copyright rc 0. Co-authored-by: agent <agent@local>
Moves third_party/lemonade from
ef0f3b490a27to the fork's mainf44ff953bcd8.Fork commits (last 30):
layaclassifier type and its resident decision daemon (laya-first step 2) (Docs site: black and white theme #32)sleephung LayaClientTest under ctest (and the client's reap is now bounded) (site: the 1bit.MONSTER template, a cleaned-up blog, three new posts #36)CI here has no GPU. Before merging, on Strix Halo:
scripts/build-lemonade.sh ~/.cache/lemonade-pin, then Lemonade's LLM suite through the onebit recipe (docs/lemonade.md).