Sin CONFIG_MEMCG el fichero memory.max no existe y arje-incarnate descarta el error: una
Card pedía un tope de memoria y corría sin ninguno, dejando sólo un warn!. El x86_64_defconfig
de 7.1 ya no trae MEMCG=y, así que había que pedirlo explícito.
Va en tanda con PSI (que el contrato declara como wants) para pagar de una sola vez el
re-hasheo: la fase configure ES la identidad del artefacto. linux.toml queda intocado a
propósito — es el baseline of_tree del selfhost-verify y no hospeda Cards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Sexta de la familia. El arreglo estaba HECHO en disco desde hace horas y lo
reporté como cerrado, pero nunca llegué a commitearlo — sólo se vio al revisar
`git status` por otra cosa. Sin esto, el arreglo se perdía.
El wrapper del sandbox (commit anterior) tapaba el síntoma. Esto arregla la causa:
nuestra receta de binutils no pasaba el flag que Alpine SÍ pasa, así que su `ar` y su
`ranlib` estampaban la hora de pared en la cabecera del miembro `/` de cada `.a`.
POR QUÉ AHORA Y NO "AGENDADO", Y POR QUÉ ESTE ORDEN. Arreglar la raíz PRIMERO evita
la parte fea del arreglo por wrapper: al cambiar el hash de binutils (c316212f… →
4b5fbf3b…) los artefactos contaminados caen en DIRECCIONES NUEVAS. No hay transición
"mismo ArtifactHash, otros bytes" — que es justo el peligro que la huella del lab
existe para eliminar. Los viejos quedan superados y podables, no reemplazados en el
sitio. Re-sellar en el sitio habría sido la opción peligrosa.
COSTE, MEDIDO CON yupana radio (no estimado): 422 dependientes transitivos, 365
sellados caen a deuda, las siete imágenes. Se asume a propósito: el corpus ya está en
campaña de reconstrucción (1093/1125) y la cascada se arrastra sola, porque cada
`hammer build` construye sus deps.
El wrapper del sandbox se mantiene como defensa en profundidad: es byte-neutral para
todo lo que ya sellaba con mtime 0, y cubre a cualquier herramienta futura que archive
sin pedir permiso.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
`unable to find static system library 'bz2'` en el link, a los 2612 s (43 min).
La receta no tenía `[deps]`. Decimotercera de la familia.
NO fue OOM pese a que la RAM estaba en 222 Mi libres cuando lo comprobé: dmesg
limpio. Conviene dejarlo escrito porque la sospecha era razonable y falsa.
Falla con las dos: `unable to find static system library 'lzma'` y `… 'bz2'`,
en el link a los 1331 s. La receta no tenía `[deps]`.
Duodécima de la familia. Sin verificar (mismo criterio que mise/pixi): el
patrón lleva once arreglos idénticos y comprobarlo cuesta 22 min de campaña
parada.
Falla con las dos: `unable to find static system library 'lzma'` y `… 'bz2'`.
La receta no tenía `[deps]`. Undécima de la familia.
Acá la dep es evidente en retrospectiva: `rga` busca DENTRO de archivos
comprimidos, así que necesitar lzma/bz2 es lo esperable — pero el Cargo.toml no
las nombra (las arrastran sys-crates) y sólo aparece en el link, a los 468 s.
Sin verificar (mismo criterio): el patrón lleva diez arreglos idénticos.
`unable to find static system library 'bz2'`. La receta no tenía `[deps]`.
Décima de la familia (appstream, cargo-deb, cargo-make, dprint, dufs, fnm,
macchina, maturin, mise).
⚠ El fallo sale en el LINK, al final, y este build tarda 87 MINUTOS en llegar
(5226 s). Una dep de una línea que falta cuesta hora y media de máquina antes
de decir nada.
Sin verificar a propósito (mismo criterio que mise): comprobarlo costaría otra
hora y media de campaña parada, y el patrón lleva nueve arreglos idénticos
verificados.
`unable to find static system library 'bz2'`. La receta no tenía `[deps]`.
Novena de la familia (appstream, cargo-deb, cargo-make, dprint, dufs, fnm,
macchina, maturin).
⚠ Sin verificar a propósito: el build tarda ~60 min (falló a los 3550 s) y el
flock es exclusivo, así que comprobarlo cuesta una hora de campaña parada. El
patrón lleva ocho arreglos idénticos verificados y la campaña lo verifica sola
en la siguiente pasada.
`unable to find static system library 'lzma'`. La receta no tenía `[deps]`.
Octava de la familia (appstream, cargo-deb, cargo-make, dprint, dufs, fnm,
macchina). Verificado: sella, 0 librerías faltantes, binario en /usr/bin.
⚠ Nota de método: verificar ESTA costó ~20 min de campaña parada, porque el
build tarda más que su fallo (1033 s) y el flock es exclusivo. Para el resto de
esta familia —arreglo de UNA línea con el patrón ya verificado 8 veces— sale
más barato commitear y dejar que la campaña lo verifique en su siguiente
pasada.
`unable to find static system library 'sqlite3'`. La receta no tenía `[deps]`:
el lab trae el toolchain de Rust pero no las libs C que los crates `*-sys`
esperan del sistema. `sqlite` está sellada y aporta /usr/lib/libsqlite3.a.
Séptima de la misma familia (appstream, cargo-deb, cargo-make, dprint, dufs,
fnm). Verificado: sella, 0 errores de librería faltante.
Cadena completa, cuatro recetas nuevas y una modificada:
musl-obstack -> libobstack (find_package(obstack REQUIRED))
argp-standalone -> libargp (find_package(argp REQUIRED))
musl-fts -> fts(3), que usa libdwfl/linux-kernel-modules.c
elfutils-libdw -> libdw + libdwfl (VARIANTE: la canónica sólo hace libelf
porque de ella cuelgan los cuatro kernels)
Lo que costó, en orden de aparición:
· libdw a secas NO necesita argp/obstack/fts — la nota de la canónica es cierta
de libdwfl y src/, no de libdw. El `obstack` de libdw estaba en un COMENTARIO.
· Pero dwarves SÍ usa libdwfl (15 dwfl_* en dwarf_loader.c) ⇒ vuelven argp y fts.
· libdwfl no compila suelto: hay que seguir el orden de SUBDIRS del raíz
(lib → libelf → libcpu → backends → libebl → libdwelf → libdw → libdwfl →
libdwfl_stacktrace).
· El compat/argp.h de la canónica TAPA el argp real y no declara argp_failure.
· libdw.a GORDA: FindDWARF.cmake pone DWARF_LIBRARIES = libdw + libelf y nada
más, pero libdw necesita libdwfl/libebl/libdwelf/backends/libeu, que son libs
internas. Se fusionan en un archive (patrón de la libgtk-4.a) junto con un
`error()` real, que musl no trae y el shim de la receta sólo daba inline.
· Y al final, lzma/bz2: libdw descomprime .debug_* comprimidas.
Verificado de verdad, no por exit code: pahole v1.30 arranca (con el loader
musl del lab) y DECODIFICA DWARF — sobre un binario de prueba imprime los
offsets, los tamaños y hasta el agujero de 3 bytes de padding.
dwarves llama a 15 `dwfl_*` distintas desde dwarf_loader.c, así que libdw sola
no alcanza. libdwfl SÍ arrastra argp (argp-std.c) y fts (linux-kernel-modules.c)
⇒ la receta declara `argp-standalone` y `musl-fts`. Esos objetos casi nunca se
enlazan (dwarves no usa dwfl_standard_argp ni dwfl_linux_kernel_*) pero tienen
que COMPILAR.
Dos cosas que costaron:
· libdwfl no se puede construir suelto: su Makefile lee los .manifest de otros
subdirs. Hay que seguir el orden de SUBDIRS del raíz:
lib → libelf → libcpu → backends → libebl → libdwelf → libdw → libdwfl.
· `rm -f compat/argp.h`: el shim de la canónica es sólo tipos/decls y no declara
`argp_failure`, que usa argp-std.c. Como esta variante trae argp de verdad, hay
que BORRAR el shim para que gane el /usr/include/argp.h real — `-I$PWD/compat`
va primero y si no lo tapa.
Tercera pieza del frente libdw/musl. `libdwfl` de elfutils usa fts en
linux-kernel-modules.c, y dwarves necesita libdwfl.
⚠ Sus símbolos casi nunca se ENLAZAN (dwarves no llama dwfl_linux_kernel_*, así
que ese objeto no sale del archive), pero el fichero tiene que COMPILAR: hace
falta un <fts.h> real con los campos y constantes que usa. Escribir ese header
a mano es fácil de hacer mal en silencio; traer la implementación real es más
honesto.
Se compila a mano como musl-obstack. Gotcha menor: fts.c hace
`#include "config.h"` con COMILLAS (obstack.c lo hace con ÁNGULOS).
Tercera pata del frente libdw/musl, para `dwarves`.
VARIANTE y no tocar `recipes/elfutils.toml`: de la canónica cuelgan los CUATRO
kernels (su tools/objtool enlaza -lelf) y moverle el hash los invalidaría.
Mismo patrón que openssl-threads.
⚠ La canónica avisa que «libdw/libdwfl arrastran argp/obstack/fts, lo
verdaderamente difícil en musl». Es cierto de `libdwfl` y de `src/`, pero NO de
`libdw` a secas, que es lo único que pide dwarves. Verificado sobre el fuente:
· `argp_`/`fts_open` → sólo en libdwfl/, CERO en libdw/.
· `obstack` → en libdw/ aparece UNA vez y es dentro de un COMENTARIO de
libdwP.h: elfutils lleva su propia «simplified thread-local reimplementation
of obstacks» y no incluye <obstack.h> en ningún sitio.
⇒ los stubs de compat/ que ya montaba la receta bastan; libdw compila tal cual.
Verificado: sella y libdw.a exporta 129 símbolos `dwarf_*` reales
(dwarf_begin, dwarf_begin_elf, dwarf_getelf…), más dwarf.h/libdw.h/known-dwarf.h.
Segunda pata del frente libdw/musl: `dwarves` hace `find_package(argp REQUIRED)`
y musl no trae argp. Es lo que Alpine empaqueta como `argp-standalone`.
Se compila a mano (sin autotools, como musl-obstack) y SÓLO los siete
`argp-*.c` que el propio Makefile.am pone en `libargp_a_SOURCES`. Los otros .c
del tarball (mempcpy/strchrnul/strndup/strcasecmp) son LIBOBJS de autoconf —
reemplazos para sistemas que NO los tienen— y musl SÍ los tiene, así que
incluirlos duplicaría símbolos de la libc.
Gotcha: `UNUSED` no es del código, lo define el `acinclude.m4` de autoconf. Sin
él las firmas `char* arg UNUSED` no parsean y salen `expected ')'` y varios
`undeclared identifier 'state'` — errores que parecen del código y son de
config. Va en el config.h a mano.
Primera pieza del frente libdw/musl (para `dwarves`). La necesitan DOS cosas:
`libdw` de elfutils (su libdwP.h mete `struct obstack` en el Dwarf) y el propio
`dwarves`, que hace `find_package(obstack REQUIRED)`. Es lo que Alpine
empaqueta como `musl-obstack`.
Se compila A MANO: el tarball trae Makefile.am pero no un `configure` generado,
y el corpus no tiene autoconf/automake/libtool. Son dos .c.
Dos gotchas resueltos:
· `obstack.c` hace `#include <config.h>` SIN guarda (fuera de _LIBC) ⇒ hay que
fabricarle uno. Lo único que mira es HAVE_LIBINTL_H, que musl no tiene, así
que el config.h mínimo vale.
· Es `<config.h>` con ÁNGULOS, no comillas ⇒ no basta con dejarlo en el cwd,
hace falta `-I.` en el compile.
El nombre importa: dwarves lo busca con `find_library(NAMES obstack)` en
/usr/lib ⇒ instala /usr/lib/libobstack.a y obstack.h.
Los añadí durante el diagnóstico y luego los verifiqué uno a uno quitándolos:
la receta construye igual sin ellos. Dejarlos era cargo-cult, y encima el
comentario afirmaba cosas que mis propias pruebas ya habían desmentido.
La causa real es UNA y las dos únicas piezas necesarias siguen ahí: quitar la
dep `linux-headers` (Linux 6.16 tapando los headers 7.1 del rootfs) y el
cherry-pick de upstream para el `io_uring_buf_reg` de 7.1.
Ambos descartes quedan escritos en la receta para que nadie los re-intente:
`--enable-bundled=yes` no puede ganar porque zig-cc impone sus headers por
delante de cualquier `-isystem`, y la versión de zig es irrelevante porque los
headers que mandan son los del ROOTFS.
Verificado tras la limpieza: sella, y `strace -c /bin/true` traza 30 syscalls.
Dos cambios, una causa: el sandbox sirve headers UAPI MÁS NUEVOS de lo que
strace 6.19 espera, y la receta traía una dep que los ensombrecía con otros
más VIEJOS.
1) Fuera `linux-headers` de [deps]. Esa receta instala Linux 6.16 en
/usr/include y TAPA los headers del rootfs (7.1). Con ella faltaban 35
constantes —18 de btrfs.h, 17 de input-event-codes.h— y como los xlat de
strace son `#unconditional` (sin guardas #ifdef), una constante ausente NO
degrada la traza: rompe la compilación. Comprobado que no aporta NI UN
header que el rootfs/zig no traigan ya (0 ficheros exclusivos).
2) `strace-io-uring-7.1.patch`: Linux 7.1 añadió `min_left` a
`struct io_uring_buf_reg` y cambió `__u64 resv[3]` por `__u32 resv[5]`, así
que `CHECK_TYPE_SIZE(arg.resv, sizeof(uint64_t)*3)` saltaba como
`static assertion failed`. El cambio es el de UPSTREAM (strace master ya lo
trae), mismo criterio que `linux-headers-7.0.patch`, que también es un
cherry-pick.
⚠ El fallo se destapa POR CAPAS: make abortaba en btrfs.o, así que las 17
constantes de evdev ni se compilaban, y al arreglar btrfs "aparecían" las de
evdev como si el arreglo no hubiera servido. Y sólo tras resolver las 35 se
llegó a compilar io_uring.c y salió el static_assert. Una causa, tres caras.
⚠ `--enable-bundled=yes` NO sirve acá aunque el compilador lo sugiera: zig-cc
impone sus headers por delante de cualquier `-isystem`, así que los bundled de
strace no pueden ganar. Se probó: la opción se aplica (`checking whether to use
bundled linux kernel headers... yes`) y el assert sigue.
Verificado: sella, 0 undeclared, 0 asserts, y el binario TRAZA de verdad —
`strace -c /bin/true` cuenta 30 syscalls.
El módulo es `github.com/yyyar/gobetween/main` y el paquete main está en la
raíz, así que `go install` —que nombra el binario por el último elemento de la
ruta del módulo— lo dejaba como `/usr/bin/main`. Un `/usr/bin/main` en una
distro choca con cualquier cosa y no dice qué es.
La fase `install` que genera hammer para Go es `true` (el binario ya lo puso
`go install` en GOBIN=/out/usr/bin), así que definirla sólo añade el renombrado.
Los `test -x` no son adorno: si `go install` cambiara el nombre, sin ellos el
`mv` fallaría y se sellaría un artefacto SIN binario — regla 3 del repo, que
falle ruidosamente.
Verificado: /usr/bin/gobetween (33 M), arranca e imprime su versión, y no queda
ningún fichero `main` en el artefacto.
`github.com/eric-lindau/udpfacade` (que importa src/server/udp) ya no existe:
GitHub da «Repository not found» y proxy.golang.org 404 para esa versión, así
que `go mod vendor` moría y la receta era INCONSTRUIBLE. No se arregla subiendo
de versión: master de gobetween pinea el mismo módulo.
Se redirige con `replace` al único superviviente, illarion/udpfacade.
⚠ Apunta a MASTER (031998cc71fa), no al commit pineado. El original
(d8c1c27add169599654f71a6c62d13cde1c51e50) SÍ existe como objeto en illarion
—los forks comparten almacén y la API de GitHub lo muestra— pero NO es
alcanzable desde ninguna ref, y `go` sólo resuelve pseudo-versiones alcanzables
desde una ref. Comprobado: `unknown revision d8c1c27add16`. (`git fetch <sha>`
sí lo trae; `go` no usa esa vía.)
⚠ SEGURO y comprobado, no supuesto: entre master y el commit pineado hay TRES
commits y el diff entero es `udp.go` +2 y `udp_test.go` +2 —sólo la línea
`// +build !windows`— más `udp_windows.go` nuevo con `// +build windows`. Para
GOOS=linux el código compilado es IDÉNTICO, y esto construye x86_64-linux-musl.
Va como PATCH y no como fase porque `vendor_go_deps` corre en el fetch
(lib.rs:277), antes de las fases; los patches se aplican antes (lib.rs:224).
Verificado: el patch aplica limpio sobre un checkout pristino, hammer sella, y
el binario arranca e imprime su versión.
samba.org borró `rsync-3.4.4.tar.gz` (404) y en ese directorio ya sólo queda
3.5.0. Tampoco estaba en nuestro mirror, así que la receta era INCONSTRUIBLE:
la única fuente MUERTA del corpus según docs/state/fuentes-vigia.json (1164
vivas / 3 muertas; las otras dos son un 502 transitorio de savannah).
⚠ NO es «cambiar el sha256 para tapar un 404» (lo prohibido por ADR 0013): el
tarball es OTRO, con su versión y su hash propios. Provenance verificada de
verdad, no asumida:
gpg --verify rsync-3.5.0.tar.gz.asc rsync-3.5.0.tar.gz
→ Good signature from "Andrew Tridgell <andrew@tridgell.net>"
RSA key 9FEF112DCE19A0DC7E882CB81BB24997A8535F6F
Clave traída de keys.openpgp.org; su fingerprint coincide con el `issuer` del
.asc. El aviso «User ID not certified» es esperable (no hay web-of-trust acá);
la firma en sí es válida.
Comprobado ANTES de subir: las diez opciones de configure siguen existiendo en
3.5.0, `rrsync.1` sigue en la raíz, y dont-use-nobody.patch aplica limpio
(`patch -p1 --dry-run` sin rechazos).
Verificado: sella, artefacto de 3,3 M con rsync/rrsync/rsync-ssl, y el binario
responde `rsync version 3.5.0 protocol version 32`.
CPython abortaba `_ssl` con «OPENSSL_THREADS is not defined, Python requires
thread-safe OpenSSL», y la receta lo daba por imposible sin rehacer openssl.
CAUSA RAÍZ, probada: no es openssl, es `link = "static"`.
`hammer-build/src/lib.rs:285` inyecta `LDFLAGS=-static`, y el Configure de
openssl (línea 1514) hace:
if (grep { $_ =~ /(?:^|\s)-static(?:\s|$)/ } @{$config{LDFLAGS}}) {
disable('static', 'pic', 'threads');
}
⇒ el propio `-static` apaga los threads en silencio. Añadir `threads` explícito
NO sirve (el disable() va después y gana): el configuration.h salía byte a byte
idéntico. Dentro del sandbox `configdata.pm` decía `thread_scheme => pthreads`
pero `THREADS_DEFINE=0`; fuera del sandbox, los mismos flags —y hasta con el
perl del corpus— SÍ definían el macro. La diferencia era el entorno.
`openssl-threads`: misma receta con `link = "dynamic"` (mantiene `no-shared`,
sigue emitiendo .a). Verificado: OPENSSL_THREADS definido y 36 símbolos
pthread_ reales en libcrypto.a.
VARIANTE y no tocar `recipes/openssl.toml`: de la canónica cuelgan los CUATRO
kernels (linux, linux-generic, linux-metal, linux-metal-dual) y la reproducción
bit a bit del 6.16.12 es un resultado cerrado; moverle el hash lo invalidaría,
más 125 sellados.
Además `ssl` entra en la asserción del install. Sin ese guardián se volvería a
sellar un intérprete mudo — que es justo como esto estuvo escondido meses.
Verificado: `checking for stdlib extension module _ssl... yes`,
_ssl.cpython-312-x86_64-linux-musl.so instalada, y el propio install imprime
`modulos opcionales: OK` importando ssl.
⚠ Mueve el hash de python3: 251 dependientes directos, ~369 sellados en los
cinco grafos (161 en KDE). Es el coste aceptado de la decisión.
Con gtk4 ya sin objetivos compartidos, estas tres dejaron de fallar por PIC
(0 errores) y pasaron a morir en el link con `unable to find static system
library 'lzma'`.
Misma causa que appstream: declaran `appstream` y `libxmlb` pero no `xz`, y
`libxmlb.pc` trae `Requires: gio-2.0, liblzma, libzstd`. Al enlazar appstream
estática necesitan la liblzma igual. Patrón `.pc Requires`→[deps]; `xz` va
junto a `zstd`, que viene del mismo .pc.
Con esto cierra la clausura ENTERA de gtk4 en el grafo del corpus, las 6 que
colgaban de él: gtk4-hello, libadwaita, gtksourceview, adwaita-hello,
sourceview-hello y hammer-edit — todas SELLADAS y con binario real.
`gtk/meson.build` declara dos hermanos con llamadas explícitas —`static_library('gtk')`
y `shared_library('gtk-4')`— y por ser explícita, `-Ddefault_library=static`
NO la suprime: no hay flag. Esa .so era el único objetivo compartido que se
enlazaba, arrastraba CINCO archives sin PIC (libtiff, libfreetype,
libfontconfig, libjpeg, libpng16) y moría con 13930 `relocation … recompile
with -fPIC`. Un ejecutable puede enlazar una .a no-PIC; una .so no.
Se apagan con `build_by_default: false` + `install: false` vía dos seds
acotados por rango (tocan 1 de 10 y 1 de 3 `install: true` respectivamente).
⚠ `build_by_default: false` NO BASTA SOLO: ninja construye igual lo que algo
NECESITA. El primer intento falló exactamente así — `shared_module('printbackend-file')`
depende de `libgtk_dep` y el fuente avisa «The 'file' print backend cannot be
disabled» (está fuera de los `if` de cpdb/cups), así que devolvía la .so al
grafo y re-aparecían los 13930 errores. Por eso se apagan LOS DOS.
En todo el árbol hay 5 objetivos compartidos: libgtk-4.so, printbackend-{cpdb,
cups,file} y media-gstreamer; las flags ya quitaban tres, estos seds los otros dos.
No se borra la declaración de libgtk: `pkg_config.generate(libgtk)` la necesita
para emitir el .pc con `-lgtk-4`, que es el nombre del archive GORDO que fabrica
la fase install. Nada la enlaza: los usuarios de `libgtk_dep` son demos, tests,
testsuite, examples y los backends de impresión/media, todos desactivados.
Verificado: sella, 0 errores PIC, 0 .so enlazadas, targets 997→993. Artefacto
con gtk4.pc `Libs: -lgtk-4`, libgtk-4.a de 808 objetos y `gtk_window_new` como
símbolo T definido. Las colas wlr/gnome tienen sus PROPIAS recetas de gtk4.
Quinta de la familia (appstream, cargo-deb, cargo-make, dprint). Sin `[deps]`
el link muere con `unable to find static system library 'lzma'`. Pendiente de
verificar en la próxima parada; el patrón está verificado tres veces.
Falla con las DOS a la vez: `unable to find static system library 'lzma'` y
`… 'bz2'`. La receta no tenía `[deps]`.
Cuarta de la misma familia esta noche (appstream, cargo-deb, cargo-make): el
lab trae el toolchain de Rust pero NO las libs C que los crates `*-sys`
esperan del sistema. El arreglo va en [deps], NUNCA engordando el rootfs
(regla de rootfs-laptop-worker-divergen).
NO se añade en bloque a las 220 recetas Cargo sin [deps]: la mayoría construye
bien y re-hashearlas invalidaría las ya selladas. Se arregla la que falla.
⚠ Pendiente de verificar como cargo-make en su momento; el patrón está
verificado tres veces (appstream, cargo-deb, cargo-make selladas tras el mismo
arreglo). Se verifica en la próxima parada.
`unable to find static system library 'bz2' using strategy 'no_fallback'`. La
receta no tenía `[deps]`: el lab trae el toolchain de Rust pero no las libs C
que los crates `*-sys` esperan del sistema. bzip2 está sellado y aporta
/usr/lib/libbz2.a.
Tercera de la misma familia esta noche: appstream (lzma vía el .pc Requires de
libxmlb), cargo-deb (lzma vía lzma-sys) y ésta (bz2). El síntoma del linker es
idéntico en las tres y el arreglo también.
⚠ PENDIENTE DE VERIFICAR: las otras dos se construyeron y sellaron antes de
commitear; ésta no, para no parar el driver una vez por receta. Se verifica en
la próxima tanda de reanudación. Si fallara, el patrón —no la receta— es lo que
habría que revisar.
La receta NO tenía `[deps]` en absoluto. El lab trae el toolchain de Rust pero
no las libs C que los crates `*-sys` esperan del sistema, así que el link moría
con `unable to find static system library 'lzma' using strategy 'no_fallback'`.
El log lo confirma: vendoriza y compila `lzma-sys v0.1.20`.
Mismo fallo y mismo arreglo que `appstream.toml` de hace un rato, por vías
distintas: allá liblzma entraba por el `.pc Requires` de libxmlb, acá por un
sys-crate. El síntoma del linker es idéntico.
Verificado: sella en 3m02s, artefacto de 4,6 M con un ELF real en
/usr/bin/cargo-deb. Blast radius nulo: en deuda en los cinco grafos con 0
dependientes sellados.
libxmlb.pc → Requires: gio-2.0 >= 2.45.8, liblzma, libzstd
appstream declaraba libxmlb y zstd pero NO xz, así que el link moría con
`unable to find static system library 'lzma'`. Patrón `.pc Requires`→[deps].
Se veía primero en los binarios de tests/ (as-test_xml, as-test_validate…) y
appstream 1.0.5 NO tiene opción `tests` en meson_options.txt. Sedear
`subdir('tests')` —como ya hace la receta con docs/— habría tapado el síntoma
y dejado el fallo para los 4 dependientes, que enlazan appstream estática y
necesitan la liblzma igual.
Verificado: sella en 23 s, 0 errores de lzma, artefacto de 18 M / 97 ficheros.
Blast radius nulo: en deuda en los cinco grafos con 0 dependientes sellados.
El dependiente adwaita-hello pasa de fallar en 23 s a 3m33s y ahora muere en
gtk4 (libgtk-4.so contra libtiff/libfreetype/libfontconfig/libjpeg/libpng16
no-PIC), que es una decisión de arquitectura aparte y sigue abierta.
En 2.44 `gif` es opción propia con default `auto` y ya no cae bajo `others`.
Sin declararla, el loader de GIF se construía como MÓDULO COMPARTIDO
(`libpixbufloader-gif.so`, el único .so de los 14 targets; el resto son
ejecutables), y una .so no puede enlazar una .a sin PIC: 1978 errores
`relocation R_X86_64_32 ... recompile with -fPIC`, todos de /usr/lib/libpng16.a
(que es --disable-shared).
Coherente con la intención declarada de la receta —«solo PNG (leaf mínimo)»:
jpeg y tiff ya se desactivaban; gif se coló por DERIVA DE VERSIÓN. Por eso el
arreglo es la flag y NO `[deps]`: cambiar libpng→libpng-pic es la decisión de
arquitectura que se descartó para el canónico el 2026-08-21, y que las colas
wlr/gnome resuelven con SOMBRAS propias.
Regresión CONGELADA, no fallo nuevo: se servía por cache-hit y sólo aparece al
reconstruir. Tumbaba en cascada xdg-desktop-portal, gnome-desktop, gjs, gdm,
gnome-session, gnome-settings-daemon y gnome-shell — todas fallando en 2-45 s
por su dep, no por sí mismas.
Verificado: sella en 12 s, 0 errores PIC, artefacto de 58 M con
libgdk_pixbuf-2.0.a y ningún .so. Blast radius nulo: el canónico estaba en
deuda con 0 dependientes sellados en los cinco grafos.
sway es `link = "dynamic"` A PROPÓSITO —un compositor dlopea los drivers DRI de mesa en runtime— y
sale con doce NEEDED. Nueve los cubría la clausura (pixman, drm, evdev, input, udev, wayland-server,
wlroots, xkbcommon, libc), porque esas recetas ya son dinámicas. Los otros tres —libz.so.1,
libexpat.so.1, libffi.so.8— venían de recetas `--disable-shared`, así que NINGÚN artefacto sellado
producía ese `.so` y el rootfs los resolvía contra el sysroot Alpine DEL LAB.
POR QUÉ ERA PEOR QUE UNA DEP FALTANTE. Una dep ausente falla ruidosamente. Ésta no: el lab NO entra
en `hash_inputs`, así que el store daba el artefacto por bueno mientras el binario sólo arrancaba en
una máquina que tuviera Alpine debajo. La fuga era invisible para todo el sistema de medición.
`zlib-shared` ya existía en el corpus y sólo faltaba declararla. `expat-shared` y `libffi-shared` son
nuevas, calcadas del patrón: autotools con --enable-shared, sin el truco de --whole-archive que
zlib-shared necesita porque SU configure aborta bajo zig cc. SONAMEs verificados contra lo que pide
el ELF: libexpat.so.1, libffi.so.8, libz.so.1. Exactos.
NO se tocó `link` en las canónicas: entra en `hash_inputs` y habría re-hasheado expat, libffi y todo
lo que los lista en deps —fontconfig, dbus, mesa, glib, python3, los crates `-sys`— cientos de
recetas selladas por libs que ya están bien. El nombre `*-shared` es distinto del canónico, así que
conviven. Verificado antes de construir: recalculadas las 794 recetas, **0 hashes cambiados**, sólo
las 2 nuevas.
Van al CORPUS y no a incoming-wlr/ porque la resolución de deps es hermano→padre: una receta del
corpus no ve una cola. Es donde ya viven zlib-shared, fontconfig-shared, freetype-shared…
VERIFICADO CON PÍXELES, no con el log. Rootfs rehidratado desde cero (126/126), CERO ficheros de
`.dev-fs/alpine`. Cero «Error relocating». La captura tiene el MISMO sha256 que la de las libs de
Alpine: 177fea396caa9dca, 1280x720, 383 colores. Tercera vez que la evidencia sale bit a bit igual
al cambiar la procedencia — la soberanía no costó ni un píxel.
Perfil: escritorio-sway 126/128. Faltan strace (linux-headers del lab) y rsync (404 de upstream).
QUEDA UN RESTO: el loader `/lib/ld-musl-x86_64.so.1` todavía se toma del host. `recipes/musl.toml`
existe en el corpus pero está EN DEUDA y fuera de todo perfil — mismo agujero de declaración, un
nivel más abajo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
`dejavu-fonts` y `xkeyboard-config` entran en `recipes/incoming-wlr/` y en las raíces de
`escritorio-sway`. La clausura pasa de 123 a 125 y ambas ya estaban selladas: cero builds.
POR QUÉ TENÍAN QUE SER RAÍCES Y NO PODÍAN LLEGAR POR CLAUSURA. Son DATOS, no binarios: ninguna
receta depende de una fuente ni de un mapa de teclado para COMPILAR. El grafo puede seguir todas las
aristas que quiera y no va a alcanzarlas nunca. Si no se declaran, no están — y el perfil sigue
dando 100%, porque mide la clausura de las raíces declaradas.
Copias BYTE-IDÉNTICAS a las de incoming-kde, a propósito. Ya había tres copias iguales de
xkeyboard-config (kde, gnome, cosmic) y dos de dejavu-fonts (kde, cosmic); ésta es la cuarta. No se
consolidan al corpus ahora porque eso toca las colas de otros tres frentes que otros agentes
trabajan. Mantenerlas idénticas deja esa consolidación como un `git mv` trivial en vez de un merge:
cuatro ficheros iguales se unifican de un tirón, cuatro casi-iguales exigen revisión.
VERIFICADO de punta a punta, no por el log: rootfs rehidratado DESDE CERO con sólo lo que la
clausura declara (123/123), y `sway-headless.sh` sin una línea de inyección manual de fuentes ni
XKB. Cero errores de xkbcommon, cero de fcft. La captura resultante tiene el MISMO sha256 que la de
ayer con todo inyectado a mano — 1280x720, 383 colores. La declaración es exactamente equivalente a
la inyección, y el pipeline reproduce.
Queda como deuda real (no de declaración): libz.so.1 / libexpat.so.1 / libffi.so.8, que sway pide
por estar enlazado dinámico y el corpus sólo produce como `.a`. Y `fonts.conf` NO era deuda: lo trae
el propio artefacto de fontconfig.
Perfil: escritorio-sway 123/125. Los 2 que faltan son strace (choca con los linux-headers del lab) y
rsync (404 de upstream), ninguno del escritorio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o
gdk-pixbuf no sellaba, y las dos libpng del corpus fallaban por extremos
OPUESTOS — probadas las dos hoy, una detras de otra:
libpng .a sin PIC → «relocation R_X86_64_64 cannot be used against
local symbol; recompile with -fPIC», porque ese
link acaba siendo dinamico (aparece libc.so)
pese al `link = "static"` de la receta.
libpng-shared solo la .so → «unable to find static system library 'png16'»,
porque la receta pide --prefer-static.
Es la misma tenaza que el `bz2` de freetype: los -dev traen .so pero no .a. La
salida no es elegir un extremo sino una .a que TAMBIEN sea PIC. `libpng-pic` es
copia literal del canonico con `--with-pic` en el configure; nada mas.
EVIDENCIA de que es PIC, y hay que medirla bien: 0 relocs R_X86_64_32/32S
contra 706 del canonico — EXCLUYENDO las secciones .debug_*. Sin ese filtro
ambas dan >13000 y parecen identicas; es la correccion de la regla del .a
no-PIC que ya nos mordio en GNOME.
El canonico NO se toca (decision del usuario): 12 dependientes en cuatro colas
y es estatico por diseño. Se añade una SOMBRA en incoming-wlr que cambia una
sola linea de deps. libpng-pic si va al corpus, porque la resolucion es
HERMANO→PADRE y una receta del corpus no veria una variante en incoming-*.
⚠ ALCANCE: la sombra la ve su cola. gtk4, libadwaita, gtksourceview y otras 4
son del CORPUS y siguen resolviendo el gdk-pixbuf canonico roto.
⚠ NO ERA UN FALLO NUEVO: gdk-pixbuf tenia artefacto sellado y se servia por
cache-hit. La reconstruccion no lo rompio, lo DESTAPO.
Verificado: sombra SELLADA, 71 MB, con .a, .pc y los loaders .so reales — no un
directorio vacio haciendose pasar por artefacto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
Consulta solo las recetas que HOY no tienen licencia, asi que su cosecha MENGUA
a cada pasada: lo sembrado ayer ya no sale en --faltan. Y reescribia el fichero
entero con la cosecha del dia. Hoy una pasada con CERO detecciones dejo
docs/licencias-detectadas.tsv en 0 filas y se llevo las 610 que documentaban de
donde salia cada licencia ya sembrada.
Salio con exit 0 diciendo «escrito» y «sembrar con». Un vacio que llega hasta el
final afirmando que todo fue bien — la regla 3 de CLAUDE.md, esta vez sobre el
registro de procedencia en vez de sobre un artefacto.
Ahora FUSIONA con lo registrado (la fila nueva gana) y se niega a sobrescribir
si el resultado pierde filas: un registro de evidencia que encoge es un fallo,
no un resultado. Con CON=0 lo dice y no invita a sembrar nada.
Y las cuatro de HashiCorp quedan declaradas: BUSL-1.1.
No es adivinado ni sale de la API —que devuelve NOASSERTION en las cuatro, y por
eso llevaban meses sin licencia—: es el texto del LICENSE del TAG QUE LA RECETA
PINEA, no el de la rama por defecto. consul v1.22.7, vault v1.21.4, nomad
v1.11.3 y packer v1.15.4 abren con «Business Source License 1.1».
⚠ BUSL-1.1 NO es una licencia libre: prohibe el uso en produccion que compita
con el producto de pago, y solo pasa a MPL-2.0 cuatro años despues de cada
version. Cuatro paquetes del catalogo publicable no son redistribuibles como si
fueran libres.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
Cadena probada de punta a punta (2026-08-12):
1. Se añadio `bzip2-dev` al lab para que CPython tuviera sus modulos.
2. freetype AUTODETECTA bzip2 —la receta desactivaba harfbuzz y brotli de
forma explicita, pero no este— y lo grabo en su freetype2.pc:
`Requires: zlib, bzip2, libpng`.
3. Toda receta que enlaza freetype con `-all-static` resuelve ese Requires
via pkg-config y pide `-lbz2`.
4. Los `-dev` de Alpine traen `.so` pero NO `.a` ⇒ «unable to find static
system library 'bz2'».
5. Cayo fontconfig y con el 27 recetas: KDE, GNOME y COSMIC dependen de el.
Verificado: el freetype nuevo vuelve a `Requires: zlib, libpng` y fontconfig
SELLA (8290b402...).
Se arregla en la receta y NO quitando bzip2-dev del lab: esto mueve el hash
de freetype y sus dependientes; lo otro re-hashearia el corpus ENTERO por
tercera vez en un dia. freetype solo usa bz2 para fuentes PCF comprimidas.
⚠ Metodo, porque me costo tres hipotesis fallidas: hay CINCO artefactos de
freetype en el store y mirar uno al azar dio el `.pc` equivocado. Y al
apartar bzip2.pc el error cambio a «freetype2 not met» — eso era evidencia A
FAVOR (pkg-config no podia resolver el Requires) y lo lei como si fuera en
contra. Comprobar el hash VIGENTE, no el primero que lista `ls`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decision del usuario. CPython construye sus modulos opcionales como .so
COMPARTIDOS y las .a del corpus NO son PIC («relocation R_X86_64_PC32 against
symbol 'stdscr'»), asi que declararlas en [deps] NO funciona: se probo una
por una. Las libs del rootfs son compartidas y si sirven.
Añadidos: libffi-dev ncurses-dev readline-dev sqlite-dev bzip2-dev xz-dev
expat-dev. Resultado VERIFICADO: el guardian de python3 importa los OCHO
modulos (_ctypes _curses readline sqlite3 bz2 lzma zlib pyexpat) y pasa. De
paso `libffi` sale de [deps]: ya lo aporta el lab.
openssl-dev NO va, deliberado: se de-Alpinizo porque el host-tool del kernel
enlaza el openssl del corpus desde el overlay; devolverlo podria cambiar el
artefacto del kernel. python3 sigue sin `ssl`.
Y SE CIERRA EL AGUJERO QUE ESTO ABRIA. Esas libs del rootfs ahora entran en
el CONTENIDO de un artefacto, asi que su version es parte de su identidad ⇒
van a TOOLCHAIN_PREFIXES. Sin eso habriamos reabierto en pequeño el mismo
fallo que 58d3161 cerro: instalar los -dev subio ncurses 6.5→6.6 y readline
8.3.1→8.3.3 —sin tocar gcc/rust/musl, lo confirmo el lock— y ese salto habria
cambiado el python3 producido SIN mover su direccion.
Coste: la huella del lab cambia ⇒ el corpus se re-hashea otra vez. Se hace
AHORA a proposito, con 194 artefactos, no con el corpus a medio construir.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estado VERIFICADO: con libffi el build sella y el guardian de la fase install
imprime «modulos opcionales: OK» ⇒ _ctypes y zlib importan de verdad.
El guardian es la pieza que mas vale de este commit: `configure` de CPython
OMITE en silencio cada modulo opcional cuyos headers no encuentra, `make`
termina 0 y el artefacto se sella mutilado. El error aparece dias despues en
OTRA receta (gjs, gdm) como ModuleNotFoundError y no se parece a su causa.
Importarlos en install lo convierte en un fallo en la receta correcta.
Lo que NO se pudo añadir, probado uno por uno y documentado en la receta:
openssl → el del corpus es libcrypto ESTATICA sin threads; CPython aborta
con «OPENSSL_THREADS is not defined». Sin modulo `ssl`.
ncurses → `.a` no-PIC: _curses_panel.so no enlaza
(«relocation R_X86_64_PC32 ... against symbol 'stdscr'»).
sqlite/bzip2/xz/readline/expat → mismo muro no-PIC (_lzma lo destapo).
CPython construye sus modulos opcionales como .so COMPARTIDOS, y las .a del
corpus no son PIC. El python3 viejo tenia _ctypes Y _curses porque se
construyo contra las libs COMPARTIDAS del rootfs de entonces; el lab anclado
trae los runtime pero no los headers.
⇒ _curses sigue roto y con el la familia GNOME. Arreglarlo pide DECIDIR:
meter los -dev en la imagen del lab (re-hashea el corpus otra vez, barato
AHORA que van 48 de 1186) o hacer recetas PIC de esas libs (frente nuevo).
Queda para el usuario.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Destapado reconstruyendo el corpus: gjs y el build de mozjs morian con
`ModuleNotFoundError: No module named '_ctypes'`. La causa no estaba ahi: el
artefacto de python3 se sella SIN ese modulo y arranca perfectamente; el
fallo aparece mucho despues, en otra receta. 310 recetas dependen de python3.
El rootfs del lab trae libffi (runtime) pero NO sus headers — no hay
libffi-dev en el lock. El configure de CPython no encuentra ffi y omite
_ctypes sin fallar. recipes/libffi.toml si instala headers y .pc, y pkgconf
—ya declarado— los ve en la capa overlay.
Por que aparece AHORA y no antes: el artefacto viejo de python3 tenia _ctypes
porque el rootfs de entonces traia los headers, y el cache-hit lo mantuvo
congelado hasta que el corpus se re-hasheo. Mismo patron que
make/--disable-load: reconstruir destapa lo que la cache sostenia.
Se arregla ahora y no mas tarde a proposito: mover el hash de python3 mueve
el de sus 310 dependientes, y con solo ~48 recetas selladas eso es barato.
Dentro de dos dias no lo habria sido.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sintoma: al reconstruir el corpus, bash/binutils/bison/busybox/zlib morian
con exit 139. dmesg lo nombraba: `traps: make general protection fault in
ld-musl-x86_64.so.1`.
Causa exacta, leida de la linea de link real:
hammer-zig-cc -g -O2 -Wl,--export-dynamic -static -o make src/*.o
GNU make 4.4.1 soporta cargar objetos en runtime (directiva `load`), asi que
su configure anade -Wl,--export-dynamic. El wrapper hammer-zig-cc tiene la
regla —correcta— de que `-static` CEDE ante cualquier link que exija dinamico,
y --export-dynamic es uno de esos marcadores ⇒ le quitaba el -static y se
sellaba un make dinamico que segfaultea. Como toda receta autotools invoca
make, se propagaba a casi todo el corpus.
El arreglo va en la receta y NO en el wrapper: el conflicto es de origen
—pedimos estatico de un proyecto que pide symtab dinamica para una funcion
que no usamos—. Ensenarle al wrapper a ignorar --export-dynamic lo romperia
para gobject-introspection, que si lo necesita.
POR QUE NO SE VIO ANTES, que es la leccion: el artefacto viejo de make era
estatico y estaba congelado por cache-hit, probablemente desde antes de que
existiera esa regla del wrapper. Nadie lo reconstruyo hasta que el corpus se
re-hasheo entero. Un cambio que "no re-hashea nada sellado" igual cambia lo
que producen los builds FUTUROS, y eso queda invisible hasta que algo fuerza
la reconstruccion.
Verificado: make ESTATICO, corre (GNU Make 4.4.1), y zlib —que fallaba con
139— sella.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los dos simbolos ya no existen en 6.16.12, asi que `-d THUNDERBOLT` y
`-d REISERFS_FS` eran no-ops silenciosos: scripts/config los escribia y el
olddefconfig siguiente los tiraba por desconocidos.
No son el mismo caso y por eso no reciben el mismo trato:
- THUNDERBOLT se FUNDIO, no se fue. drivers/thunderbolt/Kconfig declara
`menuconfig USB4` = "Unified support for USB4 and Thunderbolt". El simbolo
cambio de nombre, la intencion de apagarlo sigue viva ⇒ se renombra a
`-d USB4`, que ademas pasa a ser un guardian de verdad: si un dia la base
o un `select` lo encienden, ahora si lo apaga.
- REISERFS_FS se RETIRO del kernel. No hay nada que apagar ⇒ se quita.
El .config resultante NO cambia hoy: USB4 no aparece en x86_64_defconfig y su
Kconfig no trae `default`, asi que ya estaba en n. Lo que cambia es el
ArtifactHash de los cuatro, porque el texto de la fase configure entra en
hash_inputs. Los cuatro artefactos viejos siguen en el respaldo como
superados; no se pierde nada.
Verificado contra el arbol real (work/kconfig-6.16.12/), no de memoria.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
COSMIC cerró 25 de 30 raíces. De los 5 fallos, CUATRO daban el mismo mensaje —
«error: no suitable Python interpreter found»— en wireplumber, xdg-desktop-portal,
xdg-desktop-portal-cosmic y cosmic-settings-daemon.
NO ERA DE ELLAS, Y NI SIQUIERA ERA DE MESON. El error viene de un `configure` de AUTOTOOLS que
prueba `python2.2`, `python2.1`, `python2.0` —literalmente— y aborta al no hallarlos. Se
identificó por las flags del comando en el log (`--disable-mpeg --disable-full-suite`), que son
inconfundibles de **libsndfile**: una dep común a las cuatro.
Y declarar `python3` en `[deps]` NO ayuda —dos de las cuatro ya lo tenían—: el problema no es
que falte el intérprete, es que el script no reconoce ese NOMBRE. Autoconf respeta la variable
de entorno `PYTHON`, así que se le pasa `PYTHON=python3` y sella.
LA LECCIÓN, que hoy ya se repitió con `dbus-shared`: cuando varias recetas fallan con el MISMO
mensaje raro, el fallo está en una dep común — y **la forma de identificarla es mirar QUÉ
configure/meson.build lo emite**, no la receta que se estaba construyendo. Las flags del comando
y el número de línea del meson.build son la firma del paquete que realmente muere.
Aplicado a las tres copias (incoming-gnome, -cosmic, -kde), que dan el mismo hash. Y de paso
`cosmic-settings-daemon` sí necesitaba `python3` en deps, que no lo declaraba: dos causas
distintas bajo un mensaje idéntico.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`mutter`, `gnome-shell` y `xdg-desktop-portal-gnome` fallaban las tres con «ERROR: Unhandled
python exception». Las tres YA tenían `--wrap-mode=nodownload` en su propia receta, así que no
era eso — hasta que el log mostró la línea culpable:
meson.build:372:11: ERROR: Unhandled python exception
<urlopen error unknown url type: https>
WARNING: failed to download with error: name 'ssl' is not defined
La misma línea 372 que el fallo de `dbus` de hace unas horas. No fallaban ellas: fallaba una
DEP que arrastran, `dbus-shared`, cuya sombra en incoming-gnome e incoming-cosmic no tenía la
flag. La canónica del corpus y la sombra de KDE sí la tenían; estas dos no.
⇒ UNA flag ausente en una sombra tumbaba TRES raíces de perfil en GNOME y bloqueaba COSMIC de
paso. Y el mensaje nunca nombra la red: «Unhandled python exception» se lee como un bug de
meson y es que el sandbox es hermético a propósito.
Lección de método: cuando tres recetas fallan con el MISMO error y las tres ya tienen el
arreglo obvio, el fallo está en una dep común, no en ellas. La línea de meson.build en el
mensaje es lo que lo identifica — es la firma del paquete que realmente muere.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Primera tanda con el orden nuevo (por impacto en el grafo, no alfabético). 30 recetas C de
clase HOJA: bash, coreutils, git, gnupg, grep, gzip, jq, e2fsprogs, libarchive, htop…
LA MEDIDA QUE JUSTIFICA EL CAMBIO DE ORDEN: activar estas 30 dejó 41 recetas sin artefacto
vigente = las 12 que ya estaban en deuda + las 30 tocadas (una ya estaba entre las 12). **Cero
colateral.** Contra la tanda anterior, donde tocar TRES bibliotecas base (expat, zstd, ncurses)
dejó 54 sin artefacto y tumbó la cadena wlroots/sway entera.
Mismo esfuerzo de build, diez veces menos destrozo. El orden no era un detalle de comodidad.
Selección: clase `c` + `dependientes_total == 0` + estado sellado, excluyendo las de tawasuyu
(git privado ⇒ no construyen en el worker, que es sin secretos por diseño) y las Go/Rust, que
necesitan sus módulos y fallan ahí. Quedan 73 hojas C elegibles; van 30.
La tanda corre DESASIDA con nohup en el worker — la lección de ayer, cuando un drenaje murió a
las 14 de 54 al caerse la sesión ssh.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`base`, `cli` y `escritorio-sway` bajaron a 50/51, 73/74 y 120/121 después de la cascada del
split, y los tres fallaban por LA MISMA receta: dbus.
EL ERROR NO MENCIONABA LA RED POR NINGÚN LADO:
meson.build:372:11: ERROR: Unhandled python exception
Y arriba, enterrado entre reintentos:
<urlopen error unknown url type: https>
WARNING: failed to download with error: name 'ssl' is not defined
dbus declara subproyectos con `.wrap` y meson intenta DESCARGARLOS. En el sandbox no hay red y
python no trae ssl ⇒ «Unhandled python exception», que se lee como un bug de meson y es
simplemente que no hay salida a internet. Y no debe haberla: el build es hermético a propósito.
`--wrap-mode=nodownload` obliga a usar las deps del sistema (nuestros artefactos, vía
pkg-config) y deja los wraps inertes. Mismo caso que `wl-clipboard` anoche.
⇒ base 51/51 · cli 74/74 · escritorio-sway 121/121. Los tres cierran otra vez.
ESTADO DE LA REPARACIÓN DE LA CASCADA: de las 54 que quedaron sin artefacto, 42 reconstruidas.
Las 12 restantes son EXACTAMENTE las que ya estaban en deuda antes de la campaña:
· 6 el muro del PIC (gtk4 y su cadena estática — duplicado superado de la dinámica de GNOME);
· 3 HUB-ONLY (mirada-*, llimphi-counter: git privado / commit en ceros);
· dwarves (libdw/musl), y adwaita-hello (error 39 = la carrera del ADR 0012).
O sea que la campaña no dejó deuda nueva.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
zstd 12M→2M (−83%) · ncurses 6M→2M (−67%) · expat 2M→1M (−50%). Cero ficheros vacíos y
**las tres REPRODUCEN**. La maquinaria de la etapa 4 queda validada de punta a punta:
activar → construir en la granja → verificar con why-differs.
LA DEP DE binutils VA EXPLÍCITA, y es la decisión de diseño de esta etapa. El paso de strip usa
`strip --strip-debug -D` de binutils. Se podría hacer que el lab lo materialice solo, sin tocar
las recetas — pero entonces la VERSIÓN de binutils sería un input INVISIBLE: dos corridas con
binutils distintos darían artefactos distintos con el mismo hash. Los `deps` sí entran en
`hash_inputs`, así que declararlo es lo único que mantiene el invariante. Cuesta una edición
mecánica por receta; el invariante no se negocia por comodidad.
EXCLUSIONES, y son exactamente dos: `binutils` y `make`. binutils provee el strip y depende de
make ⇒ activarles el split los haría necesitarse a sí mismos para construirse. No es preferencia,
es la circularidad. (Las recetas CERRADAS POR DECISIÓN tampoco se tocan.)
POR TANDAS Y NO DE GOLPE: activar re-hashea la receta a propósito y en cascada todo lo que
dependa de ella. Hacerlo sobre las 775 candidatas a la vez dejaría el corpus entero sin sellar
al mismo tiempo — días de granja antes de poder verificar NADA, y el disco aguantando artefactos
viejos y nuevos a la vez. Por tandas se mide, se verifica y se poda entre medias, que es lo que
hace la campaña reversible.
La primera tanda NO se tomó del orden alfabético que propone el script: ésas son CLIs Go/Rust
que ya vimos que no reconstruyen en el worker (necesitan red para sus módulos), y validar la
maquinaria con recetas que fallan por otro motivo no habría probado nada. Se eligieron tres
paquetes C con artefacto presente. Para las tandas grandes hay que resolver antes el acceso a
red de los módulos Go/Rust, o restringirse a lo que reconstruye.
Estado: 775 candidatas, 5 desplegadas (bison y appstream del piloto + estas 3).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RESULTADO, con los tres criterios medidos a la vez sobre las dos recetas que divergían:
bison 6M → 3M · 0 ficheros vacíos · 0 secciones .debug_ · «bison (GNU Bison) 3.8.2»
appstream 56M → 18M · 0 ficheros vacíos · 0 secciones .debug_ · «AppStream version: 1.0.5»
y las DOS pasan de DIVERGIR a REPRODUCIR.
O sea que un solo cambio recupera espacio Y cierra la fuga de reproducibilidad, como predijo el
§1.bis. Pero se llegó ahí después de tres errores que conviene dejar escritos.
🧨 1. `zig objcopy --strip-debug X X` (mismo fichero de entrada y salida) TRUNCA EL FICHERO A 0
BYTES. Destruyó los artefactos del piloto — y lo grave es que LOS TRES INDICADORES DECÍAN QUE
IBA BIEN: el tamaño cayó 84% (porque los ficheros quedaron vacíos), `why-differs` dijo REPRODUCE
(porque dos árboles vacíos son idénticos) y no quedaban secciones .debug_ (porque no quedaba
ninguna sección). Se cazó al EJECUTAR el binario: 0 bytes.
⇒ La verificación de un artefacto tiene que incluir que SIGA FUNCIONANDO, no sólo que pese menos
y reproduzca. Un artefacto vacío cumple las dos y no sirve para nada. Es la lección de esta
campaña aplicada a la campaña misma: una métrica que parece éxito.
2. Al arreglarlo con fichero temporal, el strip pasó a ser un NO-OP SILENCIOSO: los binarios
quedaban intactos y el tamaño no bajaba, porque no se pudo confirmar que `zig objcopy` acepte
`--strip-debug`. Cambiado al `strip` de binutils, que sí funciona, a costa de declarar la dep.
⇒ Preferible una dep explícita que funciona a una comodidad que no se sabe si hace algo.
3. Con el strip real, apareció una fuga NUEVA: los artefactos seguían divergiendo, ahora por la
CABECERA `ar` de los `.a` — `strip` los reescribe con los timestamps de cada corrida. Lo nombró
`why-differs` exacto («archivar en modo determinista»). Arreglado con `strip -D`
(= --enable-deterministic-archives). ⇒ Arreglar media causa deja el invariante igual de roto: el
debug ya no divergía y el archivo sí.
DISEÑO: `strip_debug` es un campo de la receta que ENTRA en `hash_inputs` y sólo si está fijado
(mismo patrón que `zig_version`). Las dos mitades importan y están clavadas en un test: si no
entrara, el lab cambiaría el contenido del artefacto sin mover el hash y el store MENTIRÍA; y al
entrar sólo si está fijado, se despliega receta a receta sin re-hashear las 1161 de golpe —
verificado: con el campo añadido al código, los 1161 hashes existentes NO se movieron.
Va como paso del lab y no en la fase install de cada receta porque 383 de las 1161 no tienen
install explícita: meterlo receta a receta obligaría a escribir a mano ese install por defecto en
las 383, con riesgo de no clavarlo exacto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decisión del usuario: promover una por una, verificando. Hecho así, y valió la pena.
EL RIESGO QUE SE TEMÍA NO APLICABA. La nota de `granja-promote-colisiones` advierte que
promover a ciegas hace que variantes homónimas pisen recetas canónicas. Acá no: los nombres
`*-shared` son DISTINTOS de los canónicos —`zlib-shared` no pisa a `zlib`— y se comprobó que
ninguna de las 19 sombras del catálogo choca con un nombre del corpus. Decirlo importa: repetir
una advertencia donde no aplica es tan malo como ignorarla donde sí.
VERIFICADO EMPÍRICAMENTE, no razonado: se calcularon los hashes de LAS 1153 recetas antes y
después de promover. **Ninguna cambió**, y las 8 nuevas tienen hash idéntico a su original ⇒ sus
artefactos ya están sellados y no hay que reconstruir nada. Promovidas: zlib, libpng, freetype,
fontconfig, libjpeg-turbo, libtiff, libxml2 y libyaml (todas en su variante -shared).
⛔ `cairo-shared` NO SE PROMOVIÓ, y el porqué es el hallazgo: su hash SÍ cambia al moverla,
porque una de sus deps —`glib`— resuelve distinto desde el corpus. En `incoming-gnome-onda2`
hay una SOMBRA DE GLIB CON EL MISMO NOMBRE que la canónica (`link=dynamic`,
`-Ddefault_library=both` en vez de static), y `cairo-shared` está construida contra ella.
⇒ O sea que el riesgo de homónimos SÍ existe, pero un nivel más abajo del que se miraba: no en
las `-shared`, sino en el `glib` sombra. Promoverlo pisaría la receta canónica de glib y
re-hashearía en silencio todo lo que cuelga de ella, que es medio catálogo. El camino limpio es
renombrarla a `glib-shared` —nombre que YA existe en incoming-cosmic— y reapuntar cairo-shared;
eso cambia hashes de la cadena GNOME y merece su propia decisión, no colarla acá de madrugada.
Con esto la cadena estática del corpus (gtk4 y las 6 que cuelgan) sigue bloqueada, pero ahora se
sabe exactamente por qué y cuál es el siguiente paso concreto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decidido el 2026-08-08. Las tres recetas dependen de GTK3 (gnome-settings-daemon además de
gtk+-x11-3.0) y quedan cerradas, **no «en deuda»**. La diferencia no es semántica: una deuda
invita a reintentarla en cada informe y en cada ciclo de granja; una decisión se respeta.
POR QUÉ ES RAZONABLE Y NO UNA RENDICIÓN:
· GNOME funciona sin esto — el camino vivo es mutter → gnome-shell arrancado por arje, y
ninguno de los dos depende de gnome-session (su cierre es mutter+gjs+gobject-introspection+
gnome-desktop).
· Traer GTK3 sería una torre de C muerta —y para waybar además gtkmm, sus bindings de C++—
por un gestor de sesión y un login manager que este escritorio no necesita.
· La función está cubierta: la sesión la levanta arje y la barra de estado es `yambar`, C puro,
sellado anoche en el frente wlr.
Se reabre si alguien trae GTK3 por otro motivo con peso propio (una app gráfica que lo exija).
EL MARCADOR VIVE EN LA RECETA, NO EN UNA LISTA APARTE. `build-farm.sh` salta las recetas cuya
cabecera dice «CERRADA POR DECISIÓN». Podría haber hecho un fichero de exclusiones, pero una
lista y una cabecera se desincronizan solas: así, quien lee el porqué y quien decide saltarla
miran EL MISMO TEXTO. Y el drenador lo dice en su salida, para que la decisión sea visible en
vez de silenciosa.
Con esto la granja deja de quemar CPU en tres recetas que nadie va a arreglar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`wl-copy` y `wl-paste`. En Wayland no hay forma de copiar o pegar desde un script sin esto, y
varios flujos que ya sellamos lo necesitan para ser útiles: capturar con grim, seleccionar
región con slurp, y poder pegar el resultado en algún lado.
UNA DIFERENCIA CON LAS ANTERIORES QUE CONVIENE NOTAR. Va por commit (ADR 0006, GitHub genera
sus archive/refs/tags al vuelo igual que codeberg), pero este tag es **LIGERO**: `git ls-remote`
devuelve UN solo sha y ése ES el commit. En fuzzel, yambar y foot los tags son ANOTADOS y
aparecen dos, donde el bueno es el `^{}`. Comprobar el tipo de tag antes de copiar evita pinear
el objeto del tag en vez del commit — un error silencioso, porque la receta valida y sólo falla
después, al no encontrar el árbol.
TRAE `subprojects/` CON WRAPS QUE BAJAN DE LA RED (expat, libffi, wayland, wayland-protocols).
`--wrap-mode=nodownload` es lo que lo impide y lo obliga a usar las del sistema, o sea nuestros
artefactos vía pkg-config. Sin esa flag el build intentaría salir a internet DENTRO del sandbox
hermético y moriría; con ella los wraps quedan inertes. Por eso las cuatro van en deps.
Estado del frente wlr: 10 recetas, 12 binarios — wlroots, sway (+swaybar/swaymsg/swaynag),
swaybg, swayidle, swaylock, grim, slurp, fuzzel, yambar, wl-copy/wl-paste. Con `foot` (ya en el
corpus) como terminal, el perfil «escritorio-sway» es armable: compositor, barra, lanzador,
fondo, bloqueo, inactividad, captura y portapapeles. Todo sin X11 y sin systemd.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5