Correct the release documents the readiness pass found wrong

The closing code fence in the release notes carried an info string, so under
CommonMark it was not a closer and the block ran to the end of the file.
Rendered through GitHub's own markdown endpoint the published body stopped
emitting headings after "Upgrade notes" and ended inside a code block, so
the download section, the changelog and security links and the contributor
credits all became preformatted text. Rendering the corrected file the same
way returns all seven headings and a working release link. A lint fix had
rewritten both fences rather than only the opening one.

The post-upgrade instruction named a subcommand that does not exist: it said
to run fipsctl status, which exits 2, where the command is fipsctl show
status. That instruction is aimed at exactly the users this release exists
for.

Several claims were broader than the tree supports, and each is narrowed to
what is true. The two discovery fixes carry no platform gating, so the notes
no longer tell macOS, Windows, FreeBSD and OpenWrt users that nothing
changed for them, and no longer say the release contains no behavioral
change. The supported-distribution paragraph now covers the .deb and the
tarball rather than all Linux artifacts, since Arch and NixOS build from
source and OpenWrt is a musl target that does not depend on the glibc floor.
The install-test sentence says x86_64, because the arm64 package is
install-tested by nothing. The changelog no longer claims every producer
runs the floor check, since the deprecated host-build targets do not.

The counter guidance was wrong about which counter moves, the objdump line
prints the symbol beside the version, and the two relative links in the
notes resolve inside the repository but 404 in a release body, so they are
absolute now. That last change also makes the root mirror byte-identical to
the versioned copy for the first time.

The FreeBSD install line takes a concrete filename again: a placeholder is
not pasteable, which is the whole point of an install instruction.

CHANGELOG.md

@@ -57,9 +57,11 @@ Nothing yet. Everything previously staged here is folded into
   it looked healthy while the daemon was dead. No source code caused this and
   none was changed. The Linux artifacts are now built in a container pinned to
   the oldest supported distribution, declared with the floor in
-  `packaging/build-floor.env`, and every producer runs
+  `packaging/build-floor.env`, and every producer on the release path runs
   `testing/check-glibc-floor.sh` on what it made, so a package or a tarball that
-  would not load fails the build rather than reaching a user. The declared
+  would not load fails the build rather than reaching a user. The deprecated
+  host-build targets in `packaging/Makefile` are not on that path and are not
+  floor-checked. The declared
   dependency is derived from the binaries instead of hand-written, so it states
   the floor it was built against.
 

README.md

@@ -194,9 +194,10 @@ takes `fips` from the AUR, and NixOS uses the Nix flake described
 below. **Only the `.deb` is exercised by an install test**, by the
 `deb-install` suite across debian12, debian13, ubuntu22, ubuntu24 and
 ubuntu26; neither the AUR package nor the flake is. That suite runs on
-every push and pull request, against a `.deb` built by the same pinned
+every push and pull request, on x86_64, against a `.deb` built by the same
-container as the released one. It does not run at a tag: no workflow
+pinned container as the released one. It does not run at a tag, and the
-installs the published artifact, so the released package is checked by
+arm64 package is install-tested by nothing: no workflow installs a published
+artifact, so the released packages are checked by
 hand. OpenWrt is a musl
 target rather than glibc, and it takes an `.ipk` on 24.x and earlier or
 an `.apk` on 25 and later; both carry the `fips-mesh-setup` and
