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.
This commit is contained in:
Sergio
2026-09-09 19:28:48 +00:00
parent 97ceb72411
commit 476168bb07
103 changed files with 273 additions and 268 deletions
+2 -2
View File
@@ -2,7 +2,7 @@
# vigia-parches.py — ¿los parches de la receta AGARRAN todavía en la fuente que la receta pinea?
#
# ══ EL PUNTO CIEGO QUE ESTE VIGÍA CUBRE ════════════════════════════════════════════════════════
# `hammer build` aplica los parches DESPUÉS de materializar las dependencias. En una receta hoja de
# `takana build` aplica los parches DESPUÉS de materializar las dependencias. En una receta hoja de
# la plataforma Gecko eso significa que el `patch` que no agarra se descubre detrás de horas de
# compilar OTRA COSA: waterfox estrena su primer build reconstruyendo nodejs (4414 objetivos de V8,
# a `-j2` porque el propio recipe capa por RAM). El parche que falla es el paso 3 de un camino cuyo
@@ -10,7 +10,7 @@
#
# La receta de waterfox además hace una APUESTA EXPLÍCITA y escrita: la base es Gecko 153.1.0 y los
# once parches de musl son los de Firefox 154, una release por encima. Su propio comentario dice
# «si `patch` falla, falla TEMPRANO, antes de compilar nada». Con el orden real de `hammer build`
# «si `patch` falla, falla TEMPRANO, antes de compilar nada». Con el orden real de `takana build`
# eso no es cierto: falla tarde. Este vigía es lo que lo vuelve cierto.
#
# ══ Y EL SEGUNDO PUNTO CIEGO, QUE ES EL CARO ═══════════════════════════════════════════════════