sergio/takana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
3,121 Commits 1 Branch 0 Tags
e5e723b670c3f504fce90a8be9d3ada239d85cc5
Commit Graph
7 Commits
Author SHA1 Message Date
SergioandClaude Opus 5 77732edead hydrate-profile: encontrar el binario donde ESTÉ — no sólo en el árbol de desarrollo 
`HAMMER` estaba cableado a `ROOT/target/release/takana`, así que el guión no corre en una caja
INSTALADA, donde el binario es `/usr/bin/takana` y `target/` ni existe:

    FileNotFoundError: [Errno 2] … '/opt/takana/target/release/takana'

Es la misma deuda que este frente ya pagó dos veces —`respaldo-storagebox.sh` y el «unhashable 875»
con el lab perfecto—: el instrumental asume que el hub es un árbol de desarrollo. Ahora busca en
`$TAKANA`, `$HAMMER`, el árbol de desarrollo y el `PATH`, en ese orden.

Salió al ir a actualizar la caja de producción a la imagen nueva, que es exactamente el caso de uso
para el que no servía.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
 2026-09-14 19:38:33 +00:00
Sergio af20d90648 bzip2: cuatro comandos rotos desde siempre — /usr/bin/bzcmp -> /out/usr/bin/bzdiff 
`bzcmp`, `bzegrep`, `bzfgrep` y `bzless` son symlinks con **la ruta del SANDBOX horneada dentro**.
El Makefile de bzip2 los crea con `ln -s $(PREFIX)/bin/bzdiff bzcmp` —con `$(PREFIX)` DENTRO del
destino— y como bzip2 **no soporta `DESTDIR`**, la receta pasa `PREFIX=/out/usr` (el mismo truco que
valkey) ⇒ el destino que queda es `/out/usr/bin/bzdiff`. Al hidratar, esos cuatro apuntan a un
directorio que en el sistema real no existe.

⚠ **Cinco indicadores en verde sobre cuatro comandos que no funcionan**: el artefacto tiene
contenido, `bzip2`/`bzgrep`/`bzdiff` corren, `static-audit` pasa, el grafo lo cuenta y la receta
REPRODUCE. Ninguna métrica existente mira a dónde apunta un enlace.

Arreglo: rehacerlos RELATIVOS después del install, que es lo correcto para un artefacto direccionado
por hash — un enlace relativo sigue valiendo esté el árbol montado donde esté. Verificado: los cuatro
resuelven y `bzip2 -c | bzcat` sigue dando `hola`.

## El guardián, en el mismo sitio y por la misma pregunta

`--auditar-raices` ya contestaba «¿esta receta dejó ficheros donde no van?». Ahora contesta también
la otra mitad: «¿dejó ENLACES a una raíz que no es del FHS?». Son la misma familia —un `install` que
se equivocó de destino— y comparten la definición de `FHS_RAIZ`, que es lo que evita dos listas que
se desincronizan.

La regla es independiente del perfil, y por eso vale sobre el store entero: un enlace a OTRO
artefacto es normal (`kinfocenter -> /usr/bin/systemsettings`, los dos en `escritorio-kde`, resuelve
en el rootfs fundido). Lo que nunca puede estar bien es un destino absoluto cuya primera componente
no sea del FHS: `/out`, `/src`, `/tmp` son rutas del lab.

Dos correcciones al propio guardián, las dos aprendidas midiendo:

· **Sólo audita el artefacto VIGENTE de cada receta.** El store guarda todos los sellados históricos,
  así que la primera versión acusaba a bzip2 por el artefacto YA SUPERADO — el mismo sobre-reporte
  que `static-audit.sh` tuvo que quitarse de encima. El hash vigente sale de los grafos de estado,
  no de 1150 llamadas a `takana hash`. ⚠ Y hay que regenerar **los cinco** grafos: con sólo el
  principal regenerado, el de KDE seguía apuntando al bzip2 viejo y el filtro lo dejaba pasar.
· **Un barrido que no miró NADA lo dice y sale 2.** Filtrar por hash vigente hace que un `--store`
  que no case con los grafos deje cero artefactos auditados, y sin la guarda eso se imprimía como
  «✓ 0 ofensores»: una respuesta falsa con forma de respuesta. Probado: `--store /tmp` → exit 2.

