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.
El driver marca FALLA en la receta que invocó, pero `hammer build` construye
deps recursivamente: si una dep muere, la FALLA sale a nombre del dependiente.
El 2026-08-27 siete recetas figuraban rotas (xdg-desktop-portal, gnome-desktop,
gjs, gdm, gnome-session, gnome-settings-daemon, gnome-shell) y ninguna lo
estaba: los 1978 errores los emitía gdk-pixbuf. Los tiempos de 2-10 s son la
firma — demasiado rápido para ser un build propio.
Método: quitar ANSI, partir el log por los marcadores `fetch … name=X` y
atribuir cada error al último fetch anterior. Ya destapó dos causas reales
(gdk-pixbuf/gif y gtk4/PIC) y desinfló la lista de la frontera _ssl, donde
`No module named` lo emite SÓLO spidermonkey.
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.
El store de hammer se mudó al volumen harkaq-cosecha (/dev/sdb, bind-mount
sobre ./store, work/sources y work/repos; CARGO_HOME también). Desde eso,
medir `$ROOT` mide /mnt/vvv, que hammer COMPARTE con tawasuyu y que ya no
es donde gasta.
Por qué se movió: tawasuyu repuebla su target a ~62 G/h. El 27/08 se le
liberaron 92,9 GiB con cargo clean, se lanzó la campaña con 64 G libres y
70 min después el disco estaba en 237 MB — la tanda abortó en cosmic-applets
por un disco que no era suyo. El cargo clean sirve para un pico, no para
financiar una campaña larga: el vecino lo recupera entero en una hora.
El vigía ahora toma el mínimo de {STORE, work/sources, CARGO_HOME}. Con
$ROOT veía 46 G y bajando; ahora ve 84 G reales.
Sergio