Yo mismo las reporte como "la misma clase de colision que onda1" y me pase: no
lo son. onda1 tenia una copia RANCIA del mismo build; esto son dos builds
distintos, cada uno correcto para su frente:
KDE link=dynamic --enable-shared --enable-cxx => libgmp.so + libgmpxx.so
COSMIC link=static --disable-shared => libgmp.a, sin C++
Las dos citan libqalculate y llegan a conclusiones opuestas sobre gmpxx.h, y las
dos tienen razon para su cola. Unificarlas romperia una de las dos.
Lo que compartir nombre SI cuesta es que hace ambigua la clasificacion de
store-gc: un artefacto rancio de una puede caer como SUPERADO porque la otra
tiene sellado vigente. La condicion es precisa y esta medida — solo hay riesgo si
el hash vigente de una NO esta sellado, y hoy las dos lo estan => exposicion
CERO. Antes de podar con nombres compartidos hay que comprobar ESO, no el nombre.
La salida, si algun dia molesta, es renombrar la dinamica a gmp-shared (la
convencion que el corpus ya usa: zlib-shared, cairo-shared...). No se hizo
porque cuesta: da 7 sellados de KDE que caen a deuda. es
el mismo par por la misma razon.
Los comentarios NO entran en hash_inputs (medido: mismo hash antes y despues),
asi que esto no re-hashea nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Al verificar la resolucion estricta de parches salio la unica referencia rota
del arbol: `.deferred/kalker.toml` pide `system-libs.patch` y el fichero estaba
en `recipes/`. Los patches se resuelven `base_dir.join(nombre)` sin fallback, asi
que la receta nunca lo habria encontrado.
No es una rotura nueva: `.deferred/system-libs.patch` no existio jamas (el
importador dejo la receta en .deferred y el parche en recipes/). Y es
inequivocamente de kalker — parchea `kalk/Cargo.toml` — ademas de que ninguna
receta lo citaba desde recipes/, o sea que ahi era un huerfano.
Ningun hash se mueve por esto. Referencias de parche: 95 resuelven, 0 rotas.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Era la cola de staging de las tandas base-system/foot y sus recetas ya se
habian PROMOVIDO a canonicas commit a commit ("promover 7 tier-2", "promover
cadena crypto", "promover tllist/utf8proc/scdoc/fcft/foot"). Lo que quedaba
eran 0 .toml y 26 .patch: 5 copias byte a byte de la version canonica de
recipes/ y 21 de recetas que ya no viven ahi.
No eran "probablemente inutiles": son inalcanzables POR CONSTRUCCION.
`fetch::apply_patches` resuelve `recipe.base_dir.join(nombre)` y `base_dir` es
el directorio de la receta, sin fallback a `recipes/` — un parche en una cola
sin recetas no lo puede pedir nadie.
⚠ El corolario queda escrito en farm-worker-loop.sh: al promover una cola, los
`.patch` NO viajan con la receta, y la cola queda en un estado que PARECE vivo
(tiene ficheros) sin moler nada.
Sale de QUEUES en farm-worker-loop.sh y de la lista de promote de farm-down.sh.
`incoming-go` se queda en las dos aunque el directorio no exista: es la cola
aislada del frente Go y el guard `ls $Q/*.toml` salta las vacias; quitarla seria
dejarla muerta el dia que ese frente la recree.
Verificado con la regla ESTRICTA de resolucion de parches sobre todo el corpus:
94 referencias resuelven, 0 rotas. (El chequeo que use al jubilar onda-2 era mas
laxo que hammer — aceptaba recipes/<parche> como fallback; su conclusion se
sostiene, pero el metodo queda corregido.)
Gate --check OK, grafo CIERRA, corpus 786/787.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
El caso LIMPIO del mismo fenomeno que onda-1, sin ninguna de sus asperezas: las
22 recetas son byte a byte identicas a las de incoming-gnome Y las 22 dan el
MISMO ArtifactHash, o sea la misma direccion del store. Sin divergencias, sin
colision de nombre y sin un solo artefacto que podar al retirarla.
La comprobacion que decide NO es `diff` sino `hammer hash`: la resolucion de
deps es hermano->padre, asi que dos ficheros identicos en colas distintas pueden
sellar distinto. Aca coinciden los 22.
Se va tambien `cairo-ctime-r.patch`, verificado identico al de incoming-gnome, y
comprobado que ninguna receta de ninguna cola queda apuntando a un parche
inexistente.
El andamio ya no sostenia nada: el trabajo de la isla dinamica vive en
incoming-gnome, que es la cola que el perfil usa. Sale de QUEUES en el mismo
commit, por la simetrica de la regla que ese fichero documenta.
Gate --check OK, grafo CIERRA, escritorio-gnome sigue 119/119, corpus 786/787.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Cierra la jubilacion empezada con gnome-desktop. Las 5 recetas que quedaban:
- glib, glib-introspected, gobject-introspection, py3-setuptools: byte a byte
identicas a las de incoming-gnome Y con el MISMO ArtifactHash, o sea que
sellaban en la misma direccion y entraban por cache-hit. Coste de build cero;
coste real: un segundo sitio donde editar, que se separa en silencio.
- gsettings-desktop-schemas: la unica distinta, y es la version ANTERIOR al
2026-07-28 (introspection=false + link=static). La vigente lo activo porque el
gir de Meta de mutter incluye GDesktopEnums-3.0.gir, que sale de ahi, y sin el
el g-ir-scanner corta en el ultimo target de mutter (721/722).
Lo caro no era el tiempo sino el NOMBRE: el gsettings viejo competia con el
bueno, dos artefactos homonimos con hash distinto en el store. Podado el
huerfano (0fb1703d, 155 KiB exclusivos) y anotado en el ledger anti-churn; los
otros cuatro artefactos siguen vigentes porque los produce incoming-gnome.
Y al jubilar gnome-desktop las dos hojas de la cola se habian quedado sin
consumidor: la cola se alimentaba a si misma y terminaba en el aire.
Sale tambien de QUEUES en farm-worker-loop.sh, por la simetrica de la regla que
ese fichero ya documenta dos veces: una cola ausente de la lista no da error,
da silencio — y una cola retirada que sigue en la lista, tambien.
Gate --check OK, grafo CIERRA, escritorio-gnome sigue 119/119, corpus 786/787.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Mismo paquete que `recipes/incoming-gnome/gnome-desktop.toml`: name, version
44.5 y sha256 identicos. La unica diferencia son las `[deps]`, y son las de
antes: a la de onda1 le faltan xkeyboard-config, iso-codes, libseccomp y todas
las variantes `-shared` que la canonica documenta como imprescindibles para el
scanner de introspeccion. Por eso moria con
Run-time dependency xkeyboard-config found: NO (tried pkg-config)
meson.build:64:17: ERROR: Dependency "xkeyboard-config" not found
que se leia como deuda de build y no lo era: arreglarla habria sido reescribirla
hasta volverla identica a la otra.
Nadie dependia de ella (los dependientes -mutter, gnome-shell, gnome-session,
gnome-settings-daemon, xdg-desktop-portal-gnome- viven en incoming-gnome y
resuelven contra su propia hermana). El gate `--check` sigue en OK y ningun
nodo cambia de estado; en los grafos solo baja `dependientes_total` de sus
deps, que es justo lo que tenia que pasar.
Sus dos artefactos quedaban sin receta que los produjera: podados y anotados en
el ledger anti-churn para que la cosecha no los devuelva.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Los 8 ejecutables decian static y enlazaban musl dinamicamente. La huella que lo
delata sin mirar el build: `readelf --dyn-syms` daba 21475 entradas contra ~2700
de un binario dinamico normal — eso es --export-dynamic, no un enlace corriente.
NO venia del meson de gtk (ahi no aparece la palabra) sino de un .pc DE
DEPENDENCIA: `gmodule-2.0.pc` trae literalmente `Libs: -Wl,--export-dynamic`, y
`meson.build:426` pedia `dependency('gmodule-2.0')`. El wrapper de cc del lab
(`sandbox.rs:597`) tira el `-static` ante --export-dynamic ⇒ lo ponia el lab y
lo sacaba el lab, por un flag heredado de una dep.
No hace falta parchear el .pc de glib: upstream ya publica la misma libreria sin
el flag. `gmodule-no-export-2.0.pc` trae el `-lgmodule-2.0 -pthread` de verdad y
los otros dos solo hacen Requires sobre el añadiendo --export-dynamic. Es la
palanca prevista, no un apaño — de hecho `gio-2.0.pc` de la propia glib ya usa
la variante no-export.
REGLA GENERAL: cualquier receta que enlace gmodule hereda --export-dynamic y
pierde el -static SIN AVISO. Si link=static no pega y hay glib de por medio,
mirar los .pc de las deps antes que el build del proyecto.
Y entonces aparecio un bug que SOLO existe en estatico: los 8 morian con SIGSEGV
hasta en `--help`. Backtrace con gdb:
g_module_symbol (module=0x0, symbol_name="gtk_progress_get_type")
_gtk_module_has_mixed_deps (module_to_check=0x0) at gtk/gtkmain.c:474
do_pre_parse_initialization () at gtk/gtkmain.c:498
gtk_init_check () at gtk/gtkmain.c:635
`_gtk_module_has_mixed_deps(NULL)` hace `g_module_open(NULL,0)` y pasa el
resultado a `g_module_symbol` sin comprobarlo. En musl ESTATICO `dlopen(NULL)`
devuelve NULL siempre ⇒ deref de nulo en el offset 8, en el arranque. Con libc
dinamica el bug no se ve nunca. Cuarto parche de la receta: la comprobacion que
falta. Devolver FALSE es correcto ademas de seguro — en un estatico no hay
modulos cargables, asi que no puede haber simbolos de GTK 2/3 mezclados.
Control: 423 ficheros intactos, NEEDED=0 en los ocho, .dynsym de 21475 a 0, los
ocho arrancan, gtk4-path-tool hace trabajo real, y `builder-tool validate`
devuelve EXACTAMENTE el mismo «Could not initialize windowing system» que daba
el binario dinamico anterior.
Cae en cascada el re-hash de 7 dependientes; se reconstruyen a continuacion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
No era purismo. El binario sellado, ejecutado fuera del sandbox:
Error relocating /lib/libncursesw.so.6: __vfprintf_chk: symbol not found
Salia dinamico contra `libncursesw.so.6` y `libc.so`, y NINGUN artefacto del
corpus provee esas dos —el de ncurses solo empaqueta .a—, asi que solo corria
dentro del rootfs de Alpine del sandbox. Esta en los perfiles base, cli,
escritorio-cosmic y escritorio-sway. Mismo sintoma que curl en su dia.
Causa: `configure.ac:1223` pone `LOCAL_LDFLAGS=-rdynamic` en linux* (para que
`enable -f` pueda resolver simbolos de bash), y el wrapper del lab quita el
`-static` ante `-rdynamic`. Es la misma raiz que htop y e2fsprogs.
`--enable-static-link` SOLO NO ALCANZA: pone `STATIC_LD=-static`
(`Makefile.in:170`) pero queda en la misma linea que el `-rdynamic` de
`BASE_LDFLAGS`, y el wrapper mira la linea entera. Van los dos.
PRECIO MEDIDO, y es un cambio de contenido: el artefacto pasa de 122 a 16
ficheros. No es accidente sino acoplamiento de upstream — `configure.ac:981`
salta `AC_CHECK_LIB(dl, dlopen)` cuando `opt_static_link=yes`, y sin
`HAVE_DLOPEN` no se construyen ni instalan los ~40 cargables de `usr/lib/bash/`,
sus 62 headers ni `usr/lib/pkgconfig/bash.pc`. Es correcto: un binario estatico
no puede dlopen, e instalarlos seria publicar una capacidad inexistente. Y no se
pierde nada que funcionara: dinamico no eran «cargables que funcionan», era «un
bash que no arranca». `yupana radio bash` da 0 dependientes.
Control: NEEDED=0, arranca, dice 5.3.0(1)-release (x86_64-pc-linux-musl) y pasa
arrays, asociativos, aritmetica, sustitucion de comandos y `=~`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
`e2fsck/Makefile.in:119` enlaza con `$(RDYNAMIC)` y es el UNICO de las 31
herramientas que lo hace (`configure.ac:109` lo pone en `-rdynamic`; ningun otro
Makefile.in del arbol lo menciona). El wrapper de cc del lab
(`sandbox.rs:597`) tira el `-static` inyectado ante `-rdynamic`, asi que e2fsck
—y sus tres alias fsck.ext{2,3,4}— salian dinamicos mientras las otras 27
herramientas del mismo build salian estaticas. Eso explica exactamente el
«4 de 31» que reporto el audit estricto.
Upstream pide `-rdynamic` para simbolizar el backtrace del manejador de senales
fatales, no para enlazar. Con estatico el backtrace pierde nombres, que es lo
que `link = "static"` ya pedia.
`RDYNAMIC=` va en compile Y en install (install relinkea).
Control: NEEDED=0 en los cuatro, los 149 ficheros del artefacto intactos, y
prueba funcional real — mke2fs crea un ext4 de 16M y e2fsck lo recorre las cinco
pasadas limpio.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
La receta decia `link = "static"` y el audit marcaba `pahole`. Mirando el
artefacto entero no era uno: eran los DIEZ ejecutables, contra cinco librerias.
El `-static` NUNCA faltaba. `build/CMakeFiles/pahole.dir/link.txt` —donde cmake
deja la linea de enlace literal— lo tenia puesto en la posicion 9, y mas
adelante en la misma linea habia un `.so` de ruta absoluta; el wrapper de cc del
lab (`sandbox.rs:597`) quita el `-static` ante cualquier `.so` en la linea, asi
que lo ponia cmake y lo sacaba el wrapper. Ese fichero es el sitio donde mirar
la proxima vez que `link = "static"` no pegue en un proyecto cmake.
Eran TRES `find_*` metiendo `.so`, no uno, y cayeron de a uno:
· FindDWARF.cmake → libelf.so ⇒ -DDWARF_LIBRARY/-DELF_LIBRARY a los .a
· find_package(ZLIB) (CMakeLists:52) → /usr/lib/libz.so ⇒ -DZLIB_LIBRARY
Sin `-static`, ademas, `-llzma`/`-lbz2` resolvian a las .so DEL ROOTFS de
Alpine y no a los artefactos de xz/bzip2 (que solo traen .a): entradas no
declaradas, de las que rompen el cono de affected.py.
`-DCMAKE_FIND_LIBRARY_SUFFIXES=.a` NO sirve y se probo: Platform/Linux.cmake lo
asigna como variable NORMAL en `project()` y esa tapa a la del cache.
Control, ademas de NEEDED=0 en los diez y la lista de ficheros intacta: el
pahole nuevo ARRANCA en el host (el viejo moria con `Error relocating
/lib/libelf.so.1: rawmemchr: symbol not found`), dice v1.30 y emite una seccion
.BTF real con `-J`, que es lo que hace CONFIG_DEBUG_INFO_BTF. Con eso el punto 3
de la deuda de SDD 25 H7 queda pagado y la herramienta probada de punta a punta.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
El `-lwayland-client` que salia de pkg-config resolvia a libwayland-client.so.0
y `link = "static"` era mentira (audit 2026-08-31). `--prefer-static` hace que
meson pida `pkg-config --static` y prefiera los .a; el artefacto de wayland
trae libwayland-client.a, asi que hay con que.
De paso saca el .so de la linea de enlace, que es lo que hacia que el wrapper
del lab tirara el `-static` inyectado (`sandbox.rs:597`) — misma raiz que htop.
Control: NEEDED=0 en todos los ejecutables ELF, lista de ficheros intacta.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
QUINTA causa del frente link=static, y la unica que no es culpa de la receta:
`Makefile.am:243` hace `AM_LDFLAGS += -rdynamic` bajo `if HTOP_LINUX`, y el
wrapper de cc del lab (`sandbox.rs:597`) quita el `-static` inyectado ante
`-rdynamic`/`--export-dynamic`/un `.so` en la linea. La regla del wrapper es
correcta —`-static` no se sostiene contra un link intrinsecamente dinamico—,
pero el `-rdynamic` de htop es solo para simbolizar el backtrace del manejador
de fallos, no una necesidad de enlace.
Efecto que tenia: `-lncursesw` resolvia a la libncursesw.so.6 DEL ROOTFS de
Alpine en vez del artefacto de ncurses (que solo trae .a) — una entrada no
declarada, de las que rompen el cono de affected.py.
`AM_LDFLAGS=-static` va en compile Y en install: si `make install` relinkea sin
el override devuelve el binario dinamico (la leccion de parted).
Seguro: el UNICO dlopen del arbol esta en linux/LibSensors.c y la receta ya
pasa --disable-sensors; delayacct queda en `no` por no estar libnl en [deps].
Control: NEEDED=0 en todos los ejecutables ELF, y la lista de ficheros del
artefacto no perdio nada contra el sellado anterior.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
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>
