Salió de 'yupana frontera' en cuanto nix volvió a correr: kcoreaddons la pide y no había receta.
Es un hueco de RUNTIME, no de build — KDE sella 1037/1037 sin ella, y por eso NINGUNA métrica de
deuda la veía. Sin la base MIME el escritorio no resuelve asociaciones, iconos por tipo ni
'abrir con', y GIO cae a adivinar por extensión.
Va al CORPUS, no a incoming-kde: la necesitan las cuatro imágenes de escritorio, y una receta
resuelve sibling-first y después el catálogo padre, nunca una cola hermana.
Dos cosas que se comprobaron ANTES de construir, no después de que fallaran:
· El tarball de GitLab no trae el submódulo 'xdgmime' — .gitmodules lo declara y el directorio
llega vacío. Leyendo meson.build:26-47 se ve que sólo lo usa la suite de tests y con
required:false, así que con build-tests=false lo único que pasa es un warning.
· 'i18n.merge_file' corre SIEMPRE, no lo gobierna build-translations: no traduce UI, arma el
fichero de datos desde el .in. De ahí el msgfmt, que gettext-tiny sí provee.
'--prefer-static' desde el principio, que es la lección de json-glib de hace un rato: el binario
sale ESTÁTICO con 0 NEEDED y corre en el host.
Y el artefacto trae la mime.cache ya compilada (update-mimedb=true, que upstream trae en false):
sin ella el paquete son datos crudos y alguien tendría que acordarse de correr
update-mime-database al armar cada imagen.
Verificado:
prueba del consumidor update-mime-database genera 157.560 bytes de cache y 26 media-types
binario estático, 0 NEEDED, corre fuera del sandbox
repro REPRODUCE bit a bit (la caché se genera en el build: era candidata)
mirror el tarball subido al Storage Box (ADR 0013)
frontera huecos 4 → 3
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
'yupana frontera' llevaba desde el 2026-08-10 sin poder correr acá porque el hub no tenía nix.
Instalado desde el repo de Artix (extra/nix 2.35.2). Dos cosas que costaron medirse:
· El paquete quedó ROTO al instalarse: le faltaban libboost_{context,iostreams,url}.so.1.92.0
porque el sistema tiene boost 1.91 y 280 paquetes sin actualizar. NO se hizo 'pacman -Syu':
280 paquetes en un server protegido, sin backup, que hospeda la granja, gitea y el runner de
CI no es una decisión que tome un arreglo de tooling. El ensayo en seco mostró que la
reparación acotada eran TRES paquetes exactos (boost-libs, source-highlight, gdb) sin
cascada, y eso sí se hizo. Control después: gdb 17.2 sigue arrancando.
· El store por defecto iba a ~/.nixstore, o sea a '/', que tiene 21 G libres frente a los 126
del volumen. Llenar '/' no rompe una tanda, rompe la máquina. NIX_ROOT pasa a apuntar a
work/nixstore, que además ya es el sitio de lo pesado-y-regenerable. La caché git de nixpkgs
(~69 M) NO la gobierna esa variable —nix la pone en XDG_CACHE_HOME— así que en gioser está
mudada al volumen con un enlace: ~/.cache/nix -> /mnt/vvv/nix-cache.
Con eso, la frontera vuelve a dar respuesta, y es pequeña como corresponde a un corpus cerrado:
172 candidatos → 150 opcionales, 11 provistos, 5 nix-ismos, 4 HUECOS reales (polkit-qt-1,
qqc2-breeze-style, shared-mime-info, xwayland) y 2 pendientes de clasificar (mesa-libclc,
python3-3.14.7-env).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
Las 6 que quedaban (fuse3, hwdata, icu4c, libdisplay-info, libelogind, lua) no tenían copia en
el corpus, así que borrar una habría roto su cola: la resolución es sibling-first y después el
catálogo PADRE, nunca una cola hermana. Se promueve una y se barren las 16.
Las 16 eran byte a byte IDÉNTICAS entre sí, con el mismo ArtifactHash — medido con 'hammer hash',
no deducido del nombre. Cada una la comparten entre 2 y 4 imágenes, que es exactamente el
criterio que dejó escrito xkeyboard-config al promoverse: lo que comparten varias imágenes tiene
que vivir en el corpus o no lo alcanzan.
A diferencia de aquella, acá las copias SÍ se barren en el mismo movimiento: sin copia en el
corpus no había dónde caer, y dejarlas sería mantener hasta 4 ficheros que son el mismo hash.
Verificado con la huella de las 1167 recetas antes y después:
ficheros de receta 1167 → 1157 (16 borradas, 6 promovidas)
hashes supervivientes ninguno se movió ⇒ CERO rebuilds
los cinco grafos deuda 0, huérfanas [], sellados == recetas
static-audit MIENTEN 0 de 690
duplicados SOMBRAS REDUNDANTES: 0 ← de 14
⚠ Y una lectura que casi publico mal: mi primera comparación de hashes dijo 'CAMBIÓ ✗' en las
seis. Era el grep de la comparación, que no casaba y dejaba el valor 'antes' vacío — los hashes
nuevos eran idénticos a los medidos minutos antes. Un instrumento roto que grita es tan malo
como uno mudo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
Las 14 sombras marcadas 'redundante' dan el MISMO ArtifactHash en todas sus colas — no son
variantes, son el mismo artefacto declarado dos, tres, cuatro y hasta cinco veces. Medido con
'hammer hash' receta por receta, no deducido del nombre.
Se barren sólo las que YA tenían copia en el corpus, porque la resolución es sibling-first: una
dep desde incoming-kde busca incoming-kde/x y, si no está, CAE al corpus/x. Son 8 nombres, 14
ficheros: bzip2-shared, glib-shared, lcms2, mpc, pcre2-shared, sqlite-shared, xkeyboard-config
y xz-shared.
13 de los 14 eran byte a byte idénticos al del corpus. El decimocuarto, xkeyboard-config,
difiere en 14 líneas de COMENTARIO (mismo hash), y ese comentario es el permiso explícito para
esto: quien la promovió el 2026-09-05 escribió que dejaba las copias a propósito y que
'barrerlas es otra unidad de trabajo, no un efecto colateral de ésta'. Ésta es esa unidad.
Verificado con la huella de las 1181 recetas antes y después: NINGÚN hash superviviente se
movió ⇒ cero rebuilds. Y tras regenerar los cinco grafos: deuda 0, huérfanas [], y todas las
clausuras de perfil siguen completas.
⚠ Nota sobre una lectura que casi me confunde: los conteos de 'recipes' NO bajan (kde sigue en
1034) y eso es lo correcto — cuentan nodos alcanzables, no ficheros. Antes incoming-kde/x tapaba
a corpus/x; ahora el del corpus ocupa su lugar. Un nodo por otro.
Quedan 6 nombres (fuse3, hwdata, icu4c, libdisplay-info, libelogind, lua) sin copia en el
corpus: ésos exigen promover una primero, y van aparte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
'-Ddefault_library=static' gobierna cómo se construye la librería PROPIA, y eso funcionaba: el
artefacto trae libjson-glib-1.0.a. Pero no dice nada de con qué se enlazan los EJECUTABLES, así
que json-glib-format y json-glib-validate salían dinámicos contra libffi.so.8, libz.so.1 y
libc.so — y ese libc.so es la musl de zig, 255 bytes de linker script en el host. O sea binarios
que NO CORREN fuera del sandbox, en una receta que declara link=static. Mismo remedio que
appstream, que ya llevaba --prefer-static.
Medido antes y después:
json-glib-format dinámico, 3 NEEDED → ESTÁTICO, 0 NEEDED
json-glib-validate dinámico, 3 NEEDED → ESTÁTICO, 0 NEEDED
libjson-glib-1.0.a igual (los consumidores no cambian de forma)
Y la prueba del consumidor, que es la que vale: json-glib-format sobre un JSON real corre EN EL
HOST y devuelve {"a":1}. (El ruido de libgvfsdbus.so en stderr es glib intentando dlopen
módulos GIO desde un binario estático: inocuo, la salida sale bien.)
Cascada reconstruida en orden de onda, con el cierre transitivo sacado de yupana y no de un grep
—que no veía a zathura ni a zathura-pdf-poppler por tener el array de deps multilínea, y la regla
del repo es justamente ésa—: zathura, incoming-cosmic/xdg-desktop-portal, zathura-pdf-poppler.
Verificado después, no antes:
static-audit MIENTEN 0 de 690 ✅ toda receta que declara link=static lo cumple
los 5 grafos deuda 0
repro REPRODUCEN 3 · DERIVA 0 · NO-DETERMINISMO 0
⚠ incoming-gnome/json-glib NO se toca: declara link="dynamic" a propósito porque el shell de
GNOME dlopea .so reales para introspección. No miente — es honesta, y su radio de 10 no se paga.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
El vigía decía 5 fuentes muertas y sólo UNA estaba en riesgo de verdad: busybox y freetype
tenían el tarball en la caché local Y en el mirror, y firefox-pgo-profile apunta a .invalid a
propósito. La que no tenía copia en ningún lado era libtool (incoming-kde), con ftpmirror.gnu.org
devolviendo 502 — o sea una receta que ya no se podía reconstruir y nadie lo sabía.
Arreglado: el tarball se bajó de ftp.gnu.org, se verificó contra el sha256 PINEADO (coincide
byte a byte), y está en la caché local y en el mirror. La URL de la receta pasa al espejo que
responde, y se midió que eso no re-hashea nada — ANTES y DESPUÉS dan el mismo
b3:5c09bff5..., que es el ADR 0013 comprobado en vez de citado.
Y el vigía ahora cruza cada fuente muerta con la caché local y el mirror, porque mezclar
'upstream caído con el blob guardado' (noticia) con 'caído y sin copia' (emergencia) hace que
el número suba, nadie lo mire, y el día que uno importe esté enterrado entre cuatro que no. A
un guardián lo mata el ruido. Ahora informa EN RIESGO aparte:
== vivas 1175 / 1179 muertas arriba 4 EN RIESGO 0
⚠ Y si el mirror no se puede consultar —el worker no tiene la clave del Storage Box— dice
'indeterminado', NUNCA 'EN RIESGO': un instrumento que no pudo correr no puede parecer un
hallazgo.
Probado con rotura a propósito y con los dos controles, que es lo que separa un guardián que
sirve de uno que nunca saltó:
sha inexistente + upstream muerto → EN RIESGO ✓ salta
blob en caché + upstream muerto → cache-local ✓ no salta
mirror inalcanzable → indeterminado ✓ no alarma en falso
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
El cp nunca corrió: zsh aborta el comando entero cuando un glob no casa, y ese directorio no
tenía ningún .txt, así que tampoco se copió el .log — y el rm -rf siguiente se ejecutó igual.
Borrar sin comprobar que la copia existía.
Se deja un PERDIDO.md en vez de un directorio vacío, que es lo que la regla 3 de CLAUDE.md
advierte: un directorio vacío no es evidencia, es un nombre. La firma medida antes de la
pérdida (7/1/6, cero screenshot) sí está registrada en la cabecera del cazador.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
arnés viejo (sólo CONTENT) 98 segfaults · 1 colgada · 49/50 screenshots
arnés nuevo (los cinco) 0 segfaults · 0 colgadas · 50/50 screenshots
Queda dicho en la cabecera qué prueba esto y qué no. El MECANISMO sí: 98 → 0, exactamente 2
por corrida, en el 100% de las corridas; un efecto determinista se refuta con pocas muestras.
El CUELGUE no: 1 contra 0 en 50 pares no es significativo — con la tasa medida (3 en 130 ≈
2,3%) ver cero en 50 tiene ~31% de probabilidad aunque nada hubiera cambiado, y harían falta
~200 corridas para un negativo convincente.
Lo que sí sostiene: las tres colgadas observadas tienen la MISMA huella exacta (7 fallos de
lanzamiento de pestaña, 1 de rdd, 6 messageManager is null, cero screenshot) y las tres
cayeron donde los ayudantes revientan. Ninguna apareció sin el mecanismo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
El banco medía el ciclo COMPLETO del proceso (arrancar → renderizar → capturar → salir)
y nunca se midió cuánto de eso era arranque. Con una página vacía como control, y las 4
cargas × 2 variantes en UNA sola sesión intercalada (restar entre corridas de días
distintos no vale: la misma variante deriva ~1%):
maquetación trabajo 7281 → 4744 ms -34,8% (publicado: -10,9%)
carga ajena trabajo 4550 → 4634 ms +1,8% = cero, y es buena señal
SunSpider trabajo -34 → -6 ms bajo el ruido
Dos correcciones al documento:
1. El -10,9% es correcto para el ciclo completo pero se leía como 'firefox 11% más
rápido'. Sobre el trabajo de la página el PGO rinde -34,8%: tres veces más. El error
subestimaba el propio resultado.
2. La explicación que di del SunSpider era aire. Su trabajo mide -34 ms, NEGATIVO: la
página con el benchmark tardó menos que la vacía. No había nada que medir, y yo le
colgué encima una teoría sobre el JIT. La teoría puede ser cierta; esta medición
nunca la probó.
Las tablas viejas se dejan sin retocar, con un aviso arriba: el error de método enseña
más que el número corregido. Todo el rigor estadístico estaba puesto sobre una cantidad
que no era la que yo creía medir, y ninguna repetición lo habría revelado — sólo un
control, que costó siete corridas de una página vacía.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2
Al reconstruir atuq sobre el firefox con jarlog, murió:
zipfile.BadZipFile: Bad magic number for central directory (rebrand.py)
El jarlog convierte el omni.ja al formato «jar optimizado» de Mozilla, que mueve
el directorio central al principio:
sin jarlog: PK\003\004 ZIP estándar — zipfile lo abre, 5306 entradas
con jarlog: \376\204#\0 zipfile lo rechaza
Y atuq reempaqueta el omni.ja con zipfile para su branding. O sea que el jarlog
rompe el navegador propio de la distro.
La cuenta es asimétrica: el COSTE está medido y el BENEFICIO no —el banco corre
con caché caliente, donde reordenar el omni.ja no ahorra ninguna lectura, y dio
-0,1%, por debajo del suelo de ruido del propio banco—. Cambiar algo que
funciona por una ganancia que no se pudo medir, rompiendo algo que sí
funcionaba, es mal negocio.
Revertido a los hashes YA construidos y medidos (perfil 3647c6be, firefox
3d199174, atuq fab2fbfb): cero reconstrucciones. La documentación va fuera de
los campos hasheados, verificado antes y después.
Se retoma cuando (1) se mida el arranque EN FRÍO, que es su terreno, y (2)
rebrand.py sepa leer el jar optimizado o des-optimizarlo antes. El blob
92497cdd del mirror ya trae el jarlog: retomarlo es cambiar una línea.
Y LA LECCIÓN, que es la que más vale: el jarlog parecía GRATIS. «Es lo que hace
upstream y no cuesta nada» lo escribí yo en este mismo documento hace unas
horas. El coste no apareció midiendo el jarlog sino CONSTRUYENDO LO QUE DEPENDÍA
DE ÉL. Una función que se declara gratuita sin haber reconstruido a sus
consumidores no es gratuita: es no medida.
sin PGO v1 v2 v3 (= v2 + jarlog)
DOM/maquetación 23.008 20.851 20.527 20.502 (-10,9%)
SunSpider 16.006 15.859 15.869 15.838 (-1,0%)
jarlog solo: -0,1% y -0,2%
Indistinguible de cero, y el argumento no es que los rangos se solapen —que se
solapan— sino que la MISMA variante varía ~1% entre corridas de días distintos
(v1 dio 20.851 hoy y 21.050 ayer). El suelo de ruido del banco es diez veces el
efecto buscado.
No es un fallo del jarlog: el banco corre con la caché de página CALIENTE, y ahí
reordenar omni.ja no ahorra ninguna lectura. Su terreno es el arranque en frío,
que este instrumento no reproduce.
Lo que SÍ está probado es que la función existe, y del lado del artefacto:
libxul IDÉNTICO byte a byte entre v2 y v3, omni.ja distinto en 26 bytes. El
jarlog tocó exactamente lo que debía y nada más. Se conserva porque es lo que
hace upstream y no cuesta nada; lo que no se afirma es una ganancia no medida.
Y no hizo falta la extensión Quitter, que este mismo documento daba por
bloqueante: profileserver.py sólo traduce JARLOG_FILE a MOZ_JAR_LOG_FILE.
Anotado además: los dos atípicos del banco son 120.034 y 120.030 ms, o sea
exactamente el timeout del arnés. No son ruido de carga sino corridas COLGADAS
al arrancar en headless, 2 de 56 (~3,5%).
