cosmic-bg dinámico (b3:b2cfc410) se conecta a cosmic-comp, entrega su buffer y el
compositor lo presenta: fondo completo en el color EXACTO que se le configuró,
(0.13,0.29,0.53) → (33,74,135), 164 colores distintos.
Que el color sea el pedido y no uno cualquiera es lo que hace de esto una
medición: descarta un buffer sin inicializar o el borrado del compositor. La
cadena cliente→compositor→KMS funciona de punta a punta.
El NEEDED del binario confirma de paso que dav1d no era un capricho del grafo:
libdav1d.so.7 y libc.so, nada más.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El default de cosmic-bg apunta a una imagen del repo cosmic-wallpapers, cuyo
tarball de GitHub pesa 20 KB: son punteros LFS, no imágenes. Una receta escrita
del modo normal produciría un paquete de ficheros de texto que además PARECERÍA
correcto — nombre bueno, ruta buena.
Mientras tanto cosmic-start escribe la config de usuario con una fuente Color,
que cosmic-bg soporta de fábrica. Va en el lanzador y no en el artefacto porque
es política de esta imagen de prueba, no algo que el paquete prometa.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pantalla completa en el gris de COSMIC (39,41,42) con el cursor dibujado, 134
colores distintos, validado CON PANTALLA (DISP=gtk + screendump).
Entra el andamiaje completo: hydrate-cosmic.sh (44 recetas, 0 faltantes),
qemu-desktop-image.sh y cosmic-start-qemu.sh.
Tres causas medidas en tres arranques, ninguna donde uno la busca:
1. cosmic-settings-daemon NO es opcional: cosmic-session lo lanza con .expect()
(main.rs:255) y panickea si falta. Corrige lo que este runbook afirmaba. De
ahi el modo bare del lanzador, que separa como compone de como arranca la
sesion.
2. La pantalla negra era libz.so.1: kms_swrast_dri.so lo NEEDea y el corpus solo
traia zlib estatica. Sin driver de software no hay GBM y el compositor arranca
igual, negro. Causa a tres capas del sintoma.
3. Los clientes no pueden ser estaticos: wayland-client entra con la feature
dlopen y un musl estatico no tiene dlopen funcional — moria 'The wayland
library could not be loaded' CON el .so presente.
Y dos carreras con /run (dbus y XDG_RUNTIME_DIR) de la misma forma que el bug de
PolicyKit1 de hoy en GNOME: comprobar al principio y usar al final. Se crea justo
antes de usar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decía «copiar es gratis de verdad, no casi». La regla honesta es: gratis SÓLO si
toda la clausura transitiva resuelve a lo mismo. Se cumple con libdisplay-info,
hwdata y nasm; no con pipewire.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El compositor compiló a la primera en 51m39s (JOBS=1 + lto fat), sin un solo
parche a la fuente; lo único que hubo que corregir fue el --bin del gotcha 1.
Lo que vale es el enlace, porque es medición y no impresión: ocho NEEDED, y las
siete primeras son EXACTAMENTE los backends de smithay que la receta declara
(display-info, gbm, seat, udev, input, pixman, xkbcommon). La octava es musl.
No hay libgcc_s —el compositor no arrastra la deuda del unwinder— y no aparece
nada sin declarar: la clausura de build y la de runtime coinciden.
Un compositor Wayland completo (DRM/GBM/EGL/libinput/seat/Vulkan/XWayland,
renderer multi-GPU y UI en iced) cerrando con ocho librerías compartidas y cero
parches es el resultado más limpio de las cuatro campañas de escritorio.
Queda anotado además por qué cosmic-settings-daemon NO se resuelve copiando
pipewire: copiar entre colas es gratis sólo si TODA la clausura transitiva
resuelve igual, y ahí glib resolvería distinto (sombra de GNOME b3:f6ccdf98 vs
corpus b3:93d2cad0) ⇒ un segundo pipewire contra otra glib, que es el cuadro de
dos registros de GType que la campaña GNOME ya midió y evitó. Medido con yupana
radio antes de tocar nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-idle se escribió sin [deps] con un argumento que parecía sólido: no usa
smithay-client-toolkit (el que hizo caer a cosmic-bg) y un demonio de inactividad
no interpreta teclas. Reventó igual, pero en el ENLACE y no en un build.rs:
-lxkbcommon lo arrastra cosmic-settings-config, de donde sale la tabla de atajos
y que usa TODO componente de la suite. La dep no viene de lo que el paquete hace
sino de la librería de configuración común.
Dos veces el mismo error de método con dos razonamientos distintos, y las dos
veces el mensaje decía exactamente quién y por qué. Queda en el runbook como
regla, no como anécdota.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-bg se escribió sin [deps] con ese argumento y reventó en el build.rs de
smithay-client-toolkit pidiendo xkbcommon.pc. El que dlopea xkbcommon es winit,
que es otra capa. Hablar el protocolo en Rust dice cómo viaja el byte, no con
qué se interpreta un teclado. El link=static sigue siendo verdad: el artefacto de
libxkbcommon trae .a además de .so.
Corolario anotado en el runbook: todo cliente de la suite va a necesitar al menos
libxkbcommon + pkgconf.
Entran además cosmic-idle (cliente Wayland puro, SIN deps a propósito: no usa
sctk y no necesita interpretar teclas) y cosmic-osd, que es el primer cliente de
iced/libcosmic y por eso vale como sonda: panel, launcher, app-library,
workspaces y notifications comparten su mismo sustrato exacto.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Deja asentado por qué COSMIC no se parece a KDE ni a GNOME (no hay torre de C
debajo: la primera receta salió estática y con cero NEEDED), la tabla de lo que
se hereda gratis de mirada/GNOME, el pin en lockstep epoch-1.5.0, y los seis
gotchas medidos — entre ellos que start-cosmic es bash de verdad (mapfile, [[ ]],
${!var}) y que bash no lo pide ningún [deps], así que a la imagen no lo trae
nadie por accidente.
Y el porqué del orden de ataque, que NO es el orden de arranque: cosmic-bg antes
del panel para que «pinta el fondo pero no el panel» separe la capa de UI del
transporte.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El plan seguía sin tilde aunque el shell arranca justamente porque están: se
verificó uno por uno con `hammer hash` contra el store en vez de fiarse del
recuerdo. Se deja el texto original del plan por la advertencia de libelogind,
que sigue vigente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
accounts-daemon y upowerd morían al arrancar: el shim de polkit se lanza en
background y tarda ~2s en adquirir org.freedesktop.PolicyKit1, ellos llamaban a
polkit_authority_get_sync() en ese hueco, D-Bus intentaba ACTIVAR el servicio y
fallaba con 'Failed to execute program ... Permission denied'.
Lo peor era el informe: los tres esperar_nombre estaban al final, así que para
cuando corrían el shim ya tenía el nombre y el resumen daba 'PolicyKit1 OK'
sobre dos clientes ya muertos. Un chequeo posterior a la carrera no la mide.
esperar_nombre pasa a definirse antes del primer daemon y el bloque de polkit
espera su propio nombre antes de que arranque ningún cliente suyo. Lanzar en
orden no es estar listo en orden.
De paso queda cerrado el ítem 4 del runbook: validación CON PANTALLA (DISP=gtk)
del Overview con el PID1 sellado nuevo — 689 colores distintos, con evidencia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sealed 765 → 768 debt 3 → 0 never 2 (los dos con bloqueo documentado)
base 50/51 → 51/51 cli 73/74 → 74/74 escritorio-mirada 29/31 → 31/31
Cierre de la deuda que yo mismo abrí al parchear libudev-zero (una hoja del cierre de las
CINCO imágenes): reconstruidas `usbutils` (b3:245c718b — depende de libudev por pkg-config),
`mirada-compositor` (b3:c906e244) y `mirada-greeter` (b3:c7dfcf09).
Ojo con la aritmética, que casi me confunde: `yupana radio libudev-zero` dice 58 dependientes
transitivos y build-state sólo veía 3 en deuda. No es contradicción — **build-state cubre el
catálogo canónico `recipes/`, no las colas `incoming-*`**, y 47 de esos 58 están en
incoming-kde. Los 8 de incoming-gnome ya se habían reconstruido ayer.
Los dos `never` NO son trabajo pendiente disfrazado; los dos tienen bloqueo real y ya escrito:
- **dwarves**: su cmake no halla libdw. La receta ya lo documentaba y el build lo confirmó
palabra por palabra («Could NOT find libdw include dir / library»): `elfutils.toml`
empaqueta sólo LIBELF —lo que kbuild necesita— y es INTOCABLE porque es build-dep de los
kernels sellados. La salida es una receta hermana `elfutils-libdw`, que en musl arrastra
shims de argp/fts/obstack. Campaña propia, no un arreglo.
- **llimphi-counter**: es una PLANTILLA, no un paquete. Su commit es `000…0`, un placeholder
que nunca se llenó. Gasté un build en descubrirlo, así que ahora la receta lo dice en la
primera línea: `⛔ ESTO ES UNA PLANTILLA, NO UN PAQUETE. NO INTENTES CONSTRUIRLA.` El estado
`never` del grafo era técnicamente cierto y semánticamente engañoso.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Audio
├─ Devices: 48. HDA Intel [alsa]
├─ Sinks: * 52. HDA Intel Analog Stereo [vol: 0.40]
├─ Sources: * 53. HDA Intel Analog Stereo [vol: 1.00]
Y gvc con perfiles reales (`output:analog-stereo+input:analog-stereo`). Se fue el auto_null.
LA CAUSA: SPA pide el device `card` (alsa-udev.c:178-183), que no tiene major:minor, y
libudev-zero recorría SÓLO /sys/dev/{block,char} — sólo devices CON nodo. El device que
SPA necesita nunca entraba en la enumeración: no faltaba una propiedad, faltaba la mitad
del espacio de búsqueda.
**Y LA PRIMERA VERSIÓN DEL PARCHE ARREGLÓ EL AUDIO Y ROMPIÓ EL VÍDEO.** Recorría
/sys/class entero, y /sys/class/drm no trae sólo tarjetas: trae los CONECTORES
(card0-Virtual-1) y un fichero `version`, ninguno con nodo. Mutter los tomaba como
candidatos ⇒ `No available CRTC for monitor` + `Page flip failed: drmModeAtomicCommit:
Invalid argument` en bucle. Pantalla negra con el compositor vivo: el mismo síntoma de
antes por una causa nueva. El udev real también los enumera, pero les adjunta las
propiedades por las que mutter los descarta, y ésas libudev-zero no las sintetiza.
La lección, que vale para cualquier reimplementación parcial de una API: **ensanchar la
enumeración expone los huecos de PROPIEDADES a más consumidores. Los dos lados del
contrato tienen que crecer juntos.** El parche final lleva una LISTA ACOTADA de
subsistemas (`sound` hoy); agregar otro es una línea *y* una prueba de que el consumidor
lo necesita y no se rompe.
POR QUÉ NO eudev — y corrijo mi propia sugerencia de antes, que era la peor opción: el
repo ya lo había probado en otro frente y ROMPIÓ EL INPUT. Su libudev.so.1 pisa el de
libudev-zero y, sin udevd, no expone ID_INPUT ⇒ libinput ignora todos los dispositivos en
silencio. Verificación A/B en QEMU de aquel episodio: eudev = 0 «New device»,
libudev-zero = 5. eudev sin udevd es PEOR, y correr udevd contradice la arquitectura
(arje-zero es PID1). El arreglo va donde está el hueco.
Radio pagado: 51 sellados a deuda, 9 en el cierre GNOME (reconstruidos: libinput,
libgudev, colord, mutter, gnome-shell, libgdm, upower, pipewire, wireplumber). El resto
—base, cli, KDE— queda para el latido.
Captura actualizada: escritorio pintando (628 colores) Y audio, cero page-flip fallidos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierra el gestor de sesión de PipeWire, que es lo que separa «PipeWire acepta clientes»
de «PipeWire tiene dispositivos». Su política está escrita en Lua, así que arrastró una
receta de Lua que hubo que autorar entera.
LO QUE LA RECETA DE LUA TIENE QUE INVENTAR: el Makefile de upstream sólo produce
liblua.a y los binarios — **no hay regla de .so ni fichero pkg-config**, los agrega cada
distro. Acá la compartida se enlaza a mano desde la .a con --whole-archive (una estática
sólo aporta lo referenciado y hay que llevarse todo) y el .pc se escribe con los TRES
nombres que se usan por ahí, porque wireplumber prueba lua-5.4, lua5.4 y lua54 en orden.
`-fPIC` no es opcional: libwplua es un objeto compartido.
Dos símbolos más en libelogind (tawasuyu 087230054 → re-pineado 749edfe41):
sd_uid_get_seats y sd_uid_get_state, que module-logind.c de wireplumber usa para saber si
el usuario está en un asiento antes de tomar los dispositivos. Van 28 símbolos sd-*.
**EL `Devices:` VACÍO DE wpctl NO ES UN FALLO DE wireplumber: el kernel no tiene ALSA.**
recipes/linux-metal.toml:111 lo apaga explícito (`-d SOUND -d SND`), así que no hay
/dev/snd que enumerar. Y esto NO se dio por supuesto: se agregó una ich9-intel-hda
emulada a QEMU (AUDIO=1, ahora el default de run-qemu-desktop.sh) justo porque un
«Devices: vacío» se lee IGUAL si wireplumber funciona sobre una VM sin hardware que si no
funciona. Con tarjeta y sin ALSA en el kernel, el resultado no cambia — la ambigüedad
queda resuelta. Encender el sonido en la distro es una decisión con costo (re-sellar el
kernel, rehacer la imagen metal) y queda a la vista en vez de escondida en un default.
Bug propio destapado en el camino: el bloque de wireplumber quedó DUPLICADO en
gnome-start y había DOS wireplumber peleándose el grafo. El síntoma no era un error sino
una lista de clientes que se lee normal si no se cuenta: dos «WirePlumber» con pids
distintos en wpctl status.
Y una nota de ADR 0012 que costó un rato: la cascada de libelogind cortó a mitad y dejó
el `output/` de mutter a medio hacer; el reintento moría con «error opening
'...c.o.d': No such file or directory». Un `rm -rf output` en el configure NO alcanzó
—el árbol tenía estado viejo más allá del build dir—; lo que lo arregló fue BORRAR
work/sources/mutter-* para que el fetch lo re-extraiga limpio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierra una pregunta que estaba explícitamente abierta en varias recetas, y que es la
razón por la que `pulseaudio` se había construido con `-Ddaemon=false`: sólo el cliente,
para que gvc hablara el protocolo sin cerrar la decisión de prestado.
**Los dos conviven y por eso la decisión no rompe nada**: pipewire va con
`-Dlibpulse=enabled` ⇒ `pipewire-pulse`, un servidor que habla el protocolo de
PulseAudio. gnome-shell usa libpulse sin enterarse de qué hay del otro lado. No hubo que
tocar una línea del cliente.
== gnome-qemu :: socket pipewire-0 OK
== gnome-qemu :: socket pulse/native OK — gvc va a poder conectar
Gvc-DEBUG: Updating client: index=32 name='pipewire'
Gvc-DEBUG: Updating sink: index=33 name='auto_null' description='Dummy Output'
El `Failed to connect context: Connection refused` desapareció. El sink es auto_null, que
es la respuesta honesta: la VM no tiene tarjeta de sonido.
**⚠ Falta wireplumber** (gestor de sesión, Lua + su cierre). Sin él PipeWire acepta
clientes pero NO enumera ni enruta dispositivos. «El shell conecta» ≠ «hay sonido», y el
log de arriba es justo el caso donde confundirlos sería fácil. Queda escrito en la receta
y en el runbook.
GOTCHA MEDIDO: ya existía incoming-kde/pipewire.toml sellada y NO se puede reusar
hidratándola acá — los dos cierres traen glib y **no son la misma glib**:
incoming-kde/glib-shared y incoming-gnome/glib producen libglib-2.0.so.0.8800.1 con bytes
distintos (verificado con cmp) y comparten 370 rutas. Proyectar las dos deja que una gane
por orden de proyección ⇒ dos registros de GType en un proceso, el cuadro que costó el
episodio de colord. De ahí la copia en la cola GNOME (glib-shared→glib, dbus→dbus-shared,
pcre2-shared→pcre2), que sí re-construye. Lo que FUE gratis: alsa-lib, cuya única dep es
pkgconf y resuelve al catálogo PADRE ⇒ hash idéntico y cache hit (b3:93cae411).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
bus: org.freedesktop.login1 OK
bus: org.freedesktop.PolicyKit1 OK
bus: org.freedesktop.Accounts OK
bus: org.freedesktop.UPower OK
accounts-daemon y upowerd arrancaban, seguían vivos, y NUNCA adquirían su nombre: los
dos se bloquean en `polkit_authority_get_sync()` al iniciar, y `org.freedesktop.PolicyKit1`
no lo servía nadie —nuestra receta polkit es libs-only a propósito, porque el demonio lo
pone arje—. gnome-shell esperaba después 25s por cada uno.
**El dato que lo resolvió no salió del log de los daemons sino de la LISTA DE NOMBRES DEL
BUS**: ahí estaban como conexiones anónimas `:1.0`, `:1.1`, sin nombre bien conocido. Eso
distingue tres cosas que en el log del cliente se ven igual — «no arrancó», «arrancó y no
llegó a pedir el nombre» y «lo pidió y se lo negaron». Era la segunda. `gnome-start` ahora
espera cada nombre con NameHasOwner y, si no aparece, vuelca el log del daemon y la lista.
Receta nueva `arje-polkit-compat` (b3:03e0a86f), tercer shim de este tipo tras
arje-logind-compat y arje-sdlogin-compat. Su propio autor ya había escrito el diagnóstico
en el crate: «apps que usan polkit bloquean en CheckAuthorization si no responde nadie».
⚠ AUTORIZA TODO — es la postura de sistema confiado que arje ya tenía tomada, no algo que
esta receta introduzca; queda explícito en su comentario.
Dos gotchas del empaquetado:
- **La política de polkit ya existe y NO alcanza**: permite `own` sólo al usuario polkitd
y el shim corre como root. Se agrega un `zz-arje-polkit-compat.conf` en vez de reescribir
la de upstream — dbus lee system.d en orden alfabético y las posteriores ganan.
- **Los ficheros del rootfs fundido son hardlinks de SÓLO LECTURA del store** (0444). Un
`cat >` encima falla con Permission denied y rompió un build. Regla: nunca sobrescribir
un fichero que venga de un artefacto; agregar al lado.
Queda escrito en el runbook lo que sigue faltando (colord, y que el shell no tiene servidor
de sonido porque pulseaudio se construyó sólo-cliente: el demonio de audio de la distro
sigue sin decidirse) y las dos lecciones de método que costaron una iteración cada una.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Captura actualizada: ahora se ve el puntero (Adwaita) y el icono de la notificación.
Colores distintos 582 → 629.
El setuid del dbus-daemon-launch-helper explicaba DOS cosas, no una: el «permission of
the setuid helper is not correct» de colord y, por la misma vía, que ninguna activación
por bus de sistema funcionara. Con el arreglo, colord pasó de «permiso incorrecto» a
«timed out» — la activación ya se intenta y lo que queda es del demonio.
Queda UPower: upowerd arranca y sigue vivo, pero no adquiere su nombre en el bus (su
política D-Bus está verificada y permite own a root), así que el shell espera sus 25s.
Es el indicador de batería en una VM sin batería.
Y queda escrita la lección que costó una iteración: **un pid no es un servicio**.
Reportar «lanzado» sin comprobar que el daemon adquirió su nombre es reportar una
intención, no un hecho.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
docs/evidencia/gnome-shell-qemu-2026-07-29.png: el conmutador de espacios de trabajo,
el reloj en el panel, la miniatura del escritorio, el dash, y la notificación estándar
de GNOME por sesión de root. Todo construido desde fuente sobre el kernel de hammer,
arje-zero como PID1 y musl.
**EL MURO NO ERA DE KMS.** El diagnóstico anterior culpaba al plano primario de
virtio-gpu («no advertised formats», sólo `Queue mode set`, ningún page flip). Era
correlación. Se probó quitando MUTTER_DEBUG_FORCE_KMS_MODE=simple —el log pasó a decir
`using atomic mode setting`, o sea que el cambio SÍ tomó efecto— y la pantalla siguió
con exactamente 2 colores. Refutada. Mutter no tenía un frame que presentar; no es que
no supiera presentarlo.
La causa estaba en el stack trace, en el log, desde el principio: la excepción por el
gschema `org.gnome.settings-daemon.peripherals.touchscreen` ocurre DENTRO de
`Main.start()`, construyendo los quick settings ⇒ el panel nunca se arma. Proceso vivo,
compositor con DRM master, nada que pintar.
Receta `gsd-schemas`: los gschemas de gnome-settings-daemon SIN g-s-d, que sigue
aparcada por GTK3/X11. **Tercera vez que aparece la misma lección** (tras la política
D-Bus de login1 y el `org.gnome.login-screen` de libgdm): un gschema no es un fichero de
datos del demonio, es una interfaz publicada que consume otro programa.
Dos trampas de diagnóstico, las dos ahora blindadas:
- **`glib-compile-schemas` sale con 0 aunque RECHACE un esquema.** Instalé los once XML,
el log dijo `esquemas OK` y el shell seguía diciendo `not found`: faltaba
`org.gnome.settings-daemon.enums.xml`, que meson genera con glib-mkenums y no es uno
de los `.in`. Sin los `<enum>`, glib descarta el esquema entero, avisa por stderr y
sigue. `gnome-start` ahora vuelca ese stderr SIEMPRE, no sólo al fallar.
- El log serial persiste entre arranques y me hizo leer dos veces un `STATUS +30s` de una
VM ya muerta. Truncarlo antes de arrancar; `Failed to get "write" lock` avisa de que
hay otro QEMU con el disco tomado.
Y queda escrito cómo validar CON PANTALLA sin humano delante: screendump por el monitor
de QEMU, con una métrica barata previa a mirar — contar colores distintos. Negro = 2;
pintando = 582, con el azul GNOME (2,60,136) al frente.
Lo que falta son detalles, ninguno impide el escritorio: lanzar upowerd desde gnome-start,
un tema de cursor, el setuid de colord y gnome-control-center.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Estado: gnome-shell corre 5 minutos sobre DRM real sin una sola JS ERROR, y la
captura del framebuffer muestra la consola del kernel en negro. Mutter nunca
presentó un frame.
La pista del log de KMS es concreta: el plano primario 33 de virtio-gpu 'has no
advertised formats' y sólo hay 'Queue mode set' — ningún page flip. Tres hipótesis
de una variable cada una, la primera es quitar MUTTER_DEBUG_FORCE_KMS_MODE=simple,
que se heredó de la campaña KDE (donde el que fallaba con atomic era kwin).
Queda además escrito CÓMO validar con pantalla sin humano delante: screendump por
el monitor de QEMU + PPM→PNG. Aplicar esa regla es lo que destapó este muro — el
serial decía 'sesión viva'.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Venía cerrando typelibs de a uno: AccountsService → DBus-1.0 → cairo-1.0 → Gdm-1.0,
un rebuild de imagen y un arranque completo por cada uno. Cuatro rondas para
descubrir que la lista estaba escrita todo el tiempo.
`js/misc/dependencies.js` de gnome-shell ENUMERA lo que el shell exige al arrancar.
Cruzada contra el rootfs hidratado, la frontera completa es exacta:
GnomeDesktop-4.0 + GnomeBG-4.0 → gnome-desktop (YA sellada, pero -Dintrospection=false
y estática ⇒ falta la variante de isla dinámica)
Geoclue-2.0 → geoclue (sin receta)
GWeather-4.0 → libgweather (sin receta)
IBus-1.0 → ibus (sin receta)
Rsvg-2.0 → librsvg (sin receta; es Rust)
UPowerGlib-1.0 → upower (sin receta)
Los otros veinte de la lista ya están. GnomeBluetooth, NM/NMA4 y Malcontent son
condicionales y no bloquean.
REGLA, y es el precio de no haberla aplicado antes: cuando el muro es `Requiring X`,
no cierres X y vuelvas a arrancar — leé el fichero donde el programa DECLARA sus deps
de runtime y cerralas todas de una.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5