release-0.3.6 plan: PC 2 suite result (M30 pow-cache queue under full-suite parallelism), the two follow-up jobs, the DMG with the 0.3.5 prover

This commit is contained in:
igneum-labs 2026-10-05 09:19:14 +00:00
parent fd9c841359
commit a03d4de860

View file

@ -344,6 +344,40 @@ PC 2 has no build cache, so its zip did not need the stamp. The test stage canno
filter, so `kaspa-consensus` runs its whole suite without the feature; the feature-gated finality and difficulty runs
are the adopt agent's results in 3b. The app tests had already run on this Mac before the rule arrived (8c).
PC 2 result (`build-20261005-090600`, started 09:09:09Z, 399 s): Linux node build ok in 219 s from a cold cache
(igneumd d9d227a93148cf766969cd2856a4b73d0daa13e855f3e4d02f5b06f33fe4428e 48,733,480; igneum-miner
038fcf6b133d0af36d17e28fe822c5bcc7055429958dc280e75459c4347f9a53 9,607,440), Linux app ok in 7 s. Tests, 141 s for
the node packages: `kaspa-consensus-core`, `igneum-exec`, `kaspa-pow`, `igneum-miner` all passed; `kaspa-consensus`
92 passed, 2 failed, 3 ignored. App tests ok: 74 (main) + 25 (ota-sign) + 8 (prove-verify), 0 failed, 5 s.
| Failing test | Where | Why |
|---|---|---|
| `processes::finality::tests::frozen_table_holds_a_side_without_the_other_keys_for_one_window` | the test helper `mine`, `finality.rs:1588`: `validate_and_insert_block(...).await.unwrap()` | `PowCacheQueueFull("pow cache build queue full (4 waiting, 2 building) for epoch edc4fa84... day 1243883")` |
| `processes::finality::tests::reorg_past_an_unlocked_checkpoint_re_determines_it_and_verifies_the_pending_certificate` | the same line | the same error |
The rejection is M30's PoW cache build queue (0.3.5, fud-consensus: at most 2 caches building and 4 waiting per
process). The whole `kaspa-consensus` suite runs its tests in parallel on PC 2 and more than six of them build a
cache at the same moment; the Mac runs of 3b filtered to the finality module (8 tests) and never queued that many.
Whether it is pre-existing is being settled the way the coordinator asked: two more PC 2 jobs with
`--node-tests kaspa-consensus` and nothing else, `build-20261005-091739` on release-0.3.5 20139145
(zip `build-inputs-t035.zip` d1dd841d...) and `build-20261005-091739-036` on 2b6d23ef (`build-inputs-t036.zip`
c01a7525...), published 09:17:39Z and 09:18:06Z (the second `add` within the same second had collided with the
first's generated id; `--id` fixed it). Results: see 8i.
### 8h2. The DMG
`NODE=<fork>/target-integration/release/igneumd MINER=.../igneum-miner tools/lock/with-lock.sh build packaging/mac/build-dmg.sh`
from the worktree, 09:14 to 09:16Z: `intake key: log-intake-key.next (32 chars, fingerprint 477bb0ef)`,
`manifest: dl-token.next (11 chars, fingerprint ed9c4d2e)`, the two fingerprints the rotation plan requires. That first
DMG was 21,038,829 bytes against 0.3.5's 40,027,384: the 0.3.5 DMG (mounted read-only) ships
`igneum-prove-host` (42,095,744) and `igneum-prove-export` (2,117,456) in `Contents/Resources/bin`, which the
worktree lacks (`proving/igneum-prove/target` is not in git; the main checkout's copy is another build, 55,286,800
bytes). Shipping the Mac node without its verifier would undo 0.3.6's first item, so the two binaries were taken
from the 0.3.5 DMG itself, the files the Mac node runs today (host
4dc6b1c44ccdc83079cbcc5408f9593de9af2680992fea25a00bb58d58c26b84, export
2d1d70f9dcb7724e3e91db55be401a81df7c459b370cc0f4450b178ab7720cd0), and the DMG rebuilt with `PROVE_HOST` and
`PROVE_EXPORT` pointing at them. The ship tool's `dmg` step takes a DMG newer than the bump as built.
### 8g. The digest check (step 4)
`vendor/igneum-node/target-036/release/igneumd --devnet --override-params-file=/tmp/igneum-devnet/override-v3.json --appdir=<scratch>/digest-036/appdir --rpclisten=127.0.0.1:60985 --listen=127.0.0.1:60986 --nodnsseed --nologfiles --yes` for 20 s (08:48:06Z to 08:48:28Z, then killed; nothing else touched; the override file reads `{"difficulty_v2_activation_daa": 33000, "proving_v0_activation_daa": 84100}`):