sergio/takana

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.

diff --git a/recipes/waterfox.toml b/recipes/waterfox.toml
index 1a41b9fe..fb5d8c7c 100644
--- a/recipes/waterfox.toml
+++ b/recipes/waterfox.toml
@@ -43,7 +43,18 @@
 # Se aparca a propósito: la prioridad pasó a `firefox` con la cadena de optimización y a `atuq`
 # (SDD 26). Cuando se retome, el primer paso es mirar si `browser/locales` existe en el commit
 # pineado — un minuto de `git ls-tree`, no un build.
-# ══ ⚠ DOS COSAS MEDIDAS EN EL ARTEFACTO, SIN RESOLVER — SON DECISIÓN, NO BUG ══════════════════
+# ══ ⚠ TRES COSAS MEDIDAS EN EL ARTEFACTO — SON DECISIÓN, NO BUG ═══════════════════════════════
+#
+# 0) ⚠ SALE A LA RED AL ARRANCAR, SOLO. Visto CORRIENDO el artefacto (2026-09-08), no leyendo:
+#
+#      [WaterfoxBlocker] Failed to update list: https://easylist.to/easylist/easylist.txt
+#      [WaterfoxBlocker] Failed to update list: https://easylist.to/easylist/easyprivacy.txt
+#
+#    Waterfox trae su propio bloqueador y **descarga sus listas al primer arranque, sin que nadie se
+#    lo pida**. Acá falla porque el sandbox no tiene red; en una imagen real sería una conexión no
+#    solicitada. Esta distro apagó la telemetría de firefox exactamente por esto, así que la
+#    coherencia pide decidirlo — no apagarlo de paso. Ninguna inspección estática lo habría mostrado.
+#
 # Del `application.ini` del artefacto `b3:e65c0221` (2026-09-06), leído del sellado, no de la doc:
 #
 #     Vendor=BrowserWorks      Name=Firefox      RemotingName=firefox-default
@@ -59,11 +70,11 @@
 #    probable es `unofficial`, pero es una decisión de política de marcas, no una perilla técnica,
 #    y por eso se deja escrita en vez de cambiada.
 #
-# 2) COLISIONA DE RUTA CON `firefox`. El artefacto instala en `usr/lib/firefox/` y `usr/bin/firefox`
-#    —las MISMAS rutas que la receta `firefox`— porque el árbol no fija `MOZ_APP_NAME`. Hoy no
-#    rompe nada porque ninguna imagen incluye las dos, pero el día que una lo haga, las dos capas
-#    overlay se pelean el mismo fichero y gana una en silencio. El arreglo es `MOZ_APP_NAME` en el
-#    mozconfig, que es un rebuild y puede arrastrar branding: su propia unidad de trabajo.
+# 2) ✅ RESUELTA 2026-09-08 — la colisión de rutas con `firefox`. El artefacto instalaba en
+#    `usr/lib/firefox/` y `usr/bin/firefox`, las MISMAS rutas que la receta `firefox`. Se renombra
+#    a `waterfox` en el install y se le pone lanzador: ver el bloque del install para por qué
+#    renombrar es seguro (Firefox es reubicable) y por qué NO se tocó `MOZ_APP_NAME` (arrastra el
+#    branding, que es la decisión 1, aún abierta). Verificado corriéndolo: arranca y renderiza.
 #
 name    = "waterfox"
 version = "6.7.1.1"
@@ -239,6 +250,36 @@ export MOZ_BUILD_DATE="$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y%m%d%H%M%S)"
 export MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system
 DESTDIR=/out ./mach install
 
