From d154ce02a28628216e4d54e61a6a6ba3f15c8298 Mon Sep 17 00:00:00 2001 From: Sergio Date: Mon, 21 Sep 2026 20:35:34 +0000 Subject: [PATCH] =?UTF-8?q?simi:=20REPRODUCE=20bit=20a=20bit=20=E2=80=94?= =?UTF-8?q?=20y=20dos=20trampas=20operativas=20que=20costaron=20dos=20corr?= =?UTF-8?q?idas?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit scripts/verificar-repro.sh simi en el worker: «✓ simi REPRODUCE», 0 no-determinismos. Queda anotado en docs/state/repro-verificado.tsv con su hash, que es la clave del libro: si la receta o alguna dep cambia, la entrada deja de casar y hay que volver a verificar. Las dos trampas, anotadas en el SDD porque las dos fallan en silencio: 1. --store NO sirve para verificar reproducibilidad. Un store vacío da «Error: io: No such file or directory» a secas —sin decir qué falta— porque las deps del build no están ahí. El método correcto ya estaba escrito: apartar el artefacto dentro del MISMO store y reconstruir. Dos corridas perdidas por inventar un instrumento en vez de leer el que existía. 2. La cosecha BORRA una receta sembrada a mano: siembra hub→worker con rsync --delete, y el hub del que siembra es gioser, no el clon donde se trabaja. El worker perdió recipes/simi.toml entre el build y la verificación (el artefacto sellado sobrevivió, la receta no) y el verificador informó «REPRODUCEN: 0 · sin artefacto: 0» — o sea nada, porque su primer [ -f ] falla y salta en silencio. Comprobado de paso: editar los comentarios de la receta NO cambia el hash (hash_inputs es una lista explícita de campos). Y el artefacto vive sólo en el store del worker: sella con PROMOTE=0 y la cosecha baja el manifiesto, no el store. Promoverlo es otro paso. --- docs/plan-botar-busybox.md | 21 +++++++++++++++++++++ docs/state/repro-verificado.tsv | 1 + 2 files changed, 22 insertions(+) diff --git a/docs/plan-botar-busybox.md b/docs/plan-botar-busybox.md index 1ac58067..5076fb8c 100644 --- a/docs/plan-botar-busybox.md +++ b/docs/plan-botar-busybox.md @@ -948,6 +948,7 @@ El artefacto trae exactamente dos ficheros: `usr/bin/simi` y su `.hammer/recipe. | `scripts/static-audit.sh simi` | «estáticos de verdad: 1 · MIENTEN: 0» | | banco diferencial, 159 casos vs el ash | **0 divergencias** (bash: 8 · brush: 35) | | latencia de arranque | **468 µs** contra **449 µs** del ash — **1,04×** (brush: 1569 µs, 3,5×) | +| `scripts/verificar-repro.sh simi` | **`✓ simi REPRODUCE`** — bit a bit, apartando el artefacto y reconstruyendo | ⚠ **La latencia del estático musl no es la del build nativo**: el build del hub (glibc, dinámico) daba 865 µs, o sea 1,4× el ash. El estático baja a 1,04×. **Medir el binario que viaja, no el que se @@ -956,6 +957,26 @@ compila a mano** — la diferencia acá fue de un 35 % y habría quedado escrita ⚠ Todavía NO está en ningún perfil de `docs/state/targets.toml`. Declararla es meterla en la raíz de confianza del arranque, y eso es el paso 3 de abajo. +⚠ **Y el artefacto vive SÓLO en el store del worker.** El worker sella con `PROMOTE=0` y la cosecha +baja el **manifiesto**, no el store: el hub no lo tiene. Promoverlo es otro paso. + +### Dos trampas operativas que costaron dos corridas + +**1. `--store ` NO sirve para verificar reproducibilidad, y falla con un error que no dice +nada.** Un store vacío da `Error: io: No such file or directory (os error 2)` a secas, sin decir qué +falta, porque las DEPS del build no están ahí. El método correcto ya estaba escrito y es +`scripts/verificar-repro.sh`: **aparta** el artefacto dentro del MISMO store (un rename, que sobrevive +a un kill) y reconstruye, así las deps siguen en su sitio. Dos corridas perdidas por no leer el +instrumento que ya existía antes de inventar uno. + +**2. La cosecha BORRA una receta sembrada a mano.** `cosecha-cron.sh` siembra hub→worker con +`rsync --delete`, y el hub del que siembra es **gioser**, no el clon donde se trabaja. Entre el build +y la verificación, el worker perdió `recipes/simi.toml` —el artefacto sellado sobrevivió, la receta +no— y el verificador informó `REPRODUCEN: 0 · sin artefacto: 0`, o sea **nada**, porque su primer +`[ -f "$f" ]` falla y salta en silencio. Hasta que gioser haga `pull` del commit, cualquier corrida en +el worker necesita reponer la receta primero. Comprobado de paso que el hash NO cambia al editar los +comentarios de la receta: `hash_inputs` es una lista explícita de campos. + ## El alcance salió de la medición, no de POSIX | consumidor | qué necesita | estado | diff --git a/docs/state/repro-verificado.tsv b/docs/state/repro-verificado.tsv index ba41dbeb..d2ce3cf2 100644 --- a/docs/state/repro-verificado.tsv +++ b/docs/state/repro-verificado.tsv @@ -251,3 +251,4 @@ gocryptfs 0caf96352eae21ed51b32be9ead8d5525bb07e8aa124eb33c4b9588f1a02421d 2026- sq 86de0799d816abb671cc3192daa9986adf9f6210a0be8cc1b4dfab0033d23dcf 2026-09-14 reproduce (tras poner al día un artefacto derivado) usql 820d3f10cf37da8603adc5da554800715705492c3ae8819f3a0a82ce0ad41d05 2026-09-14 reproduce (tras poner al día un artefacto derivado) gitea 5edf9c16b3a48cb44198a7d590f7c05a0f24e57429c3d05ecce92f75ce9ca19b 2026-09-14 reproduce (tras poner al día un artefacto derivado) +simi 46ff6fcf67bd23dece4d130c92855908520200f88ca85981317f81fcc56bb834 2026-09-21 reproduce