Files
felhom.eu/REPORT.md
T
admin 5a654ebc9a slice 4: bilingual console + the English download page is live (R-559)
The image is BUILT but NOT PUBLISHED, and that is deliberate: publishing to
iso.felhom.eu is public and irreversible, and the runbook needs a proof install
on BOTH menu entries plus a reboot against the uploaded bytes. That is
supervised, so I stopped there. felhom-installer-1.29.0-pve9.2-1.iso, sha256
c67ceaa3…fb02, with every mechanically checkable criterion passing (G1, G2, G5,
G6, G7, G9, G16 — including both payload files byte-identical to repo HEAD).

The download pages still name 1.28.0, the image that IS published. Pointing
them at a file that is not there would hand every reader a 404. A new site gate
refuses the two pages naming different installer files or checksums, so
whoever publishes 1.29.0 cannot update one and forget the other.

Measured rather than read: the pairing banner is 24 rows on a 25-row console.
One row of margin — so the height is now pinned, because two more lines push
the HUNGARIAN code at row 5 off the top, and a banner whose code has scrolled
away is furniture.

R-587: two root-password files from July sit in the directory the public ISO is
published from. Both 404 on the bucket (against a 200 control), so nothing
leaked — but the only thing keeping them off is an --include pattern they miss
by an accident of naming. A pattern that protects by coincidence is not a
control.

R-588: release records live in two different places, which made me wrongly
conclude 1.28.0's gate had never been run. It had.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-09-18 17:47:58 +02:00

78 lines
4.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# REPORT — slice 4: the console banner and the download page (R-559)
**ISO 1.29.0 source + the English download page** · base `183727db9c44` · 2026-09-18
## Claims in the task that turned out wrong, named first
1. **"the GRUB menu has one entry"** — the **release** image has **two** (graphical + text mode). The
single-entry template is the appliance image. Both updated.
2. **"27 Hungarian printf lines"** — **25**.
3. **"No test compares the banner text itself"** — one greps the painted banner, and another `cmp`s
`/etc/issue` against the `postinst`'s copy **byte for byte**. The console seam already existed too.
4. **"VM 321/322 were used"** — not confirmed; no VM was created (see Stop).
5. **"the site is published as its CHANGELOG says"** — right: push to `main`, git-sync, ~1–2 min.
Verified live.
6. The publish runbook does exist (`documentation/runbooks/iso-release-gate.md`) and is correctly not
in the ISO README.
## Two defects found before any feature work
**R-586 — the ISO harness had been RED for two days.** Run unchanged at the base commit it failed two
R-496 checks. The script paints with `> "$CONSOLE_DEV"`; on a console that is a device and truncation
is a no-op, but the harness pointed it at a plain FILE, so each banner erased the previous one. ISO
1.28.0's new bound banner (`c033b3b`, 2026-09-16) paints straight after the pairing banner and wiped
it. That commit did not touch the harness, and **the harness is in no gate and no CI run**, so nobody
saw. Fixed with a FIFO; production code untouched. Its being ungated is still open.
**The release gate would have stopped the task the operator asked for.** G16 read *"every
Felhom-authored string is Hungarian — PASS = no English sentence"*, encoding the 2026-07-31 scope.
**Ruling 1b of 2026-09-17 supersedes it.** G16 was **rewritten, not waived**: Hungarian FIRST, pinned
by a golden, each secret named once per language.
## What shipped
Bilingual pairing banner, bound banner and `/etc/issue` (plus `postinst`'s byte-coupled copy);
English halves on both GRUB entries; `website/en/download.html` **live**, linked both ways with
`hreflang`; `letoltes.html` changed by **four lines** and nothing else.
**The link is not in the nav** — the nav is a shared block `site_gates.py` pins across every page, and
the gate convicted my first attempt, which is how the link found its right home.
## Proven, not read
Hungarian **goldens** captured before one English line existed; the harness asserts each banner's
first N lines are exactly the golden. English blocks carry no Hungarian letter (Hungarian block =
positive control). Every line ≤ 80 **columns**, counted in characters because the Hungarian lines are
multi-byte. **The whole paint ≤ 25 rows.** All red-proofed — a changed byte, a planted `ó`, an
over-wide line, two extra lines.
**The pairing banner is 24 rows on a 25-row console.** One row of margin, which is exactly why the
height is now pinned: two more lines and the **Hungarian** code at row 5 scrolls off the top.
Against the built ISO: G1, G2, G5, G6, G7, G9, G16 all pass — including both payload files
**byte-identical to repo HEAD**.
## STOP — the image is built, not published
`felhom-installer-1.29.0-pve9.2-1.iso`, sha256 `c67ceaa3793b38639d0f24c9c9704270d04e50b74f1ea88b1129fdd1dec6fb02`.
Publishing is public and irreversible and the runbook needs, against the uploaded bytes: a **proof
install on BOTH menu entries**, a reboot (G15), a person choosing the disk (G14) and a round trip
(G11). That is supervised. **The download pages therefore still name 1.28.0** — the published image —
because pointing them at a file that is not there would hand every reader a 404. The new gate stops
anyone updating one page and forgetting the other.
**No VM created, none destroyed. demo-hp guest 9201 untouched. No floor, no golden.**
## Rows
**R-586** (harness red, ungated) · **R-587** (two root-password files sit in the ISO publish source
directory; both 404 on the bucket against a 200 control, so not leaked — the only thing keeping them
off is an `--include` pattern they miss by naming accident) · **R-588** (release records live in two
different places; it made me wrongly conclude 1.28.0's gate had never been run).
## Green
`bash -n` + `shellcheck` clean on both scripts · harness **71 checks, all pass** · `site_gates.py` OK ·
`repo_gates.py --fast` all 14 OK.