@@ -308,12 +309,15 @@ that makes the Linux packages install and run on Debian 12 and Ubuntu
 22.04, where every artifact from v0.3.0 through v0.5.0 installed and
 then could not start.
 [v0.5.0](https://github.com/jmcorgan/fips/releases/tag/v0.5.0) was the
-last feature release, so how much of it is new to you depends on which
+last feature release, so how much of that release is new to you depends on
-version you are upgrading from. The core
+which version you are upgrading from. The core
 protocol
 works end-to-end over UDP, TCP, Ethernet, Tor, Nym, and Bluetooth on a
 global, public test mesh of thousands of nodes.
 
+v0.5.1 is a packaging fix and carries two discovery fixes; the feature
+content below is v0.5.0's.
+
 v0.5.0 is a platform-and-lifecycle release. It adds FreeBSD as a
 packaged platform (x86_64 only), OpenWrt setup helpers for an 802.11s
 mesh between routers (`fips-mesh-setup`) and for the open `!FIPS` client

RELEASE-NOTES.md

@@ -22,9 +22,9 @@ contribution. There is no wire format change and no new configuration.
   it.
 - **Any other Linux: upgrade at your convenience.** Your daemon was
   running, and you gain the two discovery fixes.
-- **macOS, Windows, FreeBSD and OpenWrt: nothing changed for you.** The
+- **macOS, Windows, FreeBSD and OpenWrt: the packaging defect never
-  defect was in how the Linux artifacts were built. Those artifacts are
+  affected you**, since it was in how the Linux artifacts were built. You
-  rebuilt from the same source and are otherwise as v0.5.0 shipped them.
+  do get the two discovery fixes, which are not gated by platform.
 - **From source: you were never affected.** A binary you built runs
   against the C library you built it on.
 
@@ -54,9 +54,10 @@ an older C library. **`fipsctl` was unaffected**, which is why an
 install checked by running a command looked healthy while the daemon was
 dead.
 
-**No source code caused this and none was changed.** The defect was in
+**No source code caused the packaging defect and none was changed to fix
-the build environment, and the release contains no behavioral change to
+it.** The defect was in the build environment. The two discovery fixes
-the daemon.
+below are this release's only behavioral change, and they are unrelated to
+it.
 
 **Why the declared dependency did not stop it.** The `.deb` said it
 needed `libc6` with no version, which every glibc satisfies. So a
@@ -126,9 +127,10 @@ It now has its own rejection reason and counter, `req_own_loopback`,
 shown in `fipstop` as "Own Loopback". `req_duplicate` returns to meaning
 only what it says.
 
-**If you watch these counters**, expect `req_duplicate` to drop and a
+**If you watch these counters**, expect a new non-zero `Own Loopback` to
-new non-zero `Own Loopback` to appear. That is the same traffic,
+appear on a node that originates lookups. That is traffic that was
-correctly attributed, not a new fault.
+previously counted elsewhere or not at all, correctly attributed, rather
+than a new fault.
 
 ## Compatibility
 
@@ -145,18 +147,19 @@ The library surface is unchanged. Configuration is unchanged.
 **Package upgrade, Debian and Ubuntu.** The usual upgrade replaces the
 binaries and restarts the service. On Debian 12 and Ubuntu 22.04 the
 daemon will start for the first time, so this is a first start rather
-than a restart: check `fipsctl status` afterwards and expect to see peer
+than a restart: check `fipsctl show status` afterwards and expect to see
-establishment, not a resumed session.
+peer establishment, not a resumed session.
 
 **Check what you actually have.** If you want to confirm the floor of an
 installed binary rather than trust the version string:
 
 ```text
 objdump -T /usr/bin/fips | grep GLIBC_ | sed 's/.*GLIBC_//' | sort -uV | tail -1
-```text
+```
 
-An artifact from this release reports 2.34. One from v0.5.0 or earlier
+An artifact from this release prints `2.34) __libc_start_main`. One from
-reports 2.39.
+v0.5.0 or earlier prints `2.39) pidfd_spawnp`, which names the symbol that
+caused this.
 
 **Rolling upgrade.** No coordination is needed. Upgrade nodes in any
 order.
@@ -182,9 +185,11 @@ There is no Android daemon artifact. Android is supported as an embedded
 crate.
 
 The full per-commit changelog lives in
-[`CHANGELOG.md`](CHANGELOG.md). Issues and discussion at
+[`CHANGELOG.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/CHANGELOG.md).
+Issues and discussion at
 [github.com/jmcorgan/fips](https://github.com/jmcorgan/fips). Security
-reports have a private channel; see [`SECURITY.md`](SECURITY.md).
+reports have a private channel; see
+[`SECURITY.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/SECURITY.md).
 
 ## Contributors
 

docs/getting-started.md

@@ -66,12 +66,15 @@ per-platform installer:
 - Windows: `.zip` with service-install scripts
 - Generic systemd Linux: `.tar.gz` with an `install.sh` script
 
-FIPS supports every version of a supported distribution that its vendor
+The `.deb` and the systemd tarball support every version of a glibc
-still supports for free: currently Ubuntu 22.04, Debian 12, Ubuntu 24.04,
+distribution that its vendor still supports for free: currently Ubuntu
-Debian 13 and Ubuntu 26.04. The Linux binaries are built in a container
+22.04, Debian 12, Ubuntu 24.04, Debian 13 and Ubuntu 26.04. Those binaries
-pinned to the oldest of those, so they run on all of them. The glibc floor
+are built in a container pinned to the oldest of them, so they run on all
-that follows is declared in `packaging/build-floor.env` and is enforced on
+five, and the glibc floor that follows is declared in
-every artifact by `testing/check-glibc-floor.sh`.
+`packaging/build-floor.env` and checked by `testing/check-glibc-floor.sh` on
+what the release workflow produces. Arch and NixOS build from source on your
+own machine, and OpenWrt is a musl target rather than glibc, so none of them
+depends on that floor.
 
 See the [project README's Quick start section](../README.md#quick-start)
 for download links and per-platform invocations.

docs/releases/release-notes-v0.5.1.md

@@ -22,9 +22,9 @@ contribution. There is no wire format change and no new configuration.
   it.
 - **Any other Linux: upgrade at your convenience.** Your daemon was
   running, and you gain the two discovery fixes.
-- **macOS, Windows, FreeBSD and OpenWrt: nothing changed for you.** The
+- **macOS, Windows, FreeBSD and OpenWrt: the packaging defect never
-  defect was in how the Linux artifacts were built. Those artifacts are
+  affected you**, since it was in how the Linux artifacts were built. You
-  rebuilt from the same source and are otherwise as v0.5.0 shipped them.
+  do get the two discovery fixes, which are not gated by platform.
 - **From source: you were never affected.** A binary you built runs
   against the C library you built it on.
 
@@ -54,9 +54,10 @@ an older C library. **`fipsctl` was unaffected**, which is why an
 install checked by running a command looked healthy while the daemon was
 dead.
 
-**No source code caused this and none was changed.** The defect was in
+**No source code caused the packaging defect and none was changed to fix
-the build environment, and the release contains no behavioral change to
+it.** The defect was in the build environment. The two discovery fixes
-the daemon.
+below are this release's only behavioral change, and they are unrelated to
+it.
 
 **Why the declared dependency did not stop it.** The `.deb` said it
 needed `libc6` with no version, which every glibc satisfies. So a
@@ -126,9 +127,10 @@ It now has its own rejection reason and counter, `req_own_loopback`,
 shown in `fipstop` as "Own Loopback". `req_duplicate` returns to meaning
 only what it says.
 
-**If you watch these counters**, expect `req_duplicate` to drop and a
+**If you watch these counters**, expect a new non-zero `Own Loopback` to
-new non-zero `Own Loopback` to appear. That is the same traffic,
+appear on a node that originates lookups. That is traffic that was
-correctly attributed, not a new fault.
+previously counted elsewhere or not at all, correctly attributed, rather
+than a new fault.
 
 ## Compatibility
 
@@ -145,18 +147,19 @@ The library surface is unchanged. Configuration is unchanged.
 **Package upgrade, Debian and Ubuntu.** The usual upgrade replaces the
 binaries and restarts the service. On Debian 12 and Ubuntu 22.04 the
 daemon will start for the first time, so this is a first start rather
-than a restart: check `fipsctl status` afterwards and expect to see peer
+than a restart: check `fipsctl show status` afterwards and expect to see
-establishment, not a resumed session.
+peer establishment, not a resumed session.
 
 **Check what you actually have.** If you want to confirm the floor of an
 installed binary rather than trust the version string:
 
 ```text
 objdump -T /usr/bin/fips | grep GLIBC_ | sed 's/.*GLIBC_//' | sort -uV | tail -1
-```text
+```
 
-An artifact from this release reports 2.34. One from v0.5.0 or earlier
+An artifact from this release prints `2.34) __libc_start_main`. One from
-reports 2.39.
+v0.5.0 or earlier prints `2.39) pidfd_spawnp`, which names the symbol that
+caused this.
 
 **Rolling upgrade.** No coordination is needed. Upgrade nodes in any
 order.
@@ -182,9 +185,11 @@ There is no Android daemon artifact. Android is supported as an embedded
 crate.
 
 The full per-commit changelog lives in
-[`CHANGELOG.md`](../../CHANGELOG.md). Issues and discussion at
+[`CHANGELOG.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/CHANGELOG.md).
+Issues and discussion at
 [github.com/jmcorgan/fips](https://github.com/jmcorgan/fips). Security
-reports have a private channel; see [`SECURITY.md`](../../SECURITY.md).
+reports have a private channel; see
+[`SECURITY.md`](https://github.com/jmcorgan/fips/blob/v0.5.1/SECURITY.md).
 
 ## Contributors
 

packaging/freebsd/README.md

@@ -24,7 +24,7 @@ Output: `deploy/fips-<version>-freebsd-<arch>.pkg` (e.g.
 ## Install
 
 ```sh
-pkg add ./deploy/fips-<version>-freebsd-amd64.pkg
+pkg add ./deploy/fips-0.5.1-freebsd-amd64.pkg
 # post-install seeds this from the sample if absent, at mode 0600
 vi /usr/local/etc/fips/fips.yaml
 sysrc fips_enable=YES fips_dns_enable=YES