takana etapa 5c: comentarios de scripts, MOTD, y un BUG que introdujo la etapa 4

250 líneas de comentario en 151 scripts. Control verificado: el diff no toca NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa. El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces: las tres eran el MOTD que el script escribe DENTRO de la imagen construida — texto del producto, no comentario del script. Se cambiaron aparte y a propósito, que es rebranding, no limpieza. Y el hallazgo caro: casaba contra , que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate. La etapa 4 lo movió a y el script quedó casando NADA. No fallaba: imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja. Además 14 rutas de módulo en docs, que el barrido anterior no tocó porque no es frontera de palabra.
2026-09-09 19:28:48 +00:00
parent 97ceb72411
commit 476168bb07
103 changed files with 273 additions and 268 deletions
@@ -1,12 +1,12 @@
 #!/usr/bin/env bash
 # hydrate-gnome.sh — proyecta al FHS el cierre de runtime de una receta GNOME, desde artefactos
-# SELLADOS del store, sin rebuild ni reproduce (`hammer hydrate <hash> --into`).
+# SELLADOS del store, sin rebuild ni reproduce (`takana hydrate <hash> --into`).
 #
 # DIFERENCIA CON scripts/kde/hydrate-from-store.sh, y por qué importa: aquél resuelve el cierre desde
 # un `index.json` de repo y elige el artefacto por MTIME con un CUTOFF ("el más nuevo anterior a hoy").
 # Eso es una heurística: si dos artefactos del mismo paquete conviven en el store, la fecha no dice
 # cuál corresponde a la receta VIGENTE. Acá el cierre sale del GRAFO REAL de recetas (`[deps].build`,
-# resolución hermano→padre, la misma que usa hammer) y el artefacto se elige por `hammer hash`, que
+# resolución hermano→padre, la misma que usa takana) y el artefacto se elige por `takana hash`, que
 # calcula el ArtifactHash de la receta de HOY sin construir. O sea: cero ambigüedad, y si falta algo
 # el reporte dice exactamente qué receta y con qué hash lo buscaba.
 #
@@ -93,7 +93,7 @@ echo "==> inyectando arje-logind-compat (el login1 del fractal)"
 # LEYENDO /run/systemd/{sessions,users,seats}. Pero alguien tiene que ESCRIBIR esos ficheros, y ese
 # alguien es arje-logind-compat, el daemon D-Bus que se hace pasar por org.freedesktop.login1.
 # libelogind entra solo (es dep de mutter); el daemon no, porque nadie lo declara como dep de build.
-# El artefacto se elige por `hammer hash` sobre la receta —el que corresponde a la receta de HOY—, no
+# El artefacto se elige por `takana hash` sobre la receta —el que corresponde a la receta de HOY—, no
 # por el más reciente del store: con dos artefactos del mismo paquete conviviendo, la fecha no dice
 # cuál es el vigente. ALC_BIN permite inyectar un binario RECIÉN COMPILADO en vez del artefacto sellado. Es para probar
 # un cambio en arje-compat antes de commitear/pushear tawasuyu y re-sellar la receta (la receta pina