El control del hallazgo es el propio arreglo, sobre datos reales y no sintéticos: antes del fix el
barrido nombra los cuatro enlaces de bzip2; después, `✓ ninguno`.
 2026-09-12 00:46:10 +00:00
Sergio beb1c2a597 auditar-raices: el guardián de la raíz sucia sólo veía los perfiles — y hay 649 recetas fuera 
`hydrate-profile.py` ya tenía el bloque «quién ensucia la RAÍZ del rootfs», y es bueno: mira por
ARTEFACTO y no sobre el árbol fundido, porque en el fundido el nombre del culpable ya se perdió.
Pero sólo corre al hidratar un perfil ⇒ **sólo ve lo que alguna imagen declara**. Hoy hay **649
recetas que no alcanza ninguna imagen**, y una fase `install` que se equivoca de destino en una de
ésas es invisible hasta el día que alguien la declare.

Lo destapó `qdrant`: selló con **69 M** de cabeceras de protobuf bajo `/src`, y no está en ningún
perfil ⇒ ningún guardián lo habría visto. Lo encontré mirando el árbol del artefacto a mano antes de
promoverlo, que es justo lo que no se puede dejar a que alguien se acuerde.

`--auditar-raices` hace la misma pregunta sobre el STORE ENTERO sin hidratar nada, reutilizando el
mismo `FHS_RAIZ` (una sola definición de «qué puede ir en la raíz», no dos que se desincronizan).

Y dos tablas, porque un barrido que canta tres cosas de las cuales dos son correctas se deja de leer:

· `RAIZ_POR_CONTRATO` — `seed-zig` (el toolchain ES el artefacto) y los rootfs (`store`/`ente` son
  suyos por diseño). Se imprimen como ⊘ con el motivo y no cuentan.
· `RAIZ_DEUDA_DECIDIDA` — `perl` y sus 945 páginas nroff en `/`. Es suciedad REAL pero su arreglo
  está decidido EN CONTRA por ahora (una línea, 305 rebuilds, va con el próximo bump). Se imprime
  como contexto y **no hace fallar**: si fallara siempre, un ofensor NUEVO se perdería entre el ruido
  del viejo — que es exactamente cómo se muere un guardián.

Probado con los dos controles, no sólo con el que da verde: sobre un store de juguete con una
suciedad inventada sale **1** y la nombra; quitándola sale **0**. Sobre el store real: 0 ofensores
nuevos sobre 3 artefactos conocidos.
 2026-09-11 22:53:29 +00:00
Sergio 476168bb07 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
Sergio 8730aad34e takana etapa 3b: las 49 invocaciones pasan a ./target/release/takana 
Los llamadores EJECUTABLES: scripts/ (incluida toda la granja), los runbooks y
CLAUDE.md. Seguro porque la 3a ya garantiza que el worker emite los dos
binarios, y porque en farm-lab-sync.sh el cargo build remoto precede a la
invocación remota en el mismo script.

Verificado: sintaxis de los 49 (bash -n / py_compile — ojo que
why-differs-barrido.sh es Python con extensión .sh) y `takana hash` devuelve
hash real sobre el store.

NO se toca en esta etapa, a propósito:
- La variable de entorno HAMMER=. Es interfaz de los scripts entre sí y hay
  llamadores que la fijan; renombrarla va con la etapa 4.
- docs/evidencia/ y los HANDOFF: son REGISTRO de lo que se corrió ese día.
  Reescribir un comando dentro de una evidencia la falsifica.
- docs/state/: es generado, se regenera solo.
- Los ADR y los docs de diseño: texto, y `hammer` sigue funcionando. Van con
  la etapa 5, que es la de churn de texto.
 2026-09-09 18:25:58 +00:00
SergioandClaude Opus 5 02e93a02ea raíz sucia: 945 ficheros de perl en /, con guardián que nombra al culpable y el número que difiere el arreglo 
Hidratando el rootfs de sway aparecieron 945 ficheros sueltos en la raíz — `AnyDBM_File.0`,
`App::Cpan.0`, … Son las páginas nroff de perl: su `Configure -des` no encuentra nroff, elige
`man1ext='0'` y `man1dir=' '` (la convención de perl para «no instales man»), pero `installman` las
GENERA igual y con el directorio vacío `make install DESTDIR=/out` las deja en `/out/`.

Ninguna métrica sobre recetas puede ver esto: hay que hidratar un rootfs de verdad y mirarlo.

