Era el ultimo hueco medible de SDD 25 en esta maquina: H7 tenia el precio en cuatro partes
pero no el numero en bytes, que es como se pago H1.
Se construyo una copia derivada de linux-generic con UNA sola diferencia en el .config
(DEBUG_INFO_DWARF5 + DEBUG_INFO_BTF) y todo lo demas byte a byte igual:
bzImage sin BTF : 16 937 984 B
bzImage con BTF : 19 473 408 B (+2 535 424 B = +2,42 MiB = +14,97%)
seccion .BTF : 7 888 166 B sin comprimir, entran comprimidos 3,11x
Contra la unica vara comparable: H1 (MEMCG+PSI) costo +80 KiB / +0,49% del mismo bzImage
=> BTF cuesta 31 veces eso. No lo decide, pero lo saca de "un re-hasheo y ya".
Sobre linux-generic y no sobre linux, que es mas barato: BTF tiene depends on BPF_SYSCALL y
el .config sellado de linux lo trae APAGADO, asi que medir ahi habria mezclado dos precios.
TRES cosas que salieron construyendo y no leyendo:
1. Una QUINTA parte del precio que nadie habia nombrado: hace falta python3. BTF hace que
kbuild descienda a tools/bpf/resolve_btfids, que compila un libbpf vendorizado cuyo
Makefile genera bpf_helper_defs.h con un script de Python (Error 127).
2. El numero de Artix fallaba en la direccion CONTRARIA a la esperable. El doc decia que sus
6,4 MB "no dicen nada de uno monolitico y pelado"; el nuestro sale MAS GRANDE, 7,5 MiB.
Artix es modular y su .BTF cubre solo el core built-in; el nuestro es monolitico y los
tipos de i915+nouveau+radeon+iwlwifi entran todos.
3. Una trampa de kconfig que es CLAUDE.md §3 dentro de make: scripts/pahole-version.sh
imprime 0 si pahole no esta en el PATH, el depends on PAHOLE_VERSION >= 122 deja de
cumplirse, y olddefconfig BORRA la linea en silencio. El build sale OK y sella un kernel
SIN BTF diciendo que todo fue bien. Por eso la receta comprueba el .config PRODUCIDO y
sale 1 si no esta. Salio OK, lo que ademas paga la parte (3) del precio: el pahole
estatico de ayer se encuentra y se ejecuta DENTRO del sandbox.
El artefacto de medicion se borro a proposito: `hammer kernel contract --sealed` lo listaba
como SIN COMPROBAR (no declara [[target]], que es lo que exige H8), o sea un aviso permanente
en un fichero que el cron commitea cada 30 min. Un aviso fijo que no corresponde a ningun
problema es como se deja de leer un vigia. La receta derivada queda en la evidencia.
Nada del corpus se re-hasheo: la derivada vive fuera de recipes/ y el catalogo se le presta
por symlinks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
El volumen del store estaba al 97% (8,8 G libres) con la granja escribiendo ahi, y el gordo
NO era el store: eran 79 G de `work/sources` — 106 arboles con el `target/` de cargo y los
`.o` dentro, porque el arbol de fuentes es tambien el directorio de compilacion. `pixi` pesaba
3,5 G y siete apps cosmic pasaban de 3 G cada una.
Nadie podaba eso: store-gc mira el store, la poda de CI mira la cache de CI, y este tercer
monton crecia sin dueno desde que el store se mudo al volumen.
Borrarlo no cuesta nada, y eso es lo que lo hace seguro: los dos caminos de fetch.rs
(fetch_git:73 y fetch_tarball:234) hacen `remove_dir_all` del arbol y lo re-extraen en CADA
build, sin una sola rama que reutilice. Un arbol viejo no acelera nada; la re-extraccion ocurre
igual. Lo unico que se pierde es el post-mortem del ultimo build, de ahi el suelo de 24 h.
El script toma `work/.farm-build.lock` porque el unico dano posible es borrar el arbol que un
bwrap esta compilando (ADR 0012 en su forma mas directa), y el mtime del directorio raiz no
distingue "viejo" de "build lento". Con espera acotada: si hay algo en vuelo salta el ciclo.
Suelo en HORAS y no en dias por la leccion de cache-ci-no-envejece: aquel cron podaba a +10
dias sobre datos de horas y liberaba cero. Los 106 arboles abarcaban 3 dias.
Sin umbral por espacio libre: podar solo cerca del borde convierte una poda barata y plana en
un pico justo cuando un build puede quedarse sin disco a mitad.
Probado en las cuatro ramas: dry-run vacio, dry-run con 15 candidatos, --aplicar sobre un arbol
sintetico (borra el viejo, deja los 15 recientes) y lock tomado (salta y sale 0).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Tercer cable de la misma familia que el vigia de fuentes y el contrato del
kernel, y por la misma razon exacta: el gate existia desde julio, nadie lo
re-corria, y hoy el «MIENTEN: 0» con el que se habia cerrado el frente resulto
ser 4 — todas selladas DESPUES del cierre. Un frente que se cierra en cero y no
se vuelve a medir no se queda en cero.
Lo que costaba ese silencio, medido hoy: `bash` —el shell de los perfiles base,
cli y dos escritorios— NO ARRANCABA fuera del sandbox, y las cuatro apps GTK4
del corpus (hammer-edit incluida) segfalteaban en gtk_init. Todo sellado y en
verde.
PUERTA DIARIA por sello (`work/.static-audit.sello`, gitignoreado): el barrido
lee cada ejecutable de los ~750 sellados con file+readelf y tarda ~8 min de CPU
en 4 vCPU compartidos con el worker. Cada 30 min seria mas de un cuarto de core
para siempre vigilando algo que solo cambia al re-sellar. Con la puerta, 8 min
al dia. Forzar: `rm work/.static-audit.sello`.
El sello es LIMITADOR DE RITMO, no marca de exito ⇒ se toca en cuanto el barrido
termina, salga como salga. Si solo se tocara al acertar, un fallo que consuma
los 8 min se repetiria cada 30 y el cable pasaria de vigilancia a sangria.
No toma work/.farm-build.lock a proposito (solo LEE el store; retenerlo 8 min
pararia la granja) y va con `nice -n 19`: la prioridad la tiene construir.
El veredicto lleva FECHA DE MEDICION en la primera linea, y no es decoracion:
con el frente en verde el texto del audit es constante, `git diff --cached
--quiet` no veria cambio, no se commitearia nada, y en tres meses el fichero
seria indistinguible de uno rancio. Con la fecha, cada barrido deja huella en el
git log: se ve que el vigia sigue VIVO, no solo que el ultimo veredicto fue
bueno. Misma trampa que el build-state-wlr congelado 17 dias.
Comprobado en las dos direcciones, que es donde estos cables fallan callados:
la puerta abre sin sello / a las 25 h / a los 3 dias y cierra a las 0 h y 23 h;
y con un audit que sale !=0 sin imprimir nada, NO pisa el veredicto anterior,
toca el sello igual y no deja temporales. Ya corrio en el cron real: la cosecha
de 17:01Z commiteo docs/state/static-audit.txt y logueo «sello de hoy, no toca».
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
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
Sergio