Files
firmware/tools
Oleksandr ShyshatskyiandClaude Opus 5 9973019ec8 A printer ships knowing where its updates come from
Phase 3 of docs/notes/85-packaging.md was three things: signing, a URL the
printer asks, and a tree at that URL. The migration landed the first. This is
the second, and the tooling for the third.

THE POINTER HAS TO SHIP BEFORE THE HOST EXISTS, which is why this lands with
nothing serving yet. A feed cannot tell a printer where the feed is: a machine
installed without etc/apk/repositories needs a USB stick before it can ever
fetch anything, which is the thing packages were adopted to stop. So the file
travels in the .tgz, naming a host that does not answer yet, and every printer
installed from today starts fetching the day one does.

The cost of that is bounded, and was read out of apk's source rather than
assumed: an unreachable repository fails `apk upgrade` and nothing else --
apk_db_repository_check is called from app_upgrade.c and not from app_add.c,
so `apk add ./file.apk` does not consult a repository at all.

    http://reforge.8941973.xyz/apk/mipsel_xburst2/anvil.adb

bin/common.sh's FEED_URL is the base, config.env can override it for a fork,
and pkgs/anvil-core generates the file from it beside the public key it
already shipped. Three things about that URL:

  * IT NAMES THE INDEX FILE, not a directory. src/repoparser.c reads a line
    ending .adb as a v3 index in place, with the packages as siblings named by
    the pkgname-spec mkndx wrote into it; anything else sends apk looking for
    <url>/<arch>/APKINDEX.tar.gz. That is the layout this repo already builds
    and the stick already uses, so the network feed is the same shape --
    exercised by every payload build rather than only in production. The v3
    directory form would work too, but only with
    `mkndx --pkgname-spec '${arch}/${name}-${version}.apk'`.

  * THE ARCH IS A DIRECTORY. Package file names carry no architecture, so two
    architectures served from one directory would be two files with one name.

  * PLAIN HTTP. libfetch defaults to SSL_VERIFY_PEER and this printer has no
    certificate bundle -- the same gap tools/python/README.md records for
    CPython. Every package is signed, and the signature rather than the
    transport is what decides whether a printer installs one.

bin/publish-feed.sh writes the matching tree and optionally rsyncs it.
Packages go first and the index last, because the index names every package by
sha256 and a mirror carrying a new index with old packages hands printers a
checksum for a file that 404s. Nothing is deleted at the far end. It refuses
an unsigned feed unless ALLOW_UNSIGNED=1: a printer verifies against the key
that shipped in its own anvil-core, so an unsigned feed is one no printer
installs from. The release workflow attaches the same tree as
reforge-apk-feed.tar.gz, so a host can be filled from any release -- including
ones tagged before the host existed -- without rebuilding.

THE REPLICA STOPPED WRITING THE FILE IT USED TO DELETE.
case-build-payload.sh wrote its own etc/apk/repositories naming /mnt and
removed it before tarring; it now passes --repositories-file with a path on
the stick, which apk reads INSTEAD of the default (database.c consults the
default file and repositories.d only when no file is named). So what ships is
whatever anvil-core installed and the build never reads it. The `apk info`
line takes the same flag: without it that one command reads the shipped file
and reaches for the network, which a build's output must not depend on.

Measured: 47 packages built from a cold cache, the payload assembled in the
replica twice, qa/static at 319 passed. Two of those are new -- the default
URL in common.sh (read from the file, not resolved, so a fork setting
FEED_URL in config.env still passes) and the built payload carrying a
package-owned entry that ends /mipsel_xburst2/anvil.adb.

What is left is operational: a host answering at $FEED_URL, and who runs
publish-feed.sh -- a release step with a deploy secret, or a person with the
tarball.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017rgrDeu9YAUuMM2G7gKTpL
2026-09-01 14:09:34 +03:00
..
2026-08-30 16:25:37 +03:00