El guardián va en `hydrate-profile.py` y mira **por artefacto**, no sobre el árbol fundido: en el
árbol fundido el nombre del culpable ya se perdió y 945 ficheros en `/` no se parecen en nada a
«una fase install con el destino vacío», que es lo que son. Barrido el store entero: **perl es el
único** — `.times`/`.dmerge` son internos del store y `product-rootfs`/`seed-zig` son especiales.

El arreglo es UNA línea (`-Dman1dir=… -Dman3dir=… -Dman1ext=1 -Dman3ext=3`) y NO se aplica hoy:

    yupana radio perl → transitivos 347 · sellados que CAEN a deuda 305 · TODAS las imágenes

305 rebuilds para mover páginas de man de sitio no se paga solo. Queda escrito en la receta para ir
con el próximo bump de perl, cuando el re-hash ya esté pagado. Comprobado que el comentario NO entra
en `hash_inputs`: el ArtifactHash es idéntico antes y después (b3:1af26f6b).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CGyBj4QyeCZiwLMkP9GJp6
 2026-09-04 02:27:22 +00:00
SergioandClaude Opus 5 b08212a7f1 waypipe: el escritorio en una ventana — ciclo de segundos, y el hueco de la libc queda medido 
Dos piezas para mirar la distro sin QEMU, que es lo que hacía falta para cazar el puntero
invisible: ese defecto no lo ve ninguna métrica de clausura Y TAMPOCO una captura headless — el
cursor no está en el framebuffer que devuelve screencopy. Hay que mirar la ventana.

`hydrate-profile.py <perfil>`: proyecta el cierre ENTERO de un perfil de `targets.toml`. Los
`hydrate-*.sh` por escritorio traen la lista de raíces escrita a mano dentro del script, o sea DOS
fuentes de verdad: hoy mismo se añadió `adwaita-cursors` a cosmic y sway y esos scripts —que no la
conocen— habrían seguido armando un rootfs sin cursores mientras el perfil decía que los lleva.
Acá el cierre sale de `yupana.membresia()`, la misma función que usan build-state y vigia-imagen.

Y trae la sonda que costó dos intentos: `hydrate` ENLAZA, y `linkat()` no cruza un punto de
MONTAJE aunque sea el mismo disco. El store y `work/out` son dos binds del mismo /dev/sdb ⇒
`st_dev` COINCIDE y el hardlink falla igual. La primera versión comparaba `st_dev` y no disparó:
salieron 174 «artefactos que no proyectaron» y un rootfs de 272 ficheros con pinta de problema de
recetas. Ahora la sonda es FUNCIONAL —se intenta un enlace de verdad— y el error nombra el montaje
del store.

`sway-nested.sh`: arranca `escritorio-sway` como ventana del compositor que ya tenés delante.
Evidencia de esta corrida, con el rootfs hidratado del perfil:

    [wlr] [xcursor] Loaded cursor theme 'default' at size 24 (62 available cursors)

o sea el tema llamado literalmente `default` —el alias que fabrica `adwaita-cursors`— resolviendo
a los 62 cursores de Adwaita. Antes de hoy esa línea no existía.

Tres cosas que sólo salen corriéndolo:
· **Ningún perfil incluye `musl`.** Ni `base`. El cierre de escritorio-sway no trae UN `ld-musl` y
  sway es `link=dynamic` con intérprete `/lib/ld-musl-x86_64.so.1`: la libc sale del bootstrap, no
  de una receta del perfil. Por eso el arnés monta DOS overlays. No es un bug, pero no estaba
  escrito en ningún lado y un rootfs de perfil solo no arranca.
· **`yambar` no va en `bar { status_command … }`**: es una barra completa de layer-shell, no un
  productor de estado para swaybar. Puesta ahí, sway rechaza la config ENTERA y arranca pelado —
  se lee como «el escritorio está roto» cuando lo único mal es una línea.
· **`grim` hay que apuntarlo al socket de NUESTRO sway.** Adentro `WAYLAND_DISPLAY` es el del HOST
  (es lo que sway necesita para nestear), así que un `grim` a secas devuelve una captura perfecta…
  del escritorio de al lado. La primera captura fue exactamente eso.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CGyBj4QyeCZiwLMkP9GJp6
 2026-09-04 01:56:45 +00:00