e9b71b5c7ba0a18f764d3ab8cc35b2e545300ff4
11
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 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. |
||
|
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. |
||
|
SergioandClaude Opus 5
|
b6d000eca3 |
atuq-nested: el runner medía un rootfs MÁS POBRE que la imagen, y su caché no cacheaba
Tres cosas en el mismo fichero, las tres medidas hoy: 1. `ffmpeg` y `libva` entran a las raíces. NO son recetas nuevas: las dos están selladas en el corpus y ya viven en la clausura de los cuatro escritorios, arrastradas por `mpv` (verificado con `yupana.membresia`, no leyendo el TOML). Faltaban acá, o sea que el runner abría un rootfs sin libavcodec y desde ahí se concluía que la imagen no tiene códecs. El instrumento otra vez, no el artefacto. 2. El bucle de hidratación salía 1 SIEMPRE: `$VIGENTES` termina en `\n`, `echo` agrega otro, la última vuelta lee la línea vacía, `[ -n "$d" ]` da 1 y con `set -e` el script moría sin imprimir una sola línea, justo después de hidratar bien las 41 raíces. Ahora `continue` en la vacía y un `hydrate` que falla grita. 3. La comparación del sello NUNCA daba igual: el lado izquierdo lleva su `\n` final y `$(cat …)` lo recorta ⇒ «DESACTUALIZADO» en cada corrida y 3013 ficheros rehidratados de más. Los dos lados pasan ahora por la misma sustitución de comandos. Y `ROOTFS_ONLY=1`, que corta después de hidratar: lo necesita el guardián de códecs, que corre headless y tiene que usar ESTA lista de raíces y no una copia. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs |
||
|
SergioandClaude Opus 5
|
6886b1541c |
libnotify: el primer hueco que el mapa del §6.10 encontró Y cerró
`libxul.so` lleva la cadena `libnotify.so.4` adentro y la abre por dlopen cuando
una página pide permiso para notificar. Nadie en el corpus la proveía, así que la
función quedaba apagada SIN UN SOLO MENSAJE: el navegador arranca, la web pide
notificaciones, y no pasa nada. No lo veía ninguna herramienta porque no hay
NEEDED en ningún ELF — es el tercer escalón, y sobrevivió a vigia-sonames con los
cinco perfiles en CERO.
Receta nueva, 0.8.8, SÓLO en variante compartida y eso no es un olvido: a un
`dlopen("libnotify.so.4")` una `.a` no le sirve de nada, así que una receta
estática sería un artefacto que nadie puede consumir.
Dos cosas que la receta se comió y quedan escritas:
1. `libpng-shared` hace falta porque las deps de hammer NO son transitivas: el
`.pc` de gdk-pixbuf-2.0 declara `Requires: libpng` y el meson muere con un
mensaje que nombra a gdk-pixbuf —que sí está— en vez de a lo que falta.
2. El guardián informaba «18 bytes» y parecía una librería vacía: `stat -c%s` no
sigue el symlink, y `libnotify.so.4` apunta a `libnotify.so.4.0.0`. El
artefacto estaba bien y el MENSAJE mentía. Con `-L` son 162.928 bytes. Se
arregla el mensaje porque es lo que alguien va a leer a las tres de la mañana,
y de paso el guardián exige el fichero real, no sólo el nombre.
⚠ Y lo que NO arregla, escrito en la receta para que nadie lea de más: libnotify
no trae daemon, manda org.freedesktop.Notifications por D-Bus. Tenerla resuelve
la mitad —que firefox la encuentre—; la otra mitad es que en la imagen haya
alguien escuchando ese nombre.
Verificado con el propio mapa: `--dlopen` pasa de 25 huecos a 24 y libnotify.so.4
desaparece; el soname viejo `.so.1` se reclasifica de «hueco» a «ruido», que es lo
que ahora es. El guardián normal sigue en CERO con un soname más pedido (66).
Queda pendiente la membresía de perfil en `docs/state/targets.toml`, que es
catálogo compartido y no lo toco sin decidirlo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
|
||
|
SergioandClaude Opus 5
|
a20d1b7453 |
atuq: un guardián para el rootfs del runner — y encontró SIETE sonames más cayendo al lab
La lista de raíces de `atuq-nested.sh` se mantiene A MANO y la jaula monta
`.dev-fs/alpine` como capa de abajo. Esas dos cosas juntas hacen que una raíz que
falte NO se note: el navegador arranca igual, resolviendo contra el lab. Ayer eso
costó `gcc-libs`. La regla del repo es que cada punto ciego se convierte en un
guardián, así que acá está el guardián en vez del parche.
`scripts/test-atuq-rootfs.py` mira el objeto que la jaula monta de verdad —el
directorio HIDRATADO— y no el grafo de recetas, que es lo que ya cubre
`vigia-sonames.py`. Son preguntas distintas: la lista del runner no sale del
grafo, así que el grafo no puede auditarla.
Lo primero que hizo fue encontrar SIETE sonames más que se estaban resolviendo
contra el lab, y no son cosmética:
libexpat.so.1, libzstd.so.1 <- los pide mesa (iris_dri, libEGL, libgbm)
libdbus-1.so.3 <- lo pide pipewire; lo trae `dbus-shared`, no `dbus`
libbz2.so.1 <- freetype
libudev.so.1 <- libspa-alsa
libsndfile.so.1, libncursesw.so.6
Los siete tienen proveedor en el corpus. Agregados a las raíces: el rootfs pasa
de 7 huecos a CERO, y la única excepción que queda es `libc.so`, que va en una
lista explícita porque ningún artefacto lo provee — las imágenes lo copian del
devfs. Si algún día hay receta que lo provea, esa lista se achica y el guardián
se vuelve más estricto solo.
CONTROL NEGATIVO incluido, que sin él esto no probaría nada:
`--negative-control` esconde libstdc++.so.6 y exige que el guardián lo cace.
Corrido: lo caza, y nombra a quién lo pide (atuq, atuq-bin).
Y `scripts/test-atuq-ruteo.py` vuelve a pasar entero contra el rootfs completo,
o sea que el ruteo por contenedor está probado ahora sobre un rootfs que no le
pide nada al lab salvo el intérprete.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
|
||
|
SergioandClaude Opus 5
|
7389d44569 |
atuq-nested: faltaba gcc-libs, y su ausencia hacía MENTIR a la prueba entera
`atuq` declara `NEEDED libstdc++.so.6` y `libgcc_s.so.1` —lo hereda de firefox, que va con clang++ y la libstdc++ COMPARTIDA— y su clausura ya estaba bien: `recipes/atuq.toml` declara `runtime = ["gcc-libs"]` desde |
||
|
Sergio
|
52d3bbfeb3 |
atuq-nested: CAPTURA=<png> — la prueba en el píxel, en una variable
Durante horas dije «mirá tu pantalla» y reporté «el proceso vive» como si fuera lo mismo. No lo es: la ventana estaba ahí desde el principio y lo que fallaba era el branding DENTRO del zip, que ningún log iba a contar. `grim` ya estaba en el corpus (`incoming-wlr`), se hidrata en el mismo rootfs y captura la pantalla real contra el mismo socket wayland desde dentro de la jaula. Ahora es parte del runner: con `CAPTURA=/ruta/foto.png` se lanza atuq, se espera a que pinte y se deja el PNG afuera para mirarlo. De paso, la resolución de raíces prueba el corpus Y `incoming-wlr`, en ese orden — el mismo que usa la resolución de deps (sibling-first, luego el catálogo padre). Sin eso, `grim` no se encontraba y el script habría dicho «falta un artefacto» sobre una receta que existe. |
||
|
Sergio
|
5d06a3b83d |
atuq ABRE: el app_id estaba compilado en el binario, y el árbol copiado llegaba de sólo lectura
Con la cadena GTK3 arreglada, atuq arrancó de verdad: parent vivo, CERO procesos de contenido muertos, y pintando una página local. Quedaban dos cosas. 1. SE ANUNCIABA COMO `firefox-default`. El application.ini decía RemotingName=atuq y aun así el proceso se presentaba así — porque esa cadena es un MOZ_APP_REMOTINGNAME horneado en el ELF, y es la que Gecko pasa a g_set_prgname(), o sea el **app_id de Wayland**. Consecuencia visible: el escritorio no casaba la ventana con nuestro .desktop (StartupWMClass=atuq) ⇒ icono genérico y sin agrupar. Se parchea EN SITIO, no recompilando: cambiarlo en recipes/firefox.toml brandearía la BASE como atuq, y firefox tiene que seguir siendo firefox para los otros forks. Es seguro porque es una cadena C terminada en NUL en el pool de .rodata —`firefox-default\0` son 16 bytes exactos y se escriben 16—, y se EXIGE una única ocurrencia: si upstream la duplica o la renombra, falla en vez de parchear el sitio equivocado. Verificado después: 0 ocurrencias de la vieja, y el log dice `(atuq:26423)`. 2. UN BUG QUE SÓLO SE VE FUERA DE ROOT. `cp -a` preserva los modos y los ficheros del store están sellados sin permiso de escritura; todo lo que viene después los modifica. En el worker pasaba inadvertido porque corre como root, que ignora los bits. El primer build local murió con `PermissionError: /out/usr/lib/atuq/application.ini`. Se arregla con `chmod -R u+w` en la receta y no en el entorno: un artefacto no debe depender de con qué uid lo construiste. Y el runner pasa a hidratar las variantes `-shared`: en runtime una `.a` no sirve de nada, y son las que gtk3 declara NEEDED desde el arreglo del cuadro de las dos Pango. Este atuq se construyó EN LOCAL en segundos, que era la promesa entera del diseño derivado del SDD 26: iterar el envoltorio sin volver a pagar un build de Gecko. |
||
|
Sergio
|
a828e74c40 |
la cadena GTK3 se enlazaba estática dentro de dos .so: cuatro variantes -shared y xkeyboard-config al corpus
Con `atk` arreglado, atuq llegó más lejos y murió igual, ahora con Pango:
GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
… decenas de líneas … tipo '<invalid>'
MISMO CUADRO, CULPABLE DISTINTO Y MÁS GRANDE. `gtk3` produce DOS objetos compartidos —libgtk-3.so y
libgdk-3.so— y libxul declara NEEDED las dos, así que se cargan siempre juntas. Con las variantes
ESTÁTICAS de sus deps, cada una se llevaba adentro su propia copia. Medido con el mismo instrumento
que cazó a atk, `nm -D --defined-only`, preguntando quién DEFINE cada símbolo:
pango_font_map_get_type → libgdk-3.so, libgtk-3.so, libgailutil-3.so
cairo_create → libgdk-3.so, libgtk-3.so
gdk_pixbuf_get_type → libgdk-3.so, libgtk-3.so
hb_buffer_create → libgdk-3.so, libgtk-3.so, libgailutil-3.so
Y se comprobó el otro lado: libxul NO embebe ninguna —enlaza libgtk-3/libgdk-3 como debe—, así que
la duplicación es toda interna del par GTK3.
Cuatro variantes nuevas: harfbuzz-shared, cairo-shared, gdk-pixbuf-shared, pango-shared. Sólo cambia
el modo de librería; se conservan todos los switches del canónico para no arrastrar deps nuevas.
DOS DEUDAS ANOTADAS, NO OLVIDADAS: `fribidi` y `pixman` siguen estáticos —no existe variante— pero
quedan embebidos en UNA sola .so cada uno, así que no hay copia que colisione; y `libepoxy` sí queda
en las dos, y se deja porque no registra tipos de GObject ni mantiene estado global. Si algún día
otra .so del mismo proceso los embebe, vuelve el cuadro.
`firefox` swapea las mismas cuatro: declarar las ESTÁTICAS junto a un gtk3 que trae las compartidas
son dos artefactos peleando por el mismo `pango.pc`, que es la otra forma conocida de este fallo.
Y `xkeyboard-config` SUBE AL CORPUS. Existía idéntica en las cuatro colas de escritorio (un solo md5
entre las cuatro, verificado antes de mover) y atuq, que vive en el corpus, no podía alcanzar
ninguna: sibling-first y después el catálogo padre, nunca una cola hermana. Sin sus datos el
navegador ni pinta («xkbcommon: failed to add default include path /usr/share/X11/xkb»). Mismo hash
en el corpus que en las colas ⇒ cero rebuilds, y las copias de las colas se quedan donde están.
|
||
|
Sergio
|
d2527284b9 |
atuq-nested: el rootfs se revalida por HASH, no por existencia
El script daba por bueno el rootfs si el directorio estaba: «¿ya está hidratado?». Es la pregunta equivocada. Tras el re-hash de la cadena atk→gtk3→firefox→atuq el directorio seguía ahí con los artefactos VIEJOS, así que habría abierto contento la versión que acabábamos de arreglar y el diagnóstico habría sido buscar en el sitio equivocado. Misma forma del cache-hit que congela regresiones. Ahora resuelve los hashes vigentes, los anota en `.raices` y rehidrata cuando difieren. De paso: nada de `diff <(...)`, que es de bash. El shebang dice /bin/sh y un script que sólo anda cuando /bin/sh resulta ser bash es una trampa que salta en otra máquina. |
||
|
Sergio
|
0f7d19232e |
atuq: el lanzador deja de ser un symlink, y un runner para abrirlo en la pantalla que ya tenés
Dos cosas que salieron de intentar ABRIRLO, que es lo único que distingue «sellado» de «usable».
1. EL LANZADOR. Con `/usr/bin/atuq` como symlink, el navegador moría antes de pintar:
XPCOMGlueLoad error for file /usr/lib/atuq/libmozsandbox.so:
Error loading shared library libnspr4.so: No such file or directory
El motor carga sus propias librerías desde `/usr/lib/atuq` y ni el binario ni esas `.so` traen
RPATH/RUNPATH — comprobado con `readelf -d`, no supuesto. Pasa a ser un script que exporta
`LD_LIBRARY_PATH` (lo mismo que hacen Debian y Fedora) y hace `exec`, para que el proceso que
queda sea el motor y `/proc/self/exe` siga resolviendo el appdir. El `LD_LIBRARY_PATH` además
tiene que HEREDARSE: Firefox lanza un proceso por pestaña y todos cargan las mismas librerías.
La alternativa limpia es grabar RPATH=$ORIGIN con `patchelf` —es lo que hace Alpine— pero
`patchelf` todavía no existe como receta del corpus; cuando exista, esto vuelve a ser un symlink.
2. `scripts/atuq-nested.sh` — hidrata el cierre de runtime y abre atuq como ventana anidada en el
compositor que ya está delante (waypipe, mirada, sway). Trae dos cosas aprendidas a golpes:
· EL ROOTFS VA EN EL MISMO MOUNT QUE EL STORE. `hydrate` proyecta con hardlinks y `linkat()`
rechaza cruzar un punto de montaje aunque sea el mismo filesystem. Acá el store es /dev/sdb
bind-monteado y `work/` vive en /dev/sdc: hidratar a `work/…` muere con «Invalid cross-device
link (os error 18)». El volumen entero está en /mnt/cosecha, así que el rootfs va ahí. Se
comprueba con `findmnt -T`, nunca con `stat -c %d`.
· `dejavu-fonts` va en las raíces por necesidad, no por completismo: un navegador sin una sola
fuente arranca, pinta y muestra cuadraditos. Ya nos costó una tarde en GNOME.
Y no saltea en silencio: si falta un artefacto de la lista, sale con error en vez de armar un
rootfs al que le faltan tres paquetes y falla tres capas más abajo.
|