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
Arreglando las tres hojas salio que el guardian tenia dos agujeros, y los dos
devuelven un pase en falso, que es la peor direccion posible para un gate.
1. `break` en el PRIMER ELF ejecutable. e2fsprogs: el primero que encontraba era
`bin/lsattr` (estatico) ⇒ receta HONESTA, mientras `e2fsck` y los tres
`fsck.ext*` eran dinamicos. 4 de 31, invisibles.
2. `find | head -40`. bash trae 42 ejecutables y CUARENTA son los modulos
cargables `usr/lib/bash/*`, que son ELF *shared object* y no matchean
`ELF.*executable`. El cap cortaba la lista ANTES de llegar a `bin/bash` ⇒ el
audit concluia «sin ELF» y eso en el resumen se lee como que no hay nada que
objetar. El shell del perfil base, dinamico, sin que nadie lo viera.
Con dwarves el `break` habia acertado de casualidad —el primero tambien era
dinamico— y por eso reportaba 1 donde habia 10.
Ahora recorre TODOS los ejecutables, sin cap, cuenta cuantos mienten sobre
cuantos hay, y nombra un ejemplo: «gtk4 dice static, 8 de 8 ejecutables
DINAMICOS (p.ej. usr/bin/gtk4-rendernode-tool)».
Barrido completo con el metodo estricto: 684 estaticos de verdad, MIENTEN 3
(gtk4, bash, e2fsprogs), 59 sin artefacto. Con el metodo viejo, sobre el mismo
store, salia 685/1/60. La diferencia son los dos que se escapaban.
Es «no comprobar no es aprobar» aplicado al propio guardian — el mismo fallo que
`hammer kernel contract` ya habia tenido que corregir en SDD 25 §4.ter.
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
El iterador pide CAP_BPF+CAP_PERFMON, y en tawasuyu el barrido de /proc de hoy
vive en `sandokan-local`, que corre SIN privilegio (se mete en un user
namespace a proposito). El unico proceso privilegiado es `sandokan-daemon`
—lo dice su propio cortafuegos.rs—. Verificado leyendo el repo espejo, no
supuesto: W2 por esta via no es un reemplazo en el lugar, cruza la frontera.
Es un coste de diseño que el cociente de 7x no muestra.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Cae el quinto de los seis experimentos nombrados. Un `iter/task` que emite
registros binarios saca la foto de procesos cerca de 7x mas barato que el
barrido de /proc (6,9-8,0x en cuatro corridas de 33 rondas y las dos
direcciones), pero el numero que decide es otro: cuesta 1,75x el piso de
`readdir` contra 12,1x de /proc. Leer los campos deja de tener precio; lo que
se paga es enumerar.
Dos barreras comprobadas, no supuestas: el programa se ata por id de tipo BTF
del vmlinux (attach_btf_id=80137, prog_type=26) — sin DEBUG_INFO_BTF no hay a
que atarse, no hay version de esto que esquive H7 —, y hace falta
CAP_BPF+CAP_PERFMON, o sea que el consumidor es el supervisor, no la Card.
Y los dos caminos NO dicen lo mismo: 24 de 245 comm difieren, todos kworkers,
porque /proc SINTETIZA el nombre pegandole la workqueue. Un reemplazo vendido
como «la misma informacion mas rapido» tenia una diferencia de contenido, y
solo aparecio cotejando registro contra registro.
H7 deja de decir «pahole en el lab y un re-hasheo». Son cuatro cosas:
DEBUG_INFO_NONE=y en los .config sellados (BTF exige DWARF antes), el kernel
no declara la receta dwarves aunque este sellada, ese pahole es DINAMICO pese
a link="static" (INTERP + 5 NEEDED) y corre dentro del sandbox del build, y
BTF mete la version de pahole en la bit-repro con el lab fuera de hash_inputs.
Ya hay dos consumidores nombrados, no cero: este iterador y sched-ext.
Lo que sigue SIN medir es el precio en bytes del bzImage, que es como se pago
H1 — se mide construyendo, y esa es la primera tarea el dia que se decida.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
`Restart=always` + `RestartSec=30` sin límite: si una receta no entra en la RAM de la
caja, el OOM killer la mata, systemd relanza a los 30 s, el loop recorre la cola por glob
alfabético y vuelve a la MISMA receta. En el LXC dev.gioser.net eso duró 30 horas con
`clang18`, y dejó la máquina con presión de I/O `full avg300=43` —todo bloqueado en disco
casi la mitad del tiempo— y sshd incapaz de completar el banner. Diagnosticarla desde
fuera era imposible: parecía red o disco. El único rastro eran dos `oom-kill` en el
journal, que sólo se ven desde dentro.
StartLimitBurst=3 / StartLimitIntervalSec=3600: a los 3 arranques en una hora systemd se
rinde y deja la unidad en `failed`, VISIBLE en `systemctl status`. OOMPolicy=stop: un OOM
no es un fallo transitorio, si no entra ahora no entra en 30 segundos.
Rendirse no pierde nada: el hub ya tolera workers ausentes —cosecha-cron dice "siembra
falló" y sigue con el siguiente— y un worker parado y diagnosticable vale más que uno que
se reinicia para siempre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Las 24 en deuda selladas, más clang18. base 52/52, cli 75/75, mirada 33/33, KDE 163/163,
sway 129/129, GNOME 119/119, COSMIC 90/90. Cero artefactos vacíos en 2103.
Las dos últimas (`cosmic-settings`, `cosmic-applets`) no cedieron al paralelismo: habían
caído con 3, 2 y 1 core. Lo que las destrabó fue MEMORIA, y la vía compatible con T9 es
zram, no swap en disco: se midió que el zram comprime a 4x real (1,9 G de páginas en
478 MB de RAM) y que los 4 GiB de `swap-zram` son sólo su default, sin justificación.
Se añadió un SEGUNDO dispositivo zram en vez de redimensionar el primero: redimensionar
exige `swapoff`, y con 1,94 G dentro y 994 MB de RAM libre eso es el escenario exacto que
volteó la máquina el 2026-08-17 —el propio script lo advierte y tiene freno—. Verificado
`backing_dev=none` en el dispositivo nuevo, que es el único agujero de zram contra T9.
`cosmic-settings` selló después con 3 cores, la misma config con la que había fallado ⇒
el paralelismo nunca fue la causa, sólo esquivaba el síntoma.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
`targets.toml` declaraba gnome-session, gnome-settings-daemon y gdm como raíces del
perfil, mientras el encabezado de las tres recetas dice "APARCADA por diseño" desde el
2026-08-07, verificado contra el meson.build de cada tag: las tres mueren en GTK3, que es
una de las tres deudas que el frente GNOME aparcó a propósito (GTK3 / X11 / PAM).
Dos documentos del repo decían cosas opuestas, y el que se mira primero es el grafo. El
resultado era deuda FANTASMA: escritorio-gnome reportaba 124/127 con 3 en `never` para
siempre, se leía como trabajo pendiente, y el worker las reintentaba en cada ciclo. En
esta misma sesión me hizo afirmar dos veces que GNOME estaba "a 3 recetas de cerrar".
No bloquean el escritorio: gnome-shell no depende de gnome-session ni de g-s-d, ni en
build ni para arrancar. El camino vivo es mutter → gnome-shell, lanzado por arje; el
único que pedía gnome-session era gdm.
Las recetas SIGUEN en el repo con su análisis intacto. Si algún día se autora GTK3, se
vuelven a añadir a `paquetes` y el objetivo reaparece solo.
escritorio-gnome: 119/119, CIERRA.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
Sergio