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.
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.
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.
b3:88b5a762, 377 M, 43 ficheros, BuildID=19700101000001 (determinista, con
guardián). Con esto el grafo queda 850/852 sellados y los dos que faltan son
`ajeno` (steam-runtime-sniper, xwayland), que son frontera y no deuda.
Los cuatro muros que costó, y ninguno era de la receta:
1. Moría en 4 s por un submódulo git — era el binario de hammer del worker,
13 h más viejo que el arreglo que los materializa.
2. El linker moría sin mensaje — era el watchdog del worker-loop barriendo el
objdir a los 2 minutos, antes de que nadie pudiera mirarlo.
3. `multiple definition` de cairo — la receta traía la lista de deps anterior
a la migración de firefox a las variantes -shared.
4. Iconos faltantes al empaquetar — inconsistencia interna de Waterfox: el
manifiesto pide ocho tamaños y branding-common.mozbuild instala cinco.
Rotura sólo de Linux.
Y una quinta que el sello NO habría delatado: selló primero con
BuildID=20260906062042, o sea sin reproducir, y en VERDE.
`llvm-nm --defined-only | grep -c w2c_` cuenta también los nombres C++
mangleados que llevan `w2c_` en el MEDIO —`_ZN5rlbox...PK16w2c_mem_capacity...`
son 913 de los 1547—, no sólo los símbolos de la jaula wasm. Anclado
(`grep -c " w2c_"`, o `awk '{print $3}' | grep -c "^w2c_"`) da 634, que es lo
que mide el guardián de recipes/firefox.toml y lo que el documento quería decir.
La conclusión no se mueve: la base sin RLBox da 0 con cualquiera de los dos
patrones, y el derivado hereda los mismos 634 que la base. Lo que se corrige es
la afirmación, que decía «símbolos w2c_*» y contaba otra cosa: un número sin su
patrón no es una medición.
Lo cazó hammer-03 al reproducir el número desde su lado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
`firefox` selló con RLBox (b3:8116bdec) y `atuq` se reconstruyó encima en 2
segundos, que es exactamente lo que el §2 prometía del camino derivado: el
overlay no cambió una línea por un rebuild del motor.
Comprobado que la base nueva es la que quedó DENTRO del derivado, no sólo
declarada: el `libxul.so` de atuq trae 1547 símbolos `w2c_*` donde la base
anterior (352d7880) traía 0. Y la capa de v0.5 sigue entera sobre ella — los
cuatro contenedores, las dos extensiones y el mapa del proxy en un arranque
real.
De paso, una promesa del documento que convenía no creer sin medir: que si sube
firefox, atuq se reconstruye solo. Se midió en un catálogo de sonda (una copia
de atuq.toml + su árbol + firefox.toml, resuelto por el fallback al catálogo
padre): con el firefox idéntico al del corpus, atuq da el mismo hash; cambiando
una bandera de ese firefox copiado, atuq pasa a b3:60ade76a. La dep entra en
hash_inputs, así que un atuq viejo no puede quedarse tapando un motor nuevo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UgNtJEFetMYbXax5dVUjZZ
Sergio