Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash
movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los
ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no
hasheaban de antes).
El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza
con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una
fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL
también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en
hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de
TOML y no entra ahí.
Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales
dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
Dos defectos con un solo arreglo. El artefacto instalaba en usr/lib/firefox y
usr/bin/firefox —LAS MISMAS RUTAS que la receta firefox— y además tenía el mismo
fallo del lanzador que se le arregló a firefox ayer: verificado sobre el sellado,
CERO entradas de RUNPATH, así que moría con «Couldn't load XPCOM».
Se renombra el árbol a `waterfox` y se añade el lanzador con LD_LIBRARY_PATH.
Renombrar es seguro porque Firefox es REUBICABLE: localiza omni.ja relativo a su
propio binario, que es lo que hace que sus tarballs anden desde cualquier
directorio. NO se toca MOZ_APP_NAME: eso exigiría tocar confvars.sh del árbol y
arrastra el branding, que es la decisión que esta receta deja abierta y que no
se toma de paso.
Guardián nuevo: ni una ruta `firefox` en el artefacto. Si mach install cambia de
layout y algo vuelve a aterrizar ahí, la colisión regresa en silencio — dos
artefactos publicando el mismo fichero, y en la imagen gana uno sin que nada lo
diga.
Verificado CORRIENDO: arranca headless y renderiza (captura de 518.735 bytes,
idéntica en tamaño a la de firefox sobre la misma página).
Y correrlo destapó lo que ninguna inspección estática mostraba, anotado como
tercera cosa a decidir: WATERFOX SALE A LA RED AL ARRANCAR, SOLO, a bajar las
listas de su propio bloqueador desde easylist.to. Acá falla porque el sandbox no
tiene red; en una imagen real sería una conexión no solicitada en el primer
arranque. Esta distro apagó la telemetría de firefox exactamente por eso.
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.
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.
waterfox selló (b3:e65c0221, 377 M, 43 ficheros) y el artefacto NO reproduce:
BuildID=20260906062042
o sea la hora del build. Y selló en VERDE, que es lo peor: el ArtifactHash es
input-addressed y no se mueve por esto, así que build-state.json lo contaba como
bueno. Es EXACTAMENTE el modo de fallo que el comentario de firefox.toml
describe desde ayer —«el artefacto deja de reproducir SIN QUE NADA LO DIGA»—
ocurriendo en la receta de al lado por no haber copiado cuatro líneas.
Se exporta MOZ_BUILD_DATE en las TRES fases (son shells distintos y mach
re-ejecuta configure) y se pone el mismo guardián que firefox: si el BuildID no
es el que obliga SOURCE_DATE_EPOCH, el build muere.
Quedan escritas en la receta otras dos cosas medidas en el application.ini del
sellado, que son decisión y no bug, y por eso se documentan en vez de cambiarse:
1. El branding «oficial» de ESTE commit es el de MOZILLA, no el de Waterfox.
El comentario de la receta afirmaba lo contrario. Comprobado en el árbol:
branding/official/configure.sh pone MOZ_APP_DISPLAYNAME=Firefox, brand.ftl
da -brand-full-name = Mozilla Firefox, y el ID es el canónico de Firefox.
Hoy esto sella un binario parcheado que se presenta como «Mozilla Firefox»,
justo lo que firefox.toml evita yendo sin marca. La salida probable es
`unofficial`, pero es política de marcas, no una perilla.
2. Colisiona de ruta con firefox: instala en usr/lib/firefox/ y
usr/bin/firefox porque no se fija MOZ_APP_NAME. Hoy no rompe nada porque
ninguna imagen incluye las dos; el día que una lo haga, las dos capas
overlay se pelean el mismo fichero y gana una en silencio.
Con las deps -shared el enlace de libxul.so YA PASA (el choque de cairo se
acabó) y el build avanza hasta el empaquetado, donde muere así:
error: browser/installer/package-manifest.in:239: Missing file(s):
bin/browser/chrome/icons/default/default22.png
:240: default24.png
:245: default256.png
No falta arte y no es culpa nuestra: es una inconsistencia INTERNA del árbol de
Waterfox 6.7.1.1. Bajo `#ifdef MOZ_GTK` el manifiesto pide ocho tamaños (16, 22,
24, 32, 48, 64, 128, 256) y la rama gtk de branding-common.mozbuild lista sólo
cinco. Los tres ficheros existen en los CUATRO brandings del árbol
(official/aurora/nightly/unofficial); lo que falta es la línea que los instala.
Es una rotura sólo de Linux, que es la razón plausible de que upstream no la
note: la rama de Windows del mismo fichero está completa.
El hunk está GENERADO con `diff -u` sobre el fichero real, no escrito a mano: la
primera versión aplicaba «with fuzz 2» y la segunda «with fuzz 1». Un parche con
fuzz es uno que puede agarrar donde no debe, y verificar que aplica limpio cuesta
un `patch --dry-run`.
Va en recipes/waterfox-patches/ y no en firefox-patches/ porque es de waterfox:
firefox no lo necesita.
El build llegaba al minuto 36 y moría enlazando libxul.so con un `collect2:
error: ld returned 1 exit status` y NADA delante — ni undefined reference, ni
cannot find -l, ni DSO missing. No era OOM ni disco. El filtro de salida de mach
clasificaba y descartaba justo el diagnóstico.
Rehecho el mismo objetivo llamando a gmake directo, el linker habló:
ld: /usr/lib/libcairo.a(cairo-ft-font.c.o): in function `_cairo_ft_to_cairo_error':
multiple definition of `_cairo_ft_to_cairo_error';
gfx/cairo/cairo/src/cairo-ft-font.o: first defined here
…y así decenas de símbolos de cairo-ft-font, cairo-pdf-surface y
cairo-toy-font-face. O sea: el libcairo.a ESTÁTICO de la dep entra al enlace por
el -lcairo que arrastra el .pc de gtk3, y sus objetos chocan con el cairo
BUNDLEADO del propio árbol de Gecko.
La receta traía la lista de deps ANTERIOR a la migración de firefox: cairo,
pango, gdk-pixbuf y harfbuzz estáticas donde firefox ya usa las -shared. Y el
propio firefox.toml lo tiene escrito desde el 2026-09-05: declarar las estáticas
junto a un gtk3 que trae las compartidas son dos artefactos peleando por el
mismo .pc, «van las dos listas al mismo sitio o ninguna». Waterfox se quedó a
mitad de camino.
Con la variante compartida, -lcairo resuelve a libcairo.so y los símbolos
bundleados se quedan donde tienen que quedarse.
NO se tocan clang18/llvm18: firefox los quitó porque tapaban el LLVM 22 del lab
y con ThinLTO el bitcode no es compatible hacia atrás; acá el compilador es gcc,
así que ese razonamiento no aplica y cambiarlo sería otra unidad de trabajo.
Se deja puesta la rama de diagnóstico del compile: si mach falla, rehace el
enlace con gmake directo para que el linker hable. No cuesta nada en el camino
bueno (`&& exit 0`) y convirtió un fallo indiagnosticable en uno diagnosticado
en una sola corrida.
Primer intento en el worker: murió en CUATRO SEGUNDOS, no en cuatro horas. `mach build` abortó con
«FATAL ERROR PROCESSING MOZBUILD FILE» sobre browser/moz.build porque referencia
browser/locales/moz.build y ese fichero NO ESTÁ en el árbol traído.
Lo que eso significa, y es la parte que vale: LOS ONCE PARCHES DE MUSL SÍ AGARRARON. La apuesta
explícita de esta receta —reusar los parches de 154 sobre un árbol 153.1.0— no es lo que falló. Lo
que falla es el FETCH: falta un trozo del árbol. Sospechoso número uno el `--filter=blob:none`
contra cómo BrowserWorks compone su repo, no la receta.
Se aparca por decisión del usuario: la prioridad pasa a firefox con la cadena de optimización y a
atuq (SDD 26). El primer paso al retomarla es un `git ls-tree` del commit pineado, no un build.
Waterfox es un fork de Gecko con árbol propio, así que consume EXACTAMENTE la
misma plataforma que Firefox (gtk3, nodejs, clang18, cbindgen, variantes -shared)
y hereda los seis muros ya resueltos sin volver a pagarlos: sin --enable-linker,
compiler=gcc, RUST_TARGET, vaciado de checksums vendorizados, strip_debug y el
build hermético.
Medido con diff ignorando comentarios: las diferencias REALES con firefox.toml son
TRES — la fuente, el branding y la versión. Si aparece una cuarta, conviene
preguntarse si no debería estar en las dos.
LA BASE ES 153.1.0 y los parches son de 154, una release por encima. Se reutilizan
igual porque el código que tocan (LFS64, time64, prctl, sandbox) se mueve poco
entre releases, pero es una apuesta EXPLÍCITA y no un hecho: si patch falla, falla
temprano —antes de compilar nada— y el arreglo es rebasar el que se queje.
ACÁ SÍ VA BRANDING OFICIAL, y no contradice a firefox.toml: allá va sin marca
porque el nombre y el logo de Firefox sobre un binario parcheado entran en la
política de marcas de Mozilla; acá browser/branding/official ES la marca del
propio Waterfox, que BrowserWorks distribuye en su árbol para que se construya
así.
Fuente por commit y no por el tarball_url de GitHub, que es /archive/-style y se
genera al vuelo. hammer clona con --filter=blob:none, así que el árbol Gecko no
trae historia.
Sergio