Tres cosas, y las tres quitan vueltas.
1. NO HACE FALTA NINGUNA CREDENCIAL EN EL WORKER, Y TAMPOCO UN USUARIO NUEVO
`tawasuyu/tawasuyu` y `sergio/takana` son repos PÚBLICOS en el gitea. Las 23 recetas que apuntaban a
`gitea@git.tawasuyu.net` (SSH, que exige la clave que es el SSH de todo) pasan a
`https://git.tawasuyu.net/…`. La URL es locator y NO entra en `hash_inputs` (ADR 0013): hecho con
control antes/después, **ningún ArtifactHash se movió**. Medido en el worker: `git clone --mirror
--filter=blob:none` + `git archive` extrae el árbol (155 M) **sin una sola credencial**.
Un usuario propio en gitea sólo haría falta para un repo PRIVADO; hoy ninguna receta usa uno. Si
mañana hace falta, es una cuenta de máquina con acceso al repo que toque — nunca la clave personal.
De paso, tres recetas decían «HUB-ONLY: el worker secretless recibe Connection refused». Ya no es
cierto y el comentario decía lo contrario de lo que pasa: corregido en las tres.
2. LA COPIA FUERA LA DA LA MUDANZA, NO GITHUB (decisión del usuario)
El «paso 1: espejar los 26 repos» deja de ser el paso 1. En cuanto el gitea vive en la caja nueva,
esos repos dejan de existir sólo en la máquina que se borra — que es lo que el paso pedía. El
objetivo es dejar de pagar dos máquinas, no sumar una dependencia. `espejar-repos.sh` queda como
herramienta disponible.
3. EL §9 REESCRITO: qué está hecho, qué falta y en qué orden
Hecho y cerrado: la caja arranca takana puro · store/grafos/granja/respaldo · repo firmado · la
imagen del perfil servidor con gitea sirviendo 200 supervisado por arje · `arjectl` · y el ensayo con
los datos REALES de gioser corriendo sobre takana.
Falta, en orden: actualizar la caja a la imagen nueva (`upgrade`, no `dd`) → mudar los datos del
gitea (`.backup` + rsync, con el origen parado en el corte) → caddy con los 6 dominios vivos → DNS →
verificar desde fuera con un clone real → el resto de servicios del censo → borrar gioser con las 8
puertas en verde.
Bloqueantes con su tamaño: `git` sellado sin `remote-http` (afecta a clonar DESDE una caja takana,
no al gitea que sirve; re-sella una raíz de `base`) y la puerta 5, que no bloquea la mudanza.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
Rotura que introduje yo al renombrar el repo en gitea, y que no fallaba todavia
porque las tres tienen su artefacto sellado en cache:
git ls-remote sergio/hammer.git -> no responde
git ls-remote sergio/takana.git -> b393687d
hammerd, netup y portal-probe clonan el propio repo por ssh. Cualquier rebuild
de esas tres —o un hub nuevo sin store— habria muerto en el fetch.
El ArtifactHash NO se mueve, y esta comprobado receta por receta antes y despues
del cambio (48bbbe52, 8d093d74, 13ebb33d): la URL es locator y no entra en
hash_inputs, solo el commit (ADR 0013). Por eso mismo el arreglo es gratis.
Tambien el default de GITEA en espejo-setup.sh. git.tawasuyu.net y
git.gioser.net son la MISMA maquina (204.168.193.248), asi que el renombre le
aplica igual.
El espejo de GitHub sigue siendo sergiovelasquezzeballos/hammer: alla el repo no
se renombro. No rompe nada porque el push va por URL explicita, pero queda dicho.
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash
movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los
ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no
hasheaban de antes).
El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza
con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una
fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL
también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en
hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de
TOML y no entra ahí.
Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales
dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
Las dos recetas apuntan a `ssh://gitea@git.gioser.net:2345/sergio/hammer.git`, o sea a este mismo
árbol, que declara MIT en `Cargo.toml` y trae su `LICENSE`. No hace falta clonar nada para saberlo:
la evidencia estaba en el directorio de trabajo. Los dos ArtifactHash, idénticos.
Primera tanda con el orden nuevo (por impacto en el grafo, no alfabético). 30 recetas C de
clase HOJA: bash, coreutils, git, gnupg, grep, gzip, jq, e2fsprogs, libarchive, htop…
LA MEDIDA QUE JUSTIFICA EL CAMBIO DE ORDEN: activar estas 30 dejó 41 recetas sin artefacto
vigente = las 12 que ya estaban en deuda + las 30 tocadas (una ya estaba entre las 12). **Cero
colateral.** Contra la tanda anterior, donde tocar TRES bibliotecas base (expat, zstd, ncurses)
dejó 54 sin artefacto y tumbó la cadena wlroots/sway entera.
Mismo esfuerzo de build, diez veces menos destrozo. El orden no era un detalle de comodidad.
Selección: clase `c` + `dependientes_total == 0` + estado sellado, excluyendo las de tawasuyu
(git privado ⇒ no construyen en el worker, que es sin secretos por diseño) y las Go/Rust, que
necesitan sus módulos y fallan ahí. Quedan 73 hojas C elegibles; van 30.
La tanda corre DESASIDA con nohup en el worker — la lección de ayer, cuando un drenaje murió a
las 14 de 54 al caerse la sesión ssh.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierra el userland mínimo salvo el init definitivo. hammerd entra como tercer
componente de stage1, construido por el lab vía BuildSys::Cargo + vendoring:
- recipes/hammerd.toml: source git del repo hammer a commit fijado (ADR 0006),
flags=["-p","hammerd"] para construir sólo ese binario del workspace, estático
con zig cc; las deps se vendorean en el fetch (Lote 6) ⇒ build --offline
- STAGE1_COMPONENTS += hammerd; el inittab provisional lo arranca como servicio
respawn (/usr/bin/hammerd) tras montar los pseudo-FS
- el test de recetas del repo ahora valida también hammerd.toml (parse + hash)
Falta sólo sustituir el init provisional de busybox por arje (ADR 0007) para el
CRASHED real. El cross-compile se valida en la VM.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5