gdm, gnome-session y gnome-settings-daemon salen de la cola y quedan aparcadas
en `recipes/incoming-gnome/.deferred/`, que es el mecanismo que el repo ya usa
(precedente: incoming-kde/.deferred/libXft.toml). El glob del worker es
TOP-LEVEL y el del grafo también, así que dejan de molerse cada ciclo y dejan de
contarse como deuda que nadie va a pagar. `targets.toml` ya no las lista desde
el 2026-08-07 («APARCADAS POR DISEÑO»); esto alinea el árbol con esa decisión.
Y el mapa que llevaban estaba mal en las dos direcciones:
1. «La terna GTK3» es un nombre engañoso: **GTK3 no es el muro**. GTK3 tiene
backend Wayland y se construye con -Dx11_backend=false. Autorarlo no habría
destrabado ninguna de las tres. Lo que bloquea de verdad:
- g-s-d 48.1: gtk+-x11-3.0 / x11 / xfixes INCONDICIONALES => imposible en
Wayland-only, no «pendiente».
- gnome-session 48.0: dependency('libsystemd', required: true) en meson:124
es una comprobación de pkg-config EN BUILD. arje-logind-compat no la
satisface y es a propósito — su receta explica que GNOME consulta login1
en RUNTIME por D-Bus y que no hace falta la C-ABI sd-login. Único camino:
parchear ese required a false, que es una decisión, no un arreglo.
- gdm: cuelga de gnome-session, y con mirada-greeter probablemente sobra.
2. La lista «FRONTERA» estaba VIEJA: ya existen libX11, libXfixes, xorgproto,
libXau/Xcursor/Xdmcp/Xext/Xi/Xrender/Xtst, libxcb (casi todas por KDE) y
polkit, upower, geocode-glib, libgweather. Cuatro de las ocho líneas de g-s-d
habían dejado de ser ciertas. Faltan de verdad: gtk3, libnotify y una
variante libcanberra-gtk3.
Verificado contra el TARBALL (sha256 = el del pin), no contra el comentario.
incoming-gnome queda en 79 recetas, sellado=79 deuda=0 nunca=0.
Gate --check OK, grafo CIERRA, escritorio-gnome sigue 119/119.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
`fontconfig-shared`, `freetype-shared`, `libjpeg-turbo-shared`, `libpng-shared`,
`libtiff-shared`, `libxml2-shared`, `libyaml-shared` y `zlib-shared` existían a
la vez en `incoming-gnome/` y en `recipes/`, y las ocho daban el MISMO
ArtifactHash que su gemela del corpus. Como la resolución de deps cae al padre
cuando no hay hermano, quitarlas deja a las consumidoras resolviendo contra
`recipes/` y con el mismo hash.
Medido, no supuesto: se hashearon las 1144 recetas antes y las 1136 después, y
de las 1136 supervivientes **0 cambiaron de hash**. No hay rebuild.
Lo que NO se toca, y conviene que quede dicho porque se parece:
- Las variantes de la ISLA DINÁMICA (glib, gtk4, gdk-pixbuf, pango, harfbuzz,
graphene, libadwaita, json-glib, libusb, libxcvt, pipewire, pulseaudio,
wireplumber, xdg-desktop-portal): mismo nombre, hash DISTINTO. Son sombras a
propósito — la introspección de GNOME exige .so reales.
- Las copias entre COLAS (alsa-lib, hwdata, xkeyboard-config, libdisplay-info,
lcms2, icu4c, lua, nasm, fuse3, libsndfile, libelogind, hicolor-icon-theme,
dbus-shared): también dan el mismo hash, pero NO sobran. Cada cola necesita su
propio hermano para cerrar su clausura; borrar la de una rompe esa cola. No es
el caso de onda-2, donde la cola entera duplicaba a otra.
Y el criterio, otra vez: `pipewire` y `pulseaudio` son TEXTUALMENTE idénticas a
las de COSMIC y sellan distinto, porque sus deps resuelven distinto según la
cola. El fichero no dice la verdad; el hash sí.
Gate --check OK, grafo CIERRA, escritorio-gnome sigue 119/119. La cola queda en
82 recetas (79 selladas + la terna GTK3) y sus 5 parches, todos en uso.
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
Ningun nodo cambia de estado y el gate `--check` sigue OK: lo unico que se
mueve es `dependientes_total` de sus deps, un dependiente menos cada una. Es
la yupana cruzando TODAS las colas, onda-1 incluida, aunque ningun grafo la
cargue como cola propia.
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
