Sin esta línea la receta queda sellada y en NINGUNA imagen — la lección de `foot`
que este mismo fichero tiene escrita cuatro renglones más arriba de `atuq`, y que
la clausura no puede ver porque mide lo declarado.
Va en los cuatro perfiles que ya llevan el navegador (kde, gnome, cosmic, sway) y
NO en base/cli/mirada, que no lo llevan. Verificado parseando el TOML y no
leyéndolo: libnotify=1 en esos cuatro, 0 en los otros tres.
Medición al lado, con el vigía de sonames antes y después:
kde 306 -> 307 nodos 2083 -> 2086 sonames 0 sin proveedor
gnome 190 -> 191 657 -> 660 0
cosmic 161 -> 162 498 -> 501 0
sway 201 -> 202 509 -> 512 0
mirada 41 -> 41 231 -> 231 0 (no lleva atuq)
+1 nodo exacto por perfil, que es lo que se agregó, y el que no lo lleva no se
movió. Si hubiera arrastrado algo sin querer, el delta no sería 1.
Y una comprobación que el mapa de §6.10 no da y que es la que decide si el
`dlopen` va a funcionar: que resuelvan las deps de la PROPIA librería. Un dlopen
falla en silencio igual si libnotify está pero su gdk-pixbuf no. Se lo pregunté
al loader musl, no a mí:
ld-musl --list /usr/lib/libnotify.so.4
libgdk_pixbuf-2.0.so.0 => /usr/lib/... libgobject-2.0.so.0 => /usr/lib/...
libglib-2.0.so.0 => /usr/lib/... libgio-2.0.so.0 => /usr/lib/...
libc.so => /lib/ld-musl-x86_64.so.1
Toda la cadena cae dentro del rootfs salvo libc.so, que es la excepción del lab
ya documentada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
`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
hammer-9f nombró el punto ciego que ni su vigía ni mi guardián podían cubrir:
una librería que sólo aparece como CADENA LITERAL dentro de un dlopen(). No hay
NEEDED en ningún ELF, así que ningún auditor de readelf la encuentra. La
jerarquía queda:
NEEDED del ejecutable -> lo vemos los dos
NEEDED de un .so dlopeado -> lo vemos los dos
dlopen("libfoo.so.1") literal -> NO LO VE NINGUNO
Y un navegador vive de eso. Firefox sondea ffmpeg, VA-API, vulkan y libnotify
por nombre, y cuando no están NO FALLA: apaga la función y sigue. No hay línea
roja; hay una función que nadie ofrece y nadie reclama. Es la forma que ya costó
caro con OBS y su dlopen("libGL.so.1").
`--dlopen` busca esas cadenas y las cruza contra el rootfs. Es un HEURÍSTICO y se
declara como tal —una cadena no prueba un dlopen y su ausencia no prueba que no
lo haya—, así que no falla nunca: imprime un mapa triado. Lo afirmable es lo
contrario, que es lo útil: si la cadena está y el fichero no, esa función no
existe en esta imagen.
De 85 cadenas, 47 sin proveedor. Siete son huecos de verdad:
códecs del sistema (H.264/AAC) sin receta de ffmpeg — el más caro
notificaciones web sin receta
llavero (libsecret) RECETA YA EXISTE en incoming-gnome
sonidos (libcanberra) receta en incoming-kde
WebGPU (vulkan-loader) receta en incoming-kde
vídeo por hardware (VA-API) sin receta
lectura en voz alta sin receta
Tres de los siete son promoción, no autoría. Ocho son decisiones ya tomadas
(libGL por Wayland-only sin GLX; libcurl porque sólo lo usa el pingsender de
telemetría) y siete son ruido de musl o sonames viejos. El triaje va en una tabla
del propio script, no escondido en un `if`, porque es criterio y no medición: ahí
se puede discutir.
Sin triar: 0. Si aparece una cadena nueva, el informe la marca «SIN TRIAR» en vez
de tragársela.
Lo que esto cambia de fondo: hasta hoy la pregunta era «¿arranca?» y la respuesta
era sí. La que faltaba era «¿y qué NO puede hacer?», que ninguna métrica del repo
respondía porque todas miran presencia y ésta mira ausencia declarada por el
propio binario.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
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
Siete recetas decían «lo vigila `scripts/audit-needed.sh`» y ese script ya no
existe: lo borré yo mismo en 02facebe, bien borrado, porque duplicaba a
`scripts/vigia-sonames.py` — que además ya estaba en el repo y ahora corre en el
latido. Pero las referencias quedaron, escritas por mí unas horas antes.
Es exactamente la etiqueta que se lee como el hecho, y en mi propia letra: un
comentario que afirma que existe un guardián manda a quien dude de una dep de
runtime a correr un script que no está. En el mejor caso pierde diez minutos; en
el peor concluye que no hay con qué comprobarlo.
Ahora apuntan a `vigia-sonames.py` y a `docs/state/sonames.txt`, que es el
fichero que el latido regenera y donde se ve si algo empeora entre cosechas.
Ningún ArtifactHash se mueve: los siete comentarios caen fuera de campos
hasheados. Verificado uno por uno antes y después, incluido
firefox-instrumentado, que tiene un build en vuelo y se habría invalidado.
Lo levantó hammer-99 desde el frente atuq. `recipes/atuq.toml` NO se toca: su
mención es una nota histórica ya corregida por ellos («…y NO audit-needed.sh»),
y mi primer grep casi la «arregla» por no leerla.
Y la advertencia que traían vale para cualquiera con pruebas de runtime: si el
runner monta `.dev-fs/alpine` debajo, `libstdc++.so.6` se resuelve contra el LAB
y la prueba es ciega. Comprobado que la mía NO lo estaba: el rootfs hidratado
trae el del corpus (20.850.968 bytes) y no el del lab (2.804.104), y el bwrap de
la prueba nunca montó .dev-fs.
`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 5b9777bd, yupana lee
`deps.runtime` desde 02facebe, y el vigía de sonames da CERO en los cinco
perfiles (rehecho hoy: 41/306/190/161/201 nodos, 0 sin proveedor).
Lo que estaba mal era el INSTRUMENTO. `atuq-nested.sh` no hidrataba `gcc-libs`, y
como la jaula monta `.dev-fs/alpine` como capa de abajo, cada «atuq corre» de
estos días resolvió libstdc++ contra el LAB. Corría, sí: en una máquina con
Alpine debajo, que es exactamente lo que la distro no es. El artefacto estaba
sano y la prueba era ciega — que es peor, porque una prueba ciega dice que sí.
Los dos ficheros ni se parecen, así que la duda se resuelve mirando:
corpus 20.850.968 bytes
lab 2.804.104 bytes
Con `gcc-libs` en las raíces, dentro de la jaula se ve el de 20 MB, y
`scripts/test-atuq-ruteo.py` vuelve a pasar entero — o sea que el ruteo por
contenedor está probado ahora contra la libstdc++ del corpus y no contra la del
lab. Queda una dependencia del lab que NO es de esta prueba y está por diseño: el
intérprete `/lib/ld-musl-x86_64.so.1`, que ningún artefacto provee y que las
imágenes copian del devfs (`scripts/mirada-usb.sh`).
De paso, un puntero muerto: las recetas dicen «lo vigila scripts/audit-needed.sh»
y ese script lo BORRÓ 02facebe al reemplazarlo por el vigía de sonames. Corregido
en atuq.toml. Quedan otras siete recetas apuntándole (firefox, waterfox,
gcc-libs, mesa-llvmpipe, librsvg, spidermonkey, firefox-instrumentado) y no se
tocan desde acá porque son de otro frente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
libclang_rt.profile.a, 129.178 bytes — la que implementa los __llvm_profile_* y
escribe los .profraw. Hermana nativa de wasi-compiler-rt: mismo tarball de LLVM
22.1.8, mismo patrón, mismo sitio de aterrizaje; cambia el target (x86_64 en vez
de wasm32) y el componente (profile en vez de builtins).
Lo destapó el build del firefox instrumentado, en el minuto 38:56:
ld.lld: error: cannot open
/usr/lib/llvm22/lib/clang/22/lib/x86_64-alpine-linux-musl/libclang_rt.profile.a
El lab trae clang 22.1.8 con su include/ pero el lib/ del resource dir NO EXISTE
— que es exactamente lo que wasi-compiler-rt ya documentaba para el caso wasm.
O sea: el PGO no estaba bloqueado por el display (eso se despejó ayer) sino por
una pieza de toolchain que nunca hizo falta hasta ahora.
Se apaga todo menos profile: compiler-rt trae sanitizers, xray, memprof, orc y
ninguno tiene destinatario acá.
La primera corrida murió en el configure con «CMAKE_C_COMPILER_TARGET must also
be set when COMPILER_RT_DEFAULT_TARGET_ONLY is ON» — un error de cmake que dice
exactamente qué falta, cosa que no se puede dar por supuesta esta noche.
Dos guardianes. El primero exige la RUTA LITERAL del error y no «alguna
libclang_rt»: el layout per-target es una opción de cmake y equivocarla deja la
librería donde clang no mira, que es el mismo fallo que la libstdc++ en
/usr/lib64 de hace unas horas. El segundo es la prueba del consumidor: que
DEFINA __llvm_profile_write_file y compañía, para que un .a vacío no se descubra
al final de una corrida de perfilado.
Al reescribir el §6.8 corté el texto entre «lo que NO está probado» y `## 7`, y
entre medio no había sólo eso: vivían ahí §2.ter (el modo `[source] dir`),
§2.quater (los tres fallos que destapó abrirlo en pantalla), §2.quinquies (los
tres mecanismos de la v0.3) y §2.sexies (lo que quedó probado y con qué). Ciento
veinte líneas de método pagado con horas.
Recuperadas de HEAD~1 y comprobadas byte a byte con `diff` contra el original, no
a ojo.
La causa, que es la de siempre en este repo: usé un ANCLA («hasta el próximo
`## 7`») dando por hecho que el documento estaba en el orden en que yo lo
imaginaba. El §6.8 lo había insertado yo mismo antes del §2.ter hace unas horas,
así que el ancla saltaba por encima de cuatro secciones. Un ancla es una
etiqueta, no una propiedad del documento — la misma familia que la cabecera de
hunk que nombra la función anterior.
Lo que lo hizo visible en el mismo minuto fue mirar el `git show --stat`: 210
líneas cambiadas en un fichero donde yo había escrito 45. La regla 2 del
CLAUDE.md manda mirarlo para el ALCANCE del commit, pero sirve igual para el
tamaño del cambio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
Era lo único que la v0.5 dejó sin probar, y las tres puertas que había
encontrado siguen cerradas: no hay flag de línea de comandos para el
userContextId, Marionette no toma `-remote-allow-system-access` en la jaula, y
`tabs.create({cookieStoreId})` exige el permiso `cookies` — que no se le da a la
extensión del proxy sólo para que pueda probarse a sí misma.
La cuarta puerta estaba abierta: el fichero de SESIÓN guarda el userContextId de
cada pestaña y Gecko lo restaura. Se fabrica a mano — `mozLz40\0` + tamaño + un
bloque LZ4, y un bloque de sólo literales es LZ4 válido: veinte líneas, sin
librería.
Y la medición no le pregunta nada al navegador: le pone dos oídos en la red y
mira a cuál llama. Dos pestañas piden la MISMA url, una sin contenedor y otra en
«Banco»:
al destino (8099) GET /directo <- la de sin contenedor, directa
al proxy (9099) \x05\x01\x00 <- saludo SOCKS5 de la de «Banco»
Ese saludo sólo aparece si Gecko decidió hablar con un proxy para esa petición, y
el único que se lo pudo indicar es proxy.onRequest mirando el cookieStoreId. La
pestaña sin contenedor no es decorativa: sin ella, «todo fue por el proxy» y «el
ruteo anda» se verían iguales.
CONTROL NEGATIVO, que es lo que este repo se exige desde hoy: con
`--negative-control` no se configura el proxy y se exige lo contrario — las dos
pestañas directas y nadie llamando al proxy. Corrido: pasa. La única diferencia
entre las dos corridas es una línea de configuración y el observable se da vuelta
entero. Sin ese modo, una prueba que se hubiera vuelto ciega se vería idéntica a
una que funciona.
Tres detalles sin los cuales la prueba mide un silencio y se lee como fallo:
restore_on_demand=false, allow_hijacking_localhost=true, y el
triggeringPrincipal_base64 en cada entrada de sesión.
El artefacto se resuelve por `hammer hash` y no por glob, que es la lección de
hammer-03 de esta madrugada: con dos artefactos de la misma receta en el store,
`ls | head -1` es una ruleta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
NO hacía falta una receta de perl. `libperl.so` está en el artefacto, son 9,6 MB
en usr/lib/perl5/5.40.2/x86_64-linux/CORE/, y el binario la encuentra por su
RUNPATH, que apunta justo ahí. El vigía no la veía porque perl la construye con
-Duseshrplib y NO le pone SONAME: el código sólo registraba el nombre del fichero
`if son:`. Un ELF compartido sin SONAME se resuelve POR NOMBRE DE FICHERO, y eso
es exactamente lo que había que indexar.
El otro falso positivo era el último «hueco» del informe:
usr/lib/go/src/debug/elf/testdata/libtiffxx.so_ — un ELF de MUESTRA que Go
shipea para los tests de su propio paquete debug/elf, pidiendo libc.so.6 (glibc)
en una distro musl. Un binario que nadie ejecuta. `testdata/` no es cierre.
Importa arreglar un falso positivo aunque «sólo» sea ruido: un vigía que grita
en falso enseña a ignorarlo, y así es como libstdc++.so.6 —que SÍ rompía el
navegador en los cuatro escritorios— estuvo en esta misma salida sin que nadie
la mirara.
escritorio-mirada 41 nodos · 231 sonames · 0 sin proveedor
escritorio-kde 306 nodos · 2083 sonames · 0 sin proveedor
escritorio-gnome 190 nodos · 657 sonames · 0 sin proveedor
escritorio-cosmic 161 nodos · 498 sonames · 0 sin proveedor
escritorio-sway 201 nodos · 509 sonames · 0 sin proveedor
PROBADO CON UNA ROTURA A PROPÓSITO, porque un vigía todo-verde se ve igual que
uno roto. Quitando `runtime = ["gcc-libs"]` de firefox SOLO no pasa nada —atuq
lo declara también y es raíz de los mismos perfiles, así que la librería entra
igual; el primer control estaba mal montado—. Quitándolo de las DOS, kde y
cosmic vuelven a reportar libstdc++.so.6 y libgcc_s.so.1 exactamente. Restaurado
después.
Tres arreglos que son el mismo: un campo que nadie lee es un campo que miente.
1. yupana._deps() leía SÓLO `deps.build`. Como yupana es la base de todas las
herramientas de grafo, una dep de EJECUCIÓN no existía para ninguna: ni el
vigía de sonames, ni la membresía de perfiles, ni el rootfs hidratado.
Medido: firefox declaraba `runtime = ["gcc-libs"]` y el cierre de las cuatro
imágenes seguía sin libstdc++.so.6, así que el navegador no arrancaba y el
vigía lo seguía reportando como hueco DESPUÉS de haberlo arreglado.
`deps.runtime` está en el esquema de hammer desde siempre. La unión es la
definición de cierre: para CORRER hacen falta las dos.
2. build-state.py, lo mismo y por lo mismo.
3. El vigía entra en el LATIDO y deja docs/state/sonames.txt. Existía desde
antes y contesta la pregunta que el grafo no contesta —no «¿está sellado?»
sino «¿arranca?»— pero NADIE LO CORRÍA: no estaba en cosecha-cron y no dejaba
fichero de estado. Por eso libstdc++.so.6, que rompía el navegador en los
CUATRO perfiles, estuvo en su salida sin que nadie lo leyera, y se
redescubrió arrancando atuq a mano. Un vigía que hay que acordarse de invocar
no se distingue de no tenerlo.
Y se BORRA scripts/audit-needed.sh, que escribí ayer sin ver que vigia-sonames.py
ya hacía exactamente esto, con la misma frase en la cabecera. Dos herramientas
que miden lo mismo divergen y la que nadie mira es la que miente; la que se
queda es la que ya existía, que además reporta POR PERFIL y encontró más cosas.
python3 declara sus cuatro deps de ejecución (readline/sqlite/lzma/bz2): son
módulos de la stdlib que se cargan por dlopen, así que no rompen el arranque
sino un `import` — un fallo que aparece lejos y no menciona a python.
Resultado, con todo aplicado: 29 huecos -> 6, y los que quedan son otra clase.
`libperl.so` es empaquetado de la receta perl; `libc.so.6` lo pide el `go`
prebuilt y es un soname de GLIBC en una distro musl, que es un síntoma distinto.
Los dos quedan anotados en docs/state/sonames.txt, que ahora se regenera solo.
libreadline.so.8, 970.144 bytes. Hermana de ncurses-shared y por la misma fuga:
python3 y sqlite-shared salen con NEEDED libreadline.so.8 y la readline del
catálogo es --disable-shared, así que sólo produce libreadline.a. En el rootfs
hidratado eso se resolvía contra el sysroot Alpine DEL LAB.
Versión 8.2 y no la 8.3.3 de Alpine, a propósito: es la que ya usa
recipes/readline.toml y tener las dos variantes en versiones distintas es pedir
que diverjan sin que nadie lo note.
TRES GUARDIANES, y el segundo es de Alpine casi literal. readline sale MAL
ENLAZADA por diseño de upstream —libreadline.so no enlaza contra ncurses salvo
que se lo fuerces, y queda con tgetent y compañía sin resolver—; Alpine lo
arregla con un parche y con un check que falla si el NEEDED de ncurses no
aparece. Acá se consigue sin parche con SHLIB_LIBS=-lncursesw, que es la perilla
que el propio Makefile expone. El guardián verifica que quedó enlazada, porque
si no el fallo reaparece en el consumidor, a un eslabón de distancia y sin
nombrar a esta receta.
La dep es ncurses-shared y no ncurses: con la estática, libreadline.so.8 se
llevaría los objetos de libncursesw.a dentro en vez de declarar el NEEDED — la
misma lección que el cairo estático de waterfox.
Se promueve además sqlite-shared de incoming-gnome al catálogo canónico: python3
la necesita como dep de ejecución y una receta de recipes/ no ve las de una
cola. Sin variantes en conflicto y ya sellada, así que la promoción no cuesta un
build.
Las seis recetas que el audit daba por colgantes declaran ahora
`runtime = ["gcc-libs"]`. `deps.runtime` NO entra en el ArtifactHash —medido:
firefox sigue en b3:8116bdec, atuq en b3:f2960991, waterfox en b3:88b5a762—
así que esto NO reconstruye nada. Lo que cambia es la CLAUSURA, que es lo que se
hidrata en la imagen.
EVIDENCIA DE QUE ARREGLA EL FALLO REAL, no de que compila: `atuq` bajo sway
headless, sin GPU, renderizando about:buildconfig con sus tablas y la barra de
contenedores de la v0.5. Antes moría con decenas de «Error relocating:
_ZNKSt5ctypeIcE13_M_widen_initEv: symbol not found».
docs/evidencia/atuq-arranca-con-gcc-libs-2026-09-06.png
Y el audit se corrige, porque SUB-REPORTABA en dos formas:
· Miraba sólo ejecutables y `head -12` por artefacto. El siguiente NEEDED que
faltaba estaba en una LIBRERÍA (libmozsandbox.so pedía libnspr4.so), así que
daba «6 recetas» cuando el artefacto de firefox declara 30 sonames. Ahora
recorre TODOS los ELF.
· No contaba lo que el propio artefacto TRAE. Firefox bundlea su nspr/nss y
las encuentra por el LD_LIBRARY_PATH que fija su lanzador; contarlas como
colgantes era un falso positivo.
Con las dos correcciones y gcc-libs en el store, el corpus baja de 25 artefactos
colgantes a TRES, y son otra cosa:
sqlite-shared libreadline.so.8
python3 libreadline.so.8
naabu libdl.so.2 libpthread.so.0 libc.so.6
Los dos primeros piden una receta que falta (readline). El tercero pide sonames
de GLIBC, que en una distro musl es un síntoma distinto y merece su propia
mirada. Quedan anotados, no arreglados.
libstdc++.so.6 (20.850.968 bytes) y libgcc_s.so.1 (824.776), construidas desde
el tarball de GCC 15.2.0 — la MISMA versión del lab, porque firefox se enlaza
contra la libstdc++ compartida de ese gcc y otra versión traería de vuelta el
mismo fallo disfrazado. sha512 del tarball verificado byte a byte contra el
APKBUILD de Alpine.
Tres decisiones que no son de estilo:
--disable-symvers Alpine lo pasa. El versionado cambia la tabla de símbolos;
nuestros binarios se enlazaron contra la libstdc++ SIN
versionar del lab.
link = "dynamic" hammer inyecta LDFLAGS=-static por defecto y acá el
producto ES una librería compartida: con el default no
saldría ni un .so. Misma perilla que apagaba los threads
de openssl, vista desde el otro lado.
--disable-bootstrap Sólo `all-target-libgcc all-target-libstdc++-v3`. GCC
entero multiplica el tiempo por cinco para tirar el
compilador a la basura.
Los guardianes se ganaron el sueldo en las dos primeras corridas:
1ª «!! falta libstdc++.so.6» — y las librerías estaban perfectas: GCC instala
en /usr/lib64 porque su t-linux64 fija MULTILIB_OSDIRNAMES=../lib64, y
--disable-multilib NO lo apaga. Un .so impecable en el directorio que el
loader no mira es EXACTAMENTE el fallo que esta receta viene a arreglar,
un directorio más allá. Se normaliza a lib en el install.
2ª «!! no definen los símbolos» — y sí los definían. --disable-symvers apaga
el versionado de libstdc++, pero libgcc tiene su PROPIO libgcc.map y
versiona igual: nm los imprime como _Unwind_Backtrace@@GCC_3.3 y el grep
anclado al fin de línea no los veía. El fallo era del guardián. Verificado
contra el libgcc_s.so.1 DEL LAB —el que satisface a firefox hoy— y
coinciden hasta en la etiqueta de versión.
gmp/mpfr/mpc ya existían pero sólo en recipes/incoming-*, con DOS variantes cada
una. Promovidas las de incoming-kde y no las de cosmic: la terna tiene que ser
internamente coherente porque mpc enlaza su .so contra las otras dos, y con las
de cosmic (estáticas sin PIC) muere en «relocation R_X86_64_32 ... recompile
with -fPIC». La de kde va con link=dynamic las tres y además ya estaba SELLADA
entera, así que la promoción no costó ni un build.
Encontrado corriendo el navegador, no leyendo. Lancé `atuq` bajo el sway
headless y murió con decenas de «Error relocating: _ZNKSt5ctypeIcE...: symbol
not found». El binario SELLADO de firefox declara:
NEEDED libstdc++.so.6 NEEDED libgcc_s.so.1 NEEDED libc.so
y las dos primeras NO EXISTEN en el store ni en ningún cierre hidratado: sólo en
.dev-fs/alpine, o sea en el LAB. Es exactamente la lección que la memoria
`quitar-dep-no-apaga-funcion` describe: el proyecto la encuentra en el sysroot
del lab y el artefacto sella con un NEEDED que nadie provee.
LO QUE LO HACE CARO ES QUE NINGUNA MÉTRICA LO VE. build-state.json dice
`sealed`; verificar-repro.sh dice que REPRODUCE bit a bit; los tres guardianes de
la receta pasan (RLBox en el binario, MOZ_REQUIRE_SIGNING, BuildID determinista)
— y el binario no arranca fuera del lab. El verde responde «¿construye?», nunca
«¿corre?».
El audit recorre el store, indexa qué sonames PROVEE el corpus y resta los NEEDED
de cada ELF. No mira el lab a propósito: mirarlo diría que todo está bien, que es
justo la ilusión que causó el problema.
Resultado de hoy: 25 artefactos colgantes, 6 recetas distintas —atuq, firefox,
waterfox, librsvg, spidermonkey, mesa-llvmpipe— y sólo DOS sonames faltan en todo
el corpus. O sea que falta UNA receta que provea las libs de runtime de gcc.
Gravedad: firefox y atuq son raíces de los CUATRO perfiles de escritorio
(cosmic, gnome, kde, sway), así que hoy las cuatro imágenes llevan un navegador
que no puede arrancar. La receta de firefox razona sobre esto en su comentario
—«clang++ de Alpine usa la libstdc++ COMPARTIDA ⇒ el NEEDED existe»— pero cierra
el requisito de BUILD y deja abierto el de EJECUCIÓN. hammer tiene
`[deps] runtime` y ninguna de las seis lo declara.
El PGO necesita correr el navegador para juntar el perfil, y las distros lo
hacen bajo xvfb-run. Nosotros no tenemos X11 (Wayland-only), así que el plan
decía «la salida es un sway headless». Ya no es plan: se corrió.
sway con WLR_BACKENDS=headless y WLR_RENDERER=pixman arranca en gioser —un LXC
SIN /dev/dri, o sea sin GPU ninguna— y dibuja píxeles reales. La captura va como
evidencia: sway 1.10 / wlroots 0.18.2 / foot 1.27.0, los tres binarios nuestros,
salida HEADLESS-1 a 1280x720. Ciclo completo ~2 min.
Dos cosas que costó y quedan escritas para no repetirlas:
· Hidratar BAJO el montaje del store. hydrate-profile.py enlaza, y un hardlink
no cruza montajes: con --into work/... sale EXDEV porque el store está en otro
disco. Con --into store/.rootfs/sway son 193/193 nodos y 4,9 G que no ocupan.
· Inyectar el loader de musl. sway salió DINÁMICO y pide
/lib/ld-musl-x86_64.so.1, que el cierre no trae. El error es
«exec: /usr/bin/sway: not found», que se lee como «falta el binario» cuando lo
que falta es su INTÉRPRETE. En musl el libc.so ES el loader, así que se
resuelve con un --ro-bind. Misma familia que el resto de la noche: el mensaje
nombra lo que buscó, no lo que falta.
Queda el segundo muro del PGO, que es de diseño y no de infra: el profdata no es
determinista, así que hay que generarlo UNA vez y sellarlo como artefacto propio
consumido por hash.
`scripts/verificar-repro.sh recipes/waterfox.toml`: REPRODUCEN 1, DERIVA 0,
NO-DETERMINISMO 0.
Con esto el guardián del BuildID queda probado en las DOS direcciones que exige
la doctrina del repo, y no por diseño sino porque los hechos cayeron así: cazó
una rotura real —el artefacto anterior selló en verde con BuildID=20260906062042,
la hora del build— y pasa un control positivo, que es el arreglado reproduciendo
de verdad. Un guardián con sólo la primera mitad no se distingue de uno que mata
siempre; con sólo la segunda, de uno que no mira nada.
Los dos Gecko del corpus (firefox con RLBox y waterfox) reproducen.
`scripts/verificar-repro.sh recipes/firefox.toml`: reconstruido y comparado
contra el sellado da REPRODUCEN 1, DERIVA 0, NO-DETERMINISMO 0.
No es un trámite. Encender RLBox mete una cadena de compilación ENTERA nueva
—wasi-libc, libc++ a wasm32, los builtins, wasm2c traduciendo a C— dentro del
build de firefox, y la duda razonable era si algo de eso metía una fecha, un
orden de tabla hash o una ruta absoluta. No lo hace.
Es además la distinción que esta misma noche costó cara en la receta de al lado:
waterfox SELLÓ EN VERDE sin reproducir, porque el ArtifactHash es
input-addressed y no se mueve por un BuildID que sea la hora del build. «Selló»
y «está bien» son dos preguntas distintas, y la segunda cuesta un comando.
