Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
| Comment: | Add ocx2 follow: a client runs the release its server accepted
Intent: Let a person on the client make its release root run what the server accepted, the last step of the release design in ocx-rootfs/README.md, "Releasing from clients to servers", subsection "The client follows", built under ticket 8986816c0b. It follows by hand only; nothing runs it on a timer, and it starts no daemon. Expression: `ocx2 follow SERVER --root ROOT`, command line only, inside the client's root as its owner. It signs in with the daemon's own credentials for that repository (Daemon.entries) through the clone sign-in receipts already use, and asks the server's release tool for current. Already current changes nothing; the client's previous only moves the links; otherwise it fetches the listed files it lacks, checks every SHA-256 and installs with Releases.take, as accept does, before moving current and keeping previous. It holds Releases.locked, and its answer says to start `confine daemon` again. Server::Asked#release reads the release tool; a file's answer is not held to the receipt byte bound. Written by Codex in run 5f89a5934cacd4d6ac5f6d45da34778b77c8443e21e37f76b5c40c58e7743206 and reviewed against the four virtues in README.md, "Virtues Enumerated". Demonstrates: spec/ocx/follow_spec.cr shows already current with nothing changed, a move to previous without fetching, a new release fetched, checked, installed with accept's inventory and modes and served with previous kept, an accepted copy reused by its hashes, a changed byte or failed fetch leaving ROOT unchanged and naming the file, the lock held and a held lock refused, the owner-and-root rule, command line only, and no password in any answer or log; spec/ocx/command_spec.cr and spec/ocx/dry_run_spec.cr list it. `crystal run ci.cr`: 697 examples, 0 failures; coverage 100.0%. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLNdgQ5Qp4fkwUDDWT |
|---|---|
| Downloads: | Tarball | ZIP archive |
| Timelines: | family | ancestors | descendants | both | protocol-v2-daemon |
| Files: | files | file ages | folders |
| SHA3-256: |
498c3c05990cb97a6cb2950ce578ca7f |
| User & Date: | x86-1-session 2026-11-04 05:38:36.705 |
|
2026-11-04
| ||
| 14:22 |
The aarch64 node image builds with Crystal 1.19.1, as shard.yml pins it
Intent: step a of the plan agreed in thread abacbc395e (posts fb7fdaa9bf and c8ccd64f2a) for moving the aarch64-1 Docker node to protocol v2, the maintainer having asked, 2026-11-04, for "a smooth update of the ocx-node docker image". Alpine 3.23 packages Crystal 1.18.2. This branch pins 1.19.1 and uses Time.instant, which 1.18.2 lacks, so the image's `shards build` of a v2 release fails. Precept I3's pin is met in the image, not worked around. Expression: ocx-node/Dockerfile no longer installs Alpine's crystal and shards. It fetches Crystal 1.19.1's official linux-aarch64 tarball, checks it against its SHA-256 (e4bfc97d18fa1c055df949b2d8c4ae9e4e8fe517da2dea536cff3992ec34f7a3, both as build arguments), unpacks it into /usr/local/lib/crystal, and installs /usr/local/bin/crystal as a two-line wrapper that sets CRYSTAL_LIBRARY_PATH=/usr/lib, plus a shards link. The tarball's bundled libgc.a fails to link on musl ("undefined reference to __pthread_unregister_cancel"), so the wrapper links gc-dev's libgc. The build stops unless `crystal --version` says 1.19.1. /usr/local lies under /usr, which run sandboxes see read-only, so runs on the node get the same compiler. Demonstrates: there is no container runtime in this session, so the image itself was not built. Each step of the new RUN was run on aarch64-1's container, an Alpine musl host: the download's sha256sum -c printed OK; the wrapper's version check passed; `shards build ocx2`, then `serve` and `confine`, built from this check-in's parent. `crystal run ci.cr` with the same tarball and wrapper: 697 examples, 0 failures, 0 errors, coverage held. The result line was "FAIL: CI took 183 s, over its limit of 180 s", 3 s over the pace limit, on a host with a load average near 8. That is not this change, which touches no Crystal. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLpFJamQoSGA4uyiGS check-in: 9528b053d2 user: aarch64-1-ollama-session tags: protocol-v2-daemon | |
| 05:38 |
Add ocx2 follow: a client runs the release its server accepted
Intent: Let a person on the client make its release root run what the server accepted, the last step of the release design in ocx-rootfs/README.md, "Releasing from clients to servers", subsection "The client follows", built under ticket 8986816c0b. It follows by hand only; nothing runs it on a timer, and it starts no daemon. Expression: `ocx2 follow SERVER --root ROOT`, command line only, inside the client's root as its owner. It signs in with the daemon's own credentials for that repository (Daemon.entries) through the clone sign-in receipts already use, and asks the server's release tool for current. Already current changes nothing; the client's previous only moves the links; otherwise it fetches the listed files it lacks, checks every SHA-256 and installs with Releases.take, as accept does, before moving current and keeping previous. It holds Releases.locked, and its answer says to start `confine daemon` again. Server::Asked#release reads the release tool; a file's answer is not held to the receipt byte bound. Written by Codex in run 5f89a5934cacd4d6ac5f6d45da34778b77c8443e21e37f76b5c40c58e7743206 and reviewed against the four virtues in README.md, "Virtues Enumerated". Demonstrates: spec/ocx/follow_spec.cr shows already current with nothing changed, a move to previous without fetching, a new release fetched, checked, installed with accept's inventory and modes and served with previous kept, an accepted copy reused by its hashes, a changed byte or failed fetch leaving ROOT unchanged and naming the file, the lock held and a held lock refused, the owner-and-root rule, command line only, and no password in any answer or log; spec/ocx/command_spec.cr and spec/ocx/dry_run_spec.cr list it. `crystal run ci.cr`: 697 examples, 0 failures; coverage 100.0%. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLNdgQ5Qp4fkwUDDWT check-in: 498c3c0599 user: x86-1-session tags: protocol-v2-daemon | |
| 04:07 |
Release work holds no record beside the repositories, and says what import requires
Intent: the maintainer, at aarch64-1's terminal, 2026-11-04: "runs.json and import.json both sound superfluous to a directory full of .fossil databases." Under virtue 4 (Parsimony) and precept C2 (Single Owner), the release root keeps no copy of what the run's record already holds; under virtue 1 (Clarity), a sender is told what import requires before a build is wasted. ocx-arm's review on aarch64-1 (thread abacbc395e, posts bf4905c000 to ce7941874e) found the rest. Expression: import.json is gone: import no longer writes it, accept no longer carries it, and the release tool's answer is each release's name and its listed files with their SHA-256, without the checkin field that only repeated the name or the record that repeated import.json. patterns/stage.md and USAGE.md say --of must be the check-in's full hash, which import requires; stage.md says import is ocx2 import RUN; USAGE.md says to remove staged/NAME by hand if import stops after copying; ocx-rootfs/README.md names the stage pattern by its SHA3-256; create.cr's comment cites section 2.7. spec/ocx/care_spec.cr's wait for a child to end treats a failed read of its vanished /proc stat as ended, rescuing IO::Error, which aarch64-1 raised, where Codex's version rescued only File::Error; that one word is mine. patterns/stage.md's sha3 is now ebf7864f387a2153035a92f04d4365f9f650b60f25c04a778865ed59430cd5f0. Codex wrote the rest as task 68afc3e8af on x86-1; I reviewed it. Demonstrates: spec/ocx/release_import_spec.cr and spec/ocx/release_read_spec.cr assert no import.json and the shorter answer. The patch's SHA-256 is 28a6aba4aa27173d7ddce8abeb47c8d5b13d191815b06de907d978d8e46bf592, as the task's ended records. crystal run ci.cr here: green, 686 examples, 0 failures; coverage 100.0%; 2 executables build. The run before it failed once in spec/ocx/message_tags_spec.cr on Fossil's "database is locked" while posting (ticket 00817df826), which this change does not touch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TUH8KLNdgQ5Qp4fkwUDDWT check-in: 384b909ae6 user: x86-1-session tags: protocol-v2-daemon | |