+# ── RENOMBRAR A `waterfox`: RESUELVE LA COLISIÓN **Y** EL ARRANQUE ────────────────────────────
+# `mach install` deja el árbol en `usr/lib/firefox` y un symlink `usr/bin/firefox`, o sea LAS
+# MISMAS RUTAS que la receta `firefox`. Hasta hoy no rompía nada porque ninguna imagen lleva las
+# dos, pero es una colisión esperando: overlayfs fusiona y gana una en silencio.
+#
+# Se renombra en vez de tocar `MOZ_APP_NAME` porque **Firefox es REUBICABLE**: localiza `omni.ja` y
+# compañía relativo a su propio binario, que es lo que hace que sus tarballs funcionen desde
+# cualquier directorio. Mover el árbol entero es seguro; cambiar `MOZ_APP_NAME` exigiría tocar
+# `confvars.sh` del árbol y arrastra el branding, que es la decisión que esta receta deja abierta
+# más arriba y que no se toma de paso.
+mv /out/usr/lib/firefox /out/usr/lib/waterfox
+rm -f /out/usr/bin/firefox
+
+# ── EL LANZADOR: SIN ESTO EL ARTEFACTO NO ARRANCA ────────────────────────────────────────────
+# Mismo fallo que tenía `firefox` hasta el 2026-09-07 y que se midió sobre el sellado: el binario
+# NO trae `RUNPATH` (verificado: 0 entradas) y el cierre no publica `ld-musl-x86_64.path`, así que
+# las librerías que viven JUNTO al binario —`libnspr4.so`, `libmozsandbox.so`— no las encuentra
+# nadie y muere con «Couldn't load XPCOM». El `LD_LIBRARY_PATH` es además lo que necesitan los
+# procesos HIJOS: el navegador lanza uno por pestaña.
+cat > /out/usr/bin/waterfox <<'LANZA'
+#!/bin/sh
+LD_LIBRARY_PATH="/usr/lib/waterfox${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
+export LD_LIBRARY_PATH
+exec /usr/lib/waterfox/waterfox "$@"
+LANZA
+chmod 755 /out/usr/bin/waterfox
+# El binario interno se llama `firefox` (viene del MOZ_APP_NAME del árbol, que no se toca): se le
+# pone un nombre propio al lado para que el lanzador no mienta sobre a qué apunta.
+[ -f /out/usr/lib/waterfox/waterfox ] || ln -s firefox /out/usr/lib/waterfox/waterfox
+
 # ── GUARDIÁN: QUE EL BuildID NO SEA UNA FECHA ────────────────────────────────────────────────
 # Copiado de `firefox.toml`, y no por simetría: SIN ESTO YA SELLÓ MAL. El artefacto
 # `b3:e65c0221` del 2026-09-06 salió con `BuildID=20260906062042` —la hora del build— o sea que
@@ -246,13 +287,23 @@ DESTDIR=/out ./mach install
 # que `build-state.json` lo contaba como bueno. Es exactamente el modo de fallo que el comentario
 # de firefox describe, ocurriendo en la receta de al lado por no haber copiado las cuatro líneas.
 esperado="$(date -u -d "@${SOURCE_DATE_EPOCH:-1}" +%Y%m%d%H%M%S)"
-real="$(sed -n 's/^BuildID=//p' /out/usr/lib/firefox/application.ini)"
+real="$(sed -n 's/^BuildID=//p' /out/usr/lib/waterfox/application.ini)"
 if [ "$real" != "$esperado" ]; then
   echo "guardián: BuildID=$real y esperaba $esperado — el artefacto NO reproduce." >&2
   echo "          Revisá que MOZ_BUILD_DATE se exporte en TODAS las fases." >&2
   exit 1
 fi
 echo "guardián: BuildID = $real (determinista, de SOURCE_DATE_EPOCH)"
+
+# ── GUARDIÁN: NI UNA RUTA `firefox` EN EL ARTEFACTO ──────────────────────────────────────────
+# Si `mach install` cambia de layout y algo vuelve a aterrizar en `usr/lib/firefox`, la colisión
+# regresa en silencio: dos artefactos distintos publicando el mismo fichero, y en la imagen gana
+# uno sin que nada lo diga.
+test ! -e /out/usr/lib/firefox && test ! -e /out/usr/bin/firefox || {
+  echo "!! quedaron rutas 'firefox' en el artefacto — colisiona con la receta firefox" >&2
+  ls -la /out/usr/lib /out/usr/bin >&2; exit 1; }
+test -x /out/usr/bin/waterfox || { echo "!! no se creó el lanzador" >&2; exit 1; }
+echo "guardián: instalado como waterfox, sin rutas 'firefox' que colisionen"
 '''
 
 [deps]