max / alloy

docs: correct Phase 0's stale and mis-measured statements Works alloy ecbe8d2b. Three of its four corrections land; the fourth does not survive checking and is argued below. 0.1 says rsync and minisign are open blockers. Both landed in the base block in b4fb21c on 2026-08-20, the same day the probe was taken. The section says so now, and says the other four were re-probed on 08-21 so nobody has to guess which dates are current. The PostgreSQL entry's premise is withdrawn. It treated a Fedora default of 18.4 against a fleet on 16 as the problem. Fedora 43 carries postgresql16 and postgresql16-server at 16.14-1.fc43, and production is 16.14, so the image can match prod to the patch release and there is no version problem. What is left is naming the versioned package instead of the unversioned one. patchelf is struck. It was a reading off cargo-tauri's downloader strings, and running it disproves it: linuxdeploy carries its own patchelf inside its AppImage and resolves it from the extracted AppDir, and the gtk plugin never calls it at all. Neither the image nor a container needs it. The fetch fragility that finding also raised is real and lives on infra 83ee4a38. NOT MADE: the task's third correction, which says the scratch restore is TCP rather than a unix socket and that the runbook is wrong to say socket. The runbook is right. That correction was read off the in-repo template, MNW/sando/daemon/sando-daemon.toml:22, which is postgres://sando@127.0.0.1. The gate runs against the deployed file, /etc/sando/sando-daemon.toml:26, which is host=/var/run/postgresql. The two disagree, and the deployed one wins. The distinction is not pedantic: it decides whether the image needs a local server or only a client, and the template reading sizes it as client-only. Recorded in the section so the next pass does not repeat it. Also carried from the earlier commit in this session: the postgres paragraph keeps the measured prod version, and the withdrawn framing is marked withdrawn rather than deleted. No code changed. Nothing pushed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-08-21 18:46 UTC

Signed with PGP, not checked

Commit: 7f82670bbd8b0fff6da81a59af6955e521c13ef6

Parent: 5edae13

1 file changed, +15 insertions, -3 deletions

M docs/MIGRATION-FW13.md +15 -3

			@@ -44,6 +44,12 @@
44	44
45	45		Probed against the built image on 2026-08-20. Each of these stops the build-host role dead, not merely degrades it.
46	46
	47	+	Two of the six are closed. rsync and minisign both landed in the base package block in
	48	+	`alloy@b4fb21c` on 2026-08-20, the same day the probe above was taken, so the probe was simply
	49	+	earlier than the fix. The base `RUN` opens at `Containerfile:1137` and both words sit inside it.
	50	+	Their entries stay below because the reasoning is worth keeping; read them as history, not as work.
	51	+	Four blockers remain open, and all four were re-probed on 2026-08-21.
	52	+
47	53		rsync is absent from both profiles. `ops-exec` spawns the `rsync` binary directly for every push and pull, and bentod, the bento driver and sandod all link it. Without it, every Bento collect from astra, mbp and windows-x86 fails and Sando's release handoff fails. This is the control plane, not a build tool: fw13 stops being able to act as a controller at all, whether or not it can compile anything. Mechanical fix, one word in the base package block. Fedora 43 carries 3.4.4.
48	54
49	55		minisign is absent. Both Linux release recipes call `dist/sign-artifacts.sh`, which hard-fails when minisign is not on PATH, and the recipe step aborts the run. Mechanical fix, one word in the base package block. Fedora 43 carries 0.12. Base rather than client: signing is a build-host act.
			@@ -52,9 +58,13 @@
52	58
53	59		node and npm are absent, and no `LANGS` value supplies them. Sando's `code_smoke` gate builds two frontends with `npm run build` before it creates a database or boots anything, and the config text says outright that this is the one place a frontend failure is fatal. It is fatal there because the MNW server's `build.rs` deliberately is not: with no node it emits a warning and lets the Rust build succeed against whatever `static/dist/` already holds, which would silently ship the previous build's JavaScript. The `LANGS` validator accepts only rust, go, python and zig, so this is not a mint-time flag away.
54	60
55		-	No PostgreSQL server or client, and the versions do not match. Sando's `migration_dry_run` and `cargo_test` gates restore prod dumps into a local scratch cluster over the unix socket. Alloy ships neither the server nor `psql`. Two problems, not one: the package is absent, and Fedora 43 offers 18.4 while fw13 and astra both run 16. A PG18 scratch cluster stops testing MNW against the version production runs, which is most of what the gate is for.
	61	+	No PostgreSQL server or client. Sando's `migration_dry_run` and `cargo_test` gates restore prod dumps into a local scratch cluster over the unix socket. Alloy ships neither the server nor `psql`.
56	62
57		-	Prod is confirmed, measured 2026-08-21 over `tailscale ssh root@alpha-west-1`: PostgreSQL 16.14 on Ubuntu 24.04.4 LTS, one cluster, client and server both 16.14. fw13 is 16.14 and astra 16.13, so all three hosts sit on 16 today and the fleet is uniform. That sizes the mismatch at two majors rather than at some unknown, and it means the gate's value is specific: it is the only place MNW's migrations meet the version prod will actually apply them on. Whatever answer 0.2 reaches has to keep a 16 available to the gate, whether that is a versioned Fedora package, a container, or the gate running somewhere other than fw13.
	63	+	This entry used to say "and the versions do not match", and treated a Fedora 43 default of 18.4 against a fleet on 16 as the real problem. That framing is wrong and is withdrawn. Fedora 43 carries versioned packages: `postgresql16` and `postgresql16-server`, both `16.14-1.fc43` in `updates`, measured with `dnf -q list --available 'postgresql16*'` inside `localhost/alloy:clip-client`. Production is 16.14, measured 2026-08-21 over `tailscale ssh root@alpha-west-1` on Ubuntu 24.04.4 LTS with one cluster, and fw13 is 16.14 with astra on 16.13. So the image can carry production's exact version to the patch release, and there is no version problem to solve. What is left is the ordinary one: name `postgresql16-server` rather than the unversioned `postgresql-server`, which is what would have pulled 18.
	64	+
	65	+	The dial that carries it is a separate call and is not this file's to make: alloy `f22b8939` decides it and alloy `7e57479e` installs on whatever it picks.
	66	+
	67	+	One thing to get right when that lands. The restore really does go over a unix socket, and the two Sando configs disagree about it. The deployed `/etc/sando/sando-daemon.toml:26` is `postgres:///sando_scratch?host=/var/run/postgresql&user=sando`, while the in-repo template at `MNW/sando/daemon/sando-daemon.toml:22` is `postgres://sando@127.0.0.1/sando_scratch`. The deployed file is what the gate runs against, so the image needs a local server with a socket at `/var/run/postgresql`, not merely a client that can reach a port. Reading the template instead of the deployed file is how this gets sized as a client-only problem.
58	68
59	69		The Tauri Linux build environment is absent. goingson and balanced_breakfast release through `cargo tauri build`, which needs webkit2gtk-4.1, gtk3, libsoup3 and javascriptcoregtk at build time. fw13 carries the whole set as host packages today. The image carries none of them and its pkgconfig directory has no matching files, so the link step cannot resolve. Largest single gap by weight, and the one most obviously suited to a container rather than to the image.
60	70
			@@ -80,7 +90,9 @@
80	90
81	91		- libfuse.so.2 is absent, so the vendored appimagetool cannot self-mount for the audiofiles build. Measured on fw13 that setting `APPIMAGE_EXTRACT_AND_RUN=1` on that exact tool succeeds and writes a valid AppImage, so the fix is one environment variable in `dist/build-appimage.sh`, not a package. Tauri's own AppImage path already sets it.
82	92		- `PROFILE=server` lacks xdg-mime and xdg-open, which tauri-bundler references at hard-coded `/usr/bin` paths. So the build-host role cannot run on the server profile as it stands, which matters while task `d1fed0d7` is still deciding whether that profile exists as a product. A headless build host is the strongest argument for the server profile, and today it is the profile that cannot build the apps.
83		-	- patchelf is absent, and Tauri's AppImage path runs linuxdeploy's gtk plugin over the bundled libraries, which rewrites RPATHs. Read from the downloader strings in the cargo-tauri binary; the plugin scripts were not read and the path was not run, so the patchelf requirement is a reading. The same finding carries a second consequence: that build path fetches linuxdeploy and its plugins from GitHub every time, so an offline or rate-limited fw13 cannot release, on Alloy or on Pop.
	93	+	- patchelf: struck. The reading was wrong. This entry said patchelf was needed because Tauri's AppImage path runs linuxdeploy's gtk plugin over the bundled libraries, and it said so on the strength of downloader strings in the cargo-tauri binary rather than on running anything. Measured 2026-08-21: linuxdeploy ships its own patchelf inside its AppImage and resolves it from the extracted AppDir, never from the host. Extracting `~/.cache/tauri/linuxdeploy-x86_64.AppImage` puts `linuxdeploy`, `linuxdeploy-plugin-appimage`, `patchelf` and `strip` in `squashfs-root/usr/bin/`, and running it under a `/usr/bin` symlink farm with patchelf excluded prints `DEBUG: Using patchelf: /tmp/appimage_extracted_.../usr/bin/patchelf` and completes. The gtk plugin never calls it at all; `grep -n patchelf ~/.cache/tauri/linuxdeploy-plugin-gtk.sh` exits 1 over 326 lines. So patchelf belongs in neither the image nor a container, and nothing here needs doing.
	94	+
	95	+	The half of the original finding that survives is unrelated to patchelf: that build path fetches linuxdeploy and its plugins from GitHub on every run, so an offline or rate-limited fw13 cannot release, on Alloy or on Pop. That moved to infra `83ee4a38` and is tracked there.
84	96		- The image declines rustup, and 28 repos pin a toolchain only rustup honours. Fedora 43's rust RPM happens to be the pinned 1.97.1 today, so nothing breaks now. The RPM has no mechanism to read the pin, so the agreement is coincidence rather than a control: the day Fedora moves, every build in the tree silently runs on a toolchain the repos did not ask for, and the first thing to notice is `cargo fmt --all --check`, a gate in every publish recipe.
85	97		- The signing material is `$HOME`-only. Release signing keys, the updater keys and the registry credentials live in `$HOME` and in no repo. Verified that astra holds byte-identical copies, so a wipe loses nothing, and verified that the bootstrap README covers repos and the cargo config and stops there. The material survives and nobody has written down where it survives. Fix that before Phase 3, in `_private`, not here.
86	98		- `~/.bashrc` carries the daemon tokens and the PATH the role depends on, and Alloy's default shell is nushell. bash is in the image, so keeping a bash login shell makes this a non-event and taking nushell makes it one file to translate. Worth naming because moving those exports out of the harness config in August quietly made `~/.bashrc` load-bearing and unbacked.