Cierra el segfault mudo de iris. El intento anterior (`-Wl,--build-id=sha1`) NO prendió:
meson lo registra pero `zig cc` 0.13 lo ignora en silencio — el configure lo dice
(«supports link arguments -Wl,--build-id=sha1: NO») y la .so sale sin ninguna nota.
zig 0.16 sí la emite (verificado a mano), pero `zig_version` está pineada a 0.13.0 como
escotilla contra la regresión de zig 0.14: subirlo cambia un muro por otro.
Tampoco había escape por entorno, y esta vez medido sobre el fuente en vez de deducido:
el retorno temprano es `if (INTEL_DEBUG(DEBUG_DISK_CACHE_DISABLE_MASK))` y en 24.0.9 esa
máscara está definida como 0 ⇒ el `if` no dispara nunca. Por eso el desensamblado no
tenía ni un salto condicional: el compilador lo dobló.
`-Dshader-cache=disabled` lo garantiza el preprocesador — el cuerpo entero de
`iris_disk_cache_init` vive en un `#ifdef ENABLE_SHADER_CACHE`. Verificado en el
artefacto: la función es ahora un único `ret`.
MEDIDO EN METAL (OptiPlex 3060 / UHD 630), bibliotecas desplegadas por SSH sobre la
máquina viva, sin re-quemar el USB: sesión COSMIC completa arriba — cosmic-comp, panel
con applets, bg, launcher, term, toplevel, workspaces — y CERO segfaults nuevos.
Confirmado en pantalla por el usuario.
Costo aceptado: sin caché en disco los shaders se recompilan en cada arranque.
Re-sella mesa: b3:6d443d9f… → b3:f43c41d1…
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Causa raíz del escritorio COSMIC que no arrancaba en metal, medida en el OptiPlex 3060
(UHD 630). cosmic-comp moría sin panic y con RUST_BACKTRACE=full; el dmesg tenía la
respuesta que ningún log de usuario podía dar:
cosmic-comp[1266]: segfault at 10 ip ... error 4 in iris_dri.so[9626c0,...]
El offset resuelve a `_mesa_sha1_format` (bytes del desensamblado idénticos al `Code:`
del kernel), y su llamador `iris_disk_cache_init` es tres llamadas seguidas sin un solo
salto condicional entre medio:
build_id_find_nhdr_for_addr → NULL (ninguna .so de mesa traía nota)
build_id_data → NULL+0x10 (offsetof del campo)
_mesa_sha1_format → lee 0x10 ⇒ SIGSEGV
El `assert(note && ...)` que cazaba esto lo borra -Db_ndebug=true.
Tres decisiones razonables por separado que juntas dan un cuelgue mudo: meson no pide
build-id, lld no lo pone solo (37 de 40 .so del corpus SÍ lo traen — era exclusivo de
mesa) y el assert no existe en release. No lo salva MESA_SHADER_CACHE_DISABLE: la
desreferencia va antes de consultar si la caché está habilitada. Y no se ve en QEMU,
donde el userland es swrast/llvmpipe y esta ruta es de iris.
Fix: -Dc_link_args/-Dcpp_link_args con -Wl,--build-id=sha1.
Re-sella mesa: b3:6d443d9f… → b3:c3c18cde…
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
WIFI. El OptiPlex 3060 SÍ tiene WiFi: `pci 0000:02:00.0: [168c:0042]` = Qualcomm
Atheros QCA9377. No aparecía interfaz porque el kernel sólo llevaba IWLWIFI. Añadido
ATH10K/ATH10K_PCI a linux-metal-dual + el firmware QCA9377 a la imagen + `wifi-up`.
El detalle que hace falta: con MODULES desactivado el driver va BUILTIN y prueba el
dispositivo a los ~5s pidiendo firmware, pero el rootfs se monta a los ~13s ⇒
`Direct firmware load failed -2` y la tarjeta queda muda, sin módulo que cargar
después. `wifi-up` fuerza un re-probe PCI (remove+rescan) con /lib/firmware ya
montado. Es la MISMA carrera que la del initramfs con el USB, un piso más abajo.
COSMIC-DIAG. La 1ª versión esperaba `sleep 50` y en esa máquina la sesión tarda ~105s
en llegar al compositor ⇒ el dmesg «después» se capturó ANTES de que cosmic-comp
arrancara y salió byte a byte idéntico al de antes. El viaje se gastó sin dato, y yo
leí ese dmesg vacío como «no hubo segfault», que era una conclusión sin respaldo.
Ahora espera al HECHO: que cosmic-comp aparezca y luego desaparezca (techo de 6 min).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
b3:b8f3baf0, selló a la primera. Arranca desde cosmic-start ("wireplumber OK (pid
192) — hay gestor de sesión"), se conecta al grafo (dos clientes en wpctl status) y
wpctl pasa a mostrar una sección Video que antes no existía.
Y el Start de ScreenCast SIGUE sin Response a los 60s. Mismo resultado exacto.
LA HIPÓTESIS QUEDA MATADA POR MEDICIÓN. "Falta el gestor de sesión que mueva el nodo
de Paused a Streaming" era mía y era razonable; no era cierta. Queda escrita junto a
su refutación porque una hipótesis descartada CON EVIDENCIA vale más que una lista de
sospechosos: acota el próximo paso a lo que queda, que es el backend mismo.
El dato nuevo, que es por dónde seguir: con wireplumber corriendo, `wpctl status`
lista `Video → Streams` VACÍO durante el handshake. O sea que el nodo
`cosmic-screencast` que SÍ existe en `pw-cli ls Node` no llega a wireplumber como
stream gestionado. Próximo movimiento: RUST_LOG=trace sobre screencast_thread, no
otra dep.
── por qué receta propia y no la de GNOME ──────────────────────────────────────
La de incoming-gnome funciona pero NEEDea libglib/libgobject/libpipewire de la ISLA
DINÁMICA de GNOME: traerla metería una segunda glib y una segunda pipewire en la
imagen. De 19 deps, 14 dan hash idéntico; las que divergen divergen a propósito —
sobre todo `pipewire`, que acá apunta a la de COSMIC (338d1d8c), la que el escritorio
realmente ARRANCA. Un gestor de sesión contra otra pipewire que la que corre no
gestiona nada.
El cambio de fondo es glib → glib-shared. COSMIC usa la glib ESTÁTICA del corpus, que
le alcanza al portal porque es un ejecutable. Acá no: wireplumber produce un .so y 17
módulos, y libglib-2.0.a tiene 44.275 reubicaciones R_X86_64_32/32S ⇒ no es PIC. La
regla del frente GNOME (readelf -r ANTES de gastar el build) ahorró uno.
Y la salida no fue una campaña nueva sino una MEDICIÓN: incoming-kde/glib-shared
copiada a esta cola resuelve al MISMO hash (0584ce1f) y ya estaba sellada ⇒ cero
rebuild. Idem pcre2-shared, lua y libelogind. Las dos glib coexisten sin pisarse (.a
y .so son ficheros distintos) y el portal conserva sus 3 NEEDED.
escritorio-cosmic: 84 → 89 recetas, 0 faltantes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La receta de la sonda (b3:af49d32d) y lo que midió. Es la única receta de la campaña
cuyo producto no es una pieza del escritorio sino un instrumento para medirlo: entra
a la imagen porque un handshake de portal sólo se puede ejercer DESDE la sesión, con
bus y compositor vivos, y sale ESTÁTICA (0 NEEDED) porque un instrumento no debe
depender de aquello que mide.
[1/4] CreateSession → Response 0, session_handle ✓
[2/4] SelectSources → Response 0 ✓
[3/4] Start → el backend ABRE "Share your screen", con
miniatura EN VIVO del framebuffer y el output
Virtual-1; se elige, se pulsa Share…
y NO llega Response en 60s ✗
El log del backend da la línea exacta:
screencast_thread: state-changed 'Connecting' -> 'Paused'
Y `pw-cli ls Node` durante la espera da el veredicto INDEPENDIENTE:
node.name = "cosmic-screencast" media.class = "Video/Source"
EL NODO DE VIDEO EXISTE EN EL GRAFO DE PIPEWIRE. La cadena entera —cliente →
frontend → backend → compositor → demonio— funciona hasta crear y negociar el stream.
Lo único que no ocurre es el Response de vuelta tras quedar en `Paused`. Eso es un
lugar muy distinto del de esta mañana ("no hay demonio con quien negociar").
Sospecha para el próximo paso, y es HIPÓTESIS no medición: falta `wireplumber`. Sin
gestor de sesión nadie mueve el nodo de Paused a Streaming y el backend parece
esperarlo. Construirlo la confirma o la mata.
Gotchas que costaron corridas y quedan escritos:
· matar el backend se lleva puesto al frontend (ambos pierden dueño del bus);
· el lanzador busca por NOMBRE VISIBLE: `cosmic-term` no matchea, `Terminal` sí —
escribir el nombre del binario abre otra app;
· `| head -N` bufferiza y deja la terminal en blanco: parece colgada y está esperando;
· pkg-config OMITE los -L de dirs "estándar" y zig cc cross NO los busca ⇒
`-ldbus-1` pelado da "unable to find static system library", que suena a librería
faltante cuando lo que falta es la ruta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
69 min. NEEDED: libgbm, libpipewire, libxkbcommon, libc. Instala el binario
en /usr/libexec, el .service de D-Bus con @libexecdir@ sustituido, el
cosmic.portal que declara las cinco interfaces
(Access/FileChooser/Screenshot/Settings/ScreenCast) y sus iconos.
clang18 se construyó en la granja y se cosechó al laptop (b3:62c6bfb5), pero
el backend NO se pudo construir allá: el worker no tiene la cola COSMIC
horneada —el snapshot golden es del 2026-07-15 y toda esta cola es
posterior— así que intentó reconstruir pipewire y murió buscando glib. Es la
regla de «rootfs laptop ≠ worker» pero con el STORE: lo que en el laptop es
cache-hit, en el worker es un build entero con sus propias deps.
Y destapó que la receta de pipewire NO lleva --wrap-mode=nodownload: ante
una dep faltante intenta bajarse un subproyecto de internet y, sin red, el
error que sale no es «te falta glib» sino «Unhandled python exception / This
is a Meson bug». Queda anotado como deuda.
--offline SIN --locked, y no es descuido: el sed del parche corre en la fase
compile, o sea DESPUÉS del cargo vendor, así que cargo ve el Cargo.toml
cambiado y con --locked se niega. Quitar una feature sólo puede ENCOGER el
conjunto de crates, así que lo que haga falta ya está vendorizado; la
hermeticidad la da --offline + el árbol vendorizado, no el --locked.
Dos raíces en el perfil y en la hidratación, porque son DOS procesos que se
encuentran por D-Bus en runtime y ningún [deps] los relaciona. Imagen en 83
recetas (eran 74).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
clang18 b3:62c6bfb5 (sólo libclang.so)
xdg-desktop-portal-cosmic b3:97dfddd8
EL PARCHE DE UNA LÍNEA resultó ser el que se esperaba: xdp-cosmic declara
cosmic-files con features = ["gvfs", "wayland"] FIJADAS a mano —mismo patrón
que deja fuera a cosmic-files-applet— así que apagarla desde afuera no
alcanza. El sed la saca y queda la misma combinación que ya compilaron
cosmic-term y cosmic-edit. Se pierden los montajes remotos DENTRO del
selector del portal, no el selector.
PERO APARECIÓ UN ESLABÓN QUE NO ESTABA EN EL PLAN: libclang.
xdp-cosmic declara pipewire y libspa-sys como deps DURAS (screencast)
→ libspa-sys/build.rs corre bindgen::builder() INCONDICIONAL
→ bindgen carga libclang.so en tiempo de build
Verificado que no hay atajo: ese build.rs no tiene rama alternativa, a
diferencia de aws-lc-sys —que sí cae a bindings pregenerados
(cargo:rustc-cfg=universal) y por eso cruzó a musl sin cmake ni perl—. Y
libclang no está ni en el corpus ni en los 182 binarios del rootfs del
constructor: llvm18 se selló con -DLLVM_ENABLE_PROJECTS="".
Lo barato es que NO se recompila LLVM: el artefacto llvm18 ya publica
usr/include/llvm, usr/include/llvm-c y usr/lib/cmake/llvm, así que clang18
es un build de clang CONTRA un LLVM sellado. Se instala sólo libclang.so y
clang-c/: el binario `clang` no es el objetivo — el compilador de esta
distro sigue siendo zig-cc, y sumar otro sería lo contrario de la deuda que
la campaña «matar gcc» viene pagando.
Patrón gcc-de-gueto (igual que llvm18 y cmake): g++ con -static-libstdc++
-static-libgcc para que la .so quede con NEEDED sólo libc.musl y no contagie
el runtime C++ de Alpine a cada build que la declare.
Vale decir de dónde sale este costo: no de COSMIC, sino de que pipewire-rs
genera sus bindings en cada build.
Ambas van a la granja (decisión del usuario): mismo peso que llvm18, que ya
se selló en el worker gordo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tres recetas nuevas y el eslabón que faltaba de verdad:
fuse3 3.18.2 b3:3a84af86
json-glib 1.10.8 b3:dc8c8e78 (variante SIN introspección)
xdg-desktop-portal b3:f4adb8c9 1.18.4
El artefacto trae /usr/share/dbus-1/services/org.freedesktop.portal.Desktop.service
—el nombre exacto que cosmic-screenshot no encontraba— más
xdg-document-portal y xdg-permission-store. NEEDED del frontend: libz,
libpipewire y libc.
CUATRO COSAS MEDIDAS QUE VALEN MÁS QUE LAS RECETAS:
1. PIN A 1.18.4 POR GSTREAMER. Desde 1.20 meson pide
dependency('gstreamer-pbutils-1.0') sin required: —para validar sonidos
de notificación— y eso arrastra gstreamer + gst-plugins-base. La 1.18.4
no lo pide: sus deps duras son glib/gio/gio-unix, json-glib, fuse3,
gdk-pixbuf y pipewire, y de ésas la única que faltaba era fuse3. Es un
pin deliberado: el día que se quiera 1.22 el precio es gstreamer.
2. fuse3: NO poner -Ddisable-libc-symbol-version=true aunque suene a lo
correcto para musl. Lo probé razonando eso y falla el enlace: la opción
sólo hace que compat.c no emita los alias versionados, pero
lib/meson.build:54 pasa --version-script INCONDICIONALMENTE, o sea que
el script queda pidiendo símbolos que ya nadie define. Es una combinación
incoherente de upstream, no una limitación de musl. La auto-detección de
upstream tampoco conoce musl: sólo apaga versionado para __UCLIBC__ y
__APPLE__. Se deja el defecto, que es con lo que Alpine construye.
3. json-glib NO se puede reusar de incoming-gnome: aquella está en la ISLA
DINÁMICA (introspection=enabled, default_library=both) porque su .gir es
entrada del .gir de evolution-data-server. Traerla metería toda la
maquinaria de introspección de GNOME en la clausura de COSMIC para no
usar un solo .typelib.
4. EL CHOQUE DE gvdb, y por qué se resolvió renombrando símbolos. El portal
vendoriza gvdb y glib TAMBIÉN lo lleva adentro (GSettings): con glib
estática el .a expone los símbolos y el enlazador ve dos definiciones.
Los otros dos caminos se descartaron POR MEDICIÓN:
· --allow-multiple-definition / -z muldefs: zig-cc NO lo acepta
(«unsupported linker arg»), y meson lo reporta como «Compiler
hammer-zig-cc cannot compile programs», que manda a buscar el
problema donde no está.
· glib-shared: no es cambiar una dep sino abrir una cadena (json-glib y
gdk-pixbuf también enlazan glib) y meter la segunda glib en la imagen.
El renombrado con -D es total —afecta definición y usos, todos pasan por
gvdb-reader.h— así que el binario queda con lector+constructor de la
misma copia. Importa: glib empaqueta sólo el LECTOR, el CONSTRUCTOR
existe únicamente en el portal.
Bonus de meson: las opciones de tipo lista se parten por COMAS, así que
-Dc_args/-Dc_link_args no sirven para banderas con comas; van por CFLAGS y
LDFLAGS. Y quitar un subdir() no es gratis: subdir comparte ámbito de
variables, y sacar subdir('tests') rompía el summary() que lee
enable_pytest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
b3:8b57ec9b, 9 minutos, NEEDED = libc.so y nada más. Un solo NEEDED, y el
único `[deps] build = []` de la campaña: 130 líneas de Rust que no dibujan
ni hablan wayland.
Se incluye en la imagen sabiendo que falla, para que el hueco sea MEDIBLE en
vez de supuesto. Error exacto capturado corriéndola desde cosmic-term dentro
de la VM:
panicked at src/main.rs:76:10: failed to send screenshot request:
Portal(ZBus(MethodError(ServiceUnknown, "The name
org.freedesktop.portal.Desktop was not provided by any .service files")))
Misma forma que la deuda de org.freedesktop.locale1: un nombre de D-Bus que
nadie sirve.
LA CADENA DEL PORTAL SON TRES ESLABONES, NO DOS. Medido en el fuente:
xdg-desktop-portal-cosmic declara DBUS_NAME =
"org.freedesktop.impl.portal.desktop.cosmic" (src/main.rs:27) — es BACKEND,
no toma el nombre que los clientes buscan. Falta también el frontend
xdg-desktop-portal, y ninguno de los dos está en ninguna cola.
⚠ CORRECCIÓN AL PROPIO RUNBOOK: decía que `gvfs` exigía «una campaña
propia». Es falso desde que KDE selló las piezas. Verificado con `hammer
hash` desde las dos colas —el método correcto para saber si una receta se
comparte—: glib-shared 2.88.1 (b3:0584ce1f) y pcre2-shared (b3:f254abaa)
resuelven IDÉNTICO desde incoming-cosmic ⇒ cero rebuild, los artefactos
sirven tal cual. zlib-shared ya estaba en la cola. libffi entra estático
dentro de la .so (su Requires.private lo ignora pkg-config fuera del modo
estático).
Lo que queda de `gvfs` NO es técnico sino una decisión: mete una segunda
glib en la imagen —lo que GNOME midió y evitó— y re-hashea cosmic-files, que
arrastra a cosmic-term y cosmic-edit porque lo usan como crate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La quinta aplicación, y la primera de la suite que choca con que hammer es
OTRA distro: una tienda es la cara de un gestor de paquetes y el de abajo no
es el suyo. De los cuatro backends de `src/backend/`:
flatpak pide libflatpak (GObject) ⇒ la cadena glib COMPARTIDA más
ostree/libsoup/gpgme: la torre de C que esta campaña no tiene
packagekit Rust puro (packagekit-zbus) pero necesita el DEMONIO en el bus
rpm-ostree irrelevante
pkgar el único que arranca: ni demonio ni enlace, lee el AppStream
del sistema — o sea los .metainfo.xml que instalan las recetas
ALCANCE HONESTO: con pkgar NAVEGA, no INSTALA. Ninguna operación está
cableada al .swm de hammer (Etapa F). El camino para arreglarlo quedó
identificado y no cuesta un solo .so de C: servir
`org.freedesktop.PackageKit` sobre .swm, mismo patrón que
arje-logind-compat.
HALLAZGO REUTILIZABLE: `aws-lc-sys` (BoringSSL, C + ensamblador) compiló
bajo zig-cc/musl SIN cmake y SIN perl — ninguno de los dos está en los 182
binarios de work/builder-rootfs/usr/bin. Tomó el camino de bindings
pregenerados (`cargo:rustc-cfg=universal`) y compiló los 21 MB de
libaws_lc_crypto.a con el crate `cc`. El `Compiling cmake v0.1.58` del log
es el crate ayudante, que se compila aunque el binario no se invoque. Esto
destraba cualquier receta futura que entre con rustls por defecto, que hoy
es casi todo lo que use reqwest.
NEEDED: libxkbcommon.so.0 y libc.so, igual que cosmic-edit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El editor de texto sella en b3:2323a325, igual que el dry-run. Es la más
barata de las cuatro: depende de `cosmic-files` como CRATE con
`default-features = false`, así que su árbol ya estaba compilado (68 min de
enlace, no de compilación desde cero).
Lo que aprendió esta receta, y que corrige un borde de la regla anterior:
**el `Cargo.lock` lista lo POSIBLE, no lo ENCENDIDO**. Aparecen `gio-sys`,
`glib-sys` y `gobject-sys` —que en cualquier otro paquete mandarían a
declarar glib y de ahí a la cadena compartida— y sin embargo entran sólo por
la feature `gvfs`, que se apaga. El lock dice el universo; las features
dicen el recorte.
Features: `--no-default-features --features dbus-config,wayland`. Fuera
`gvfs` (pide las glib compartidas, el corpus las tiene estáticas) y `wgpu`
(el que desbordó el filesystem dos veces en cosmic-files).
La doble barra `pop-os//` que mordió en applets y settings acá está
comentada en el Cargo.toml; verificado con grep ANTES del build.
Evidencia: el binario enlaza sólo `libxkbcommon.so.0` y `libc.so` — dos
NEEDED, el mínimo de la suite.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sellada b3:716dac53. Cola 33/33, escritorio-cosmic 71/71. Abre desde el lanzador con la
barra lateral entera (Red, Bluetooth, Accesibilidad, Escritorio, Pantallas, Sonido,
Energía, Entrada, Aplicaciones, Fecha y hora, Sistema y cuentas). Tarda ~20s con render
por software; no está colgado.
La sorpresa buena: nada de NetworkManager, libpulse, udisks ni accountsservice — habla con
los daemons por zbus, que es Rust puro. Se verificó ANTES de escribir la receta listando
los crates -sys del Cargo.lock, que es donde vive la verdad sobre qué C hace falta: sólo
drm-sys, input-sys, libudev-sys, dav1d-sys, wayland-sys (dlopen) y gettext-sys. Regla
barata: grep '^name = ".*-sys"' Cargo.lock antes de adivinar deps por lo que el programa
hace.
Volvió a morder la doble barra de cosmic-protocols// (404 de GitHub, muere en el fetch con
tres reintentos). Segunda víctima ⇒ es patrón de la suite, no rareza de un repo.
Instala 32 .desktop, uno por página. Y default_schema va con find, no cp plano: es el árbol
<Componente>/v1/<clave> de cosmic-config, donde cada clave es un fichero con su nombre.
Deuda que deja su propio log: org.freedesktop.locale1 no lo sirve nadie ⇒ la página de
idioma no podrá cambiar nada. Mismo tipo que login1, mismo arreglo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sellada b3:48d2b072. Cola 32/32, escritorio-cosmic 70/70. Abre desde la biblioteca y lista
el sistema de ficheros real de hammer (bin 72 ítems, dev, ente, etc, lib, lost+found).
Entró creyendo que era casi gratis porque cosmic-term ya la compila como crate. No lo era:
cosmic-term la declara con default-features = false. Lo que un paquete cuesta depende de
con qué features lo pide quien lo usa, así que «ya se compiló» puede ser falso.
Dos features apagadas, las dos por medición:
· gvfs trae gio/glib y el enlace final pide las glib COMPARTIDAS; el corpus sólo las tiene
estáticas. Se pierden montajes remotos, no la navegación local. Por eso tampoco se
construye cosmic-files-applet: su Cargo.toml fija gvfs a mano.
· wgpu desbordó el filesystem dos veces (No space left on device en /src/target) con
wgpu+naga+ash+glow+spirv a codegen-units=1. Sin él el árbol queda en ~2 GB, y no se
pierde nada: el resto de la suite pinta con tiny-skia y la imagen no tiene GPU.
Y la regla que dejó el intento con glib declarado: el error fue «Package libpcre2-8,
required by glib-2.0, not found» — el que falla no es la dep sino lo que su .pc declara en
Requires. Declarar una dep trae su artefacto, no su clausura de pkg-config; se lee con
grep ^Requires sobre los .pc ANTES de gastar el build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sellada a la primera (b3:d0ea1c1e). Cola 31/31, escritorio-cosmic 69/69.
Dentro de la ventana: bash-5.3#, uname -srm devuelve Linux 6.16.12 x86_64 —el kernel
propio de hammer— y qalc -t '6*7' devuelve 42, o sea la calculadora que empaquetamos una
hora antes. Se abre con click en su icono en la biblioteca, que hasta hoy salía vacía con
razón: los 20 .desktop de la imagen eran NoDisplay=true. Éste no lo es.
Lo que arrastra y no se adivina: su Cargo.toml depende de cosmic-files, o sea que el
gestor de ficheros entra como LIBRERÍA (selector y drag-and-drop) y compilar la terminal
compila medio gestor de ficheros. En esta suite las aplicaciones se usan unas a otras como
crates, y el grafo de Cargo no se parece al mapa de componentes. De paso, empaquetar
cosmic-files como aplicación queda casi gratis.
wgpu viene en default, al revés que el resto de los clientes: se deja, porque wgpu y naga
ya se habían compilado enteros para cosmic-workspaces y apartarse de las features por
defecto es apartarse de la única combinación que upstream prueba. Cierra con dos NEEDED.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
=123*456 → 56088 en el lanzador. libqalculate re-sellado b3:edb8d14d.
La causa del «no lee nada de la tubería» no era readline, ni el toolchain, ni la versión:
el binario salía DINÁMICO pese a link="static", porque libtool se come el -static que
inyecta el harness. Y en un musl dinámico stdin, stdout y stderr se resolvieron por copy
relocation a UNA SOLA ranura de BSS compartida —las tres en la misma dirección—, así que
fileno(stdin) daba 1: el stdin del programa era el stdout. Eso explica la asimetría que
parecía absurda, que qalc -f /dev/stdin funcionara (abre el fd por RUTA, sin tocar el
FILE* roto) y qalc leyendo stdin no.
Fix: make LDFLAGS="-all-static -no-pie", el mismo par que ya usa libxml2. Con él los tres
símbolos vuelven a tener direcciones distintas en .rodata. Regla para el runbook:
link="static" en la receta NO garantiza un binario estático — readelf -d y
nm -S | grep ' std' lo contestan en dos segundos.
Segundo muro: qalc pregunta si activar autocalc antes de leer nada, el plugin le manda la
expresión y cierra, la expresión se consume como respuesta y qalc nunca llega a guardar
config ⇒ vuelve a preguntar siempre. Se siembra qalc.cfg desde cosmic-start, política de
imagen como el color de fondo.
Y hay que repetir el -L de los alias de curses en el make: el LDFLAGS del make pisa al
del configure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Las tres selladas a la primera (gmp b3:d99a0a5d, mpfr b3:13982d20, libqalculate
b3:6bb435a7). La cadena entera desde una tecla está en el catálogo: Super →
cosmic-launcher → pop-launcher → plugin calc → qalc → mpfr → gmp. Cola 30/30,
escritorio-cosmic 68/68.
qalc FUNCIONA: -t '2+2' da 4, -f fichero anda, e interactivo sobre terminal calcula.
Pero el plugin lo invoca SIN expresión, con stdin en tubería, le escribe la cuenta y
cierra — y en ese modo nuestro binario no lee nada. Acotado a que, con el EOF ya
pendiente en un stdin que no es terminal, readline() devuelve NULL antes de entregar la
línea que sí está en el búfer.
Descartado midiendo, para no repetirlo: no es el toolchain (una sonda estática musl del
sandbox lee la tubería en C y en C++); no es readline vs no-readline (sin ella es peor:
no lee nunca); no es la versión de readline (una 8.3 sombra no movió el síntoma, y se
descartó en vez de dejar una receta duplicada inútil); y no es el descriptor 0, porque
Could not open "/dev/stdin". —el mismo pipe reabierto por ruta— sí funciona. El que no sirve es
el FILE* stdin, y ahí queda la pista.
Dos gotchas del empaquetado: gmp va con --disable-assembly (elige rutinas mirando la CPU
de quien compila, o sea hornearía la ISA del laptop en el hash), y el configure de
libqalculate no encuentra readline porque prueba -lncurses/-lcurses/-ltinfo y el corpus
sólo empaqueta libncursesw.a — los alias van en un directorio local, no ensuciando
/usr/lib, que es la evidencia de qué se declaró.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-launcher sólo dibuja: manda lo tecleado por stdin a un proceso hijo, pop-launcher,
que es quien busca. Sin ese binario la ventana no tiene qué mostrar y no se muestra —
mismo modo de falla que el panel sin applets: falta un HIJO, no una librería, y el log
del padre se lee sano.
Vive en otro repo (pop-os/launcher), fuera del pin epoch-N. La versión la fija el
Cargo.lock de cosmic-launcher (rev a332a3a7 de la 1.2.7), no el último tag: el lock es
lo que garantiza que hablen el mismo protocolo. Tarball por commit, porque no hay tag que
nombre esa rev. Selló a la primera, b3:64a5cbaa, con un solo NEEDED: libc.so.
Verificado de punta a punta: Super abre el lanzador, «?» lista los seis plugins con su
sintaxis (o sea que la enumeración y el IPC JSON-sobre-stdio andan) y «=2+2» LANZA el
plugin, que contesta «qalc command is not installed». Esa respuesta es la mejor prueba
disponible: el hijo corrió, evaluó y devolvió fila. Falta libqalculate, que es un
paquete, no un problema.
Cola 27/27, escritorio-cosmic 63/63.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Faltaba sanear un SEGUNDO fichero: system_actions de cosmic-settings-daemon, que liga
acción→comando, con la misma entrada ScreenReader que el enum del parser no conoce. Con
defaults roto no hay ligaduras; con system_actions roto hay ligadura y ningún comando.
Ahora Super+A abre la biblioteca y Super+W la vista de espacios de trabajo — con
miniatura VIVA del escritorio dentro, o sea que el camino DMA-BUF→GBM de cosmic-workspaces
anda de verdad. Super a secas no abre nada porque pop-launcher (el motor del lanzador)
no está en el catálogo; los atajos no tienen la culpa.
Me equivoqué de fichero teniendo el dato: el error traía línea y columna y busqué el
token en vez del fichero que lo tiene en esa posición. Costó 40 minutos de rebuild.
Y el panel tiene un DEADLINE para registrar su servidor D-Bus: con -smp 4 arranca sin
ala izquierda, sin reloj y sin dock (894 colores vs 130); con -smp 8 -m 8192 son 4 de 4
completos. Perseguí eso como una regresión mía, revirtiendo tres cambios inocentes, porque
usé el conteo de procesos como veredicto: un escritorio sano muestra 32, no 48. El
framebuffer es el veredicto; los procesos no distinguen «arrancó» de «dibujó».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El click sobre «Applications» abre la biblioteca (el color dominante pasa de fondo 91%
a 27,27,27 84%) y tecleando aparece «cosmic» en el buscador. Se maneja entero por QMP
con input-send-event, sin humano y sin ver la pantalla.
USB HID, no virtio-input: el kernel de hammer no trae VIRTIO_INPUT, así que
-device virtio-keyboard no crea ni un /dev/input/event*. Con qemu-xhci + usb-kbd +
usb-tablet anda, y además es lo que se va a usar en metal.
Y el hallazgo de fondo: Super no abría el lanzador TENIENDO la ligadura en el fichero.
keybindings.ron de epoch-1.5.0 liga Super+Alt+S a System(ScreenReader), acción que el
crate que lo parsea (cosmic-settings-config, rev 8c54bbbc) no tiene en su enum. RON no
ignora lo desconocido: falla el mapa entero y se caen las 29 ligaduras. El único rastro
era un WARN de cosmic-idle a 200 líneas del arranque hablando de un enum — el síntoma no
nombra ni la tecla ni el fichero. El pin lockstep fallando desde adentro de upstream.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sellado b3:a031249e. La vista de espacios de trabajo muestra miniaturas vivas de las
ventanas: el compositor se las pasa como DMA-BUF por zcosmic-toplevel-info y el cliente
importa el fd con GBM ⇒ -lgbm. Es el único cliente de la suite que toca el pipeline
gráfico además del compositor, así que el juego fijo de cuatro no alcanzaba.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`cosmic-applets` declaraba `dbus` a secas. Alcanza para que el build.rs de libdbus-sys
pase —le basta el .pc, que el paquete del daemon trae— y el fallo salta recién en el
enlace final del multiplexor: 'unable to find dynamic system library dbus-1'. El corpus
sólo empaqueta libdbus-1.a; el .so vive en `dbus-shared`, que es lo que ya declaraban
settings-daemon y pipewire. Era la única receta de la cola que pedía la estática.
De paso, las cuatro piezas que spawnea el PANEL (no cosmic-session) entran como raíces
de hydrate-cosmic.sh: se invocan por AppID, así que ningún grafo de deps las alcanza.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
libdbus-sys cortó el build de cosmic-applets. El resto de la suite habla D-Bus
con zbus (Rust puro), pero los applets de red, bluetooth y status-area usan la
libdbus de verdad por FFI.
Gotcha de diagnóstico: el build.rs de libdbus-sys hace 'panic!' a secas en la
línea 25, sin mensaje. Lo único que dice qué falta es el NOMBRE DEL CRATE — no
buscar una explicación en el error, no la hay.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El manifiesto apunta a 'https://github.com/pop-os/cosmic-protocols//' con DOS
barras al final. Es como upstream hace que cargo trate esa fuente como DISTINTA
de la URL normal, para que el [patch] de al lado no se apunte a sí mismo. Pero
GitHub devuelve 404 a '/pop-os/cosmic-protocols//info/refs' y cargo vendor muere
en el fetch, antes de compilar una línea.
El primer intento fue cambiar '//' por '.git', y falló POR LA RAZÓN QUE HACE QUE
EL TRUCO EXISTA: cargo normaliza el .git, así que el patch pasaba a apuntar a la
misma fuente que reemplaza — 'patches must point to different sources'. La barra
de más no es reemplazable por cualquier variante cosmética: tiene que ser una que
cargo considere OTRA fuente y que el servidor sepa servir.
Sólo cumple las dos la barra en el MEDIO ('pop-os//cosmic-protocols'), que es
justo la forma que usa cosmic-comp — y por eso aquél construyó sin parche.
Se toca Cargo.toml y Cargo.lock juntos: cambiar uno solo rompe el --locked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-panel (b3:ac5e48c5) arranca perfecto: lee su config, crea su wl_output,
dice 'Spawning applets' y 'Done spawning applets'. Y la pantalla no cambió ni un
color. La respuesta estaba en esa misma línea: spawnea TRECE clientes por AppID y
ninguno existía. Un panel sin applets no es un panel vacío, es un panel que no
tiene nada que medir y no se dibuja.
Es la misma forma del muro de los typelibs en GNOME: un componente puede arrancar
sin errores y no pintar porque lo que le falta es un HIJO. El log del padre se lee
sano.
La receta cubre el panel entero de una: upstream compila UN binario multiplexor y
cada applet es un symlink con el nombre que el panel invoca; despacha por argv[0].
Veinte symlinks, dos binarios.
Fase compile custom porque hay que construir DOS targets (los default-members) y
'cargo rustc --' sólo admite uno.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
openssl-sys cortó el build con 'Could not find directory of OpenSSL installation'.
No lo pide el daemon: llega por native-tls, que llega por el crate geonames — la
base de husos horarios que usa para el tema claro/oscuro por hora. Es el único de
la suite que toca TLS, y por una función que nadie asocia con la red.
El openssl del corpus ya publica openssl.pc, así que alcanza con declararlo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Escrita mientras compila su dep: cosmic-session lo lanza con .expect() en
main.rs:255, así que si falta panickea la sesión entera JUSTO DESPUÉS de que el
compositor arrancó bien. Eso es lo que lo hace confuso de diagnosticar y lo que
lo puso último en la cola pese a ser obligatorio.
Es el único de la suite con cadena propia en C (audio-server → cosmic-pipewire →
libpipewire-0.3 por pkg-config), que es exactamente lo que costó traerlo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Medido en vez de estimado: copiar pipewire a incoming-cosmic necesita CUATRO
recetas hermanas (alsa-lib, dbus-shared, libsndfile, pulseaudio), no las seis que
había contado a ojo, y de esas **tres dan hash idéntico y ya están selladas**.
Sólo pulseaudio y pipewire hay que construir, porque su glib resuelve al corpus
(b3:93d2cad0) en vez de a la sombra de GNOME (b3:f6ccdf98).
Y eso refina lo que este runbook advertía: el peligro de las dos glib es MEZCLARLAS
EN UNA IMAGEN, y la imagen COSMIC tiene una sola. Acá el costo es de builds, no de
corrección. Lo que sigue vigente es no promover a ciegas entre colas.
Gotcha del copiado: el se resuelve relativo a la receta, así
que copiar el .toml sin su .patch da 'no pude leer patch' — el hash ni siquiera
se calcula.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La línea de enlace de cosmic-osd pedía '-ludev -linput -lxkbcommon': los tres
llegan por la cadena de libcosmic (enumeración de monitores y de dispositivos de
entrada), no por nada que el cliente haga a la vista.
Los venía descubriendo de a uno por build —xkbcommon con cosmic-bg, udev con
osd, ahora input— hasta leerlos todos juntos en el comando que rustc le pasa al
linker. El error dice el que falta primero; el COMANDO dice todos.
Entra además cosmic-idle rehecho dinámico (b3:e1806acc).
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>
Escritas ya con el patrón medido —libxkbcommon + pkgconf en todas— en vez de
descubrirlo cinco veces. Cada install sale del justfile/Makefile de upstream
leído, no del parecido con el anterior; ahí estaban las tres diferencias que
importan:
- cosmic-panel: default_schema NO es un fichero sino un ÁRBOL de tres componentes
de cosmic-config con un fichero POR CLAVE. Aplanarlo deja un panel que arranca
con todo por defecto compilado: sin plugins, sin dock, sin tamaño.
- cosmic-workspaces-epoch: los tres nombres NO coinciden — repo con sufijo
-epoch, binario y AppID sin él, y cosmic-session lo busca por el del binario.
- launcher y app-library instalan .desktop + metainfo + icono; notifications y
osd no llevan ninguno porque no se lanzan a mano.
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 declara `image` con default-features=false y sin AVIF, y aun así se
compila dav1d-sys: las features de cargo se UNIFICAN en el grafo, así que alcanza
con que otro crate del árbol la prenda para que la decisión del que la apagó no
mande. Mismo modo de falla que un '.pc Requires' arrastrando una dep que nadie
declaró.
Se podría parchear el Cargo.toml de upstream para cortarlo; no se hizo, porque
eso es mentirle al paquete sobre lo que hace. Si el grafo dice que sabe
decodificar AVIF, que lo sepa de verdad — y cualquier cosa del corpus que decodifique
AV1 va a querer dav1d igual.
Dos decisiones del build, las dos leídas del meson.build y no supuestas: nasm es
dep REAL (find_program en :536, exige >= 2.14; copiado de la cola GNOME con hash
verificado b3:33383070), y default_library=both porque quien consuma dav1d con
enlace estático necesita la .a — publicar sólo la .so convierte cualquier
link=static río abajo en una etiqueta falsa.
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>
cosmic-comp es LA pieza y la receta salió casi gratis: mirada-compositor ya
probó que smithay construye en este lab, y las deps en C de smithay dependen de
las features del backend, no del compositor. La lista es la misma menos
linux-pam y más libdisplay-info.
libdisplay-info y hwdata entran COPIADAS byte a byte de la cola GNOME (idénticas
a las de KDE): las deps resuelven hermano→padre, así que desde incoming-cosmic
no se ven las de otra cola. Verificado que el hash NO se mueve (b3:260f0519 y
b3:bdc36cf9) ⇒ los artefactos ya sellados sirven y la copia no cuesta un build.
cosmic-bg va antes que el resto de los clientes porque separa dos preguntas:
habla Wayland por smithay-client-toolkit y NO toca libcosmic/iced, así que si el
fondo pinta y el panel no, el problema es de la capa de UI y no del transporte.
Toda la suite está tagueada epoch-1.5.0, confirmado repo por repo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sonda barata antes del compositor: Rust puro, sin una dep en C, y prueba las
tres cosas nuevas que la cola COSMIC necesita — edition 2024 sobre el rustc 1.96
del sandbox, deps de git en el Cargo.lock (launch-pad, cosmic-dbus-a11y), y el
patrón de instalación de la suite (binario + start-cosmic + cosmic.desktop).
Salió a la primera: ELF estático, cero NEEDED.
Toda la cola incoming-cosmic va pinneada al tag epoch-1.5.0: COSMIC versiona sus
repos en lockstep y mezclar epochs no da error de compilación sino un escritorio
que no se entiende consigo mismo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Cierra un TODO que el propio script tenía escrito («esto pertenece al artefacto de
arje-logind-compat, no a la imagen») y que estaba bien puesto: **un servicio que no puede
adueñarse de su nombre no es un servicio**, así que su política D-Bus es parte de lo que el
paquete promete, igual que el binario. Con la política en el script de UNA imagen,
cualquier otra —metal, KDE, mirada— se llevaba el daemon y no podía usarlo.
arje-logind-compat b3:b4795829 · arje-polkit-compat b3:6c82f44b. Radio de las dos: 0.
**Y la comprobación que reemplaza a escribirlas atrapó un bug de verdad en el primer
intento.** Mover algo a un artefacto sólo es una mejora si se NOTA cuando falta, así que el
script pasó de ESCRIBIR los .conf a EXIGIRLOS. Falló al toque: `✗ falta
org.freedesktop.login1.conf`. Causa — el script inyectaba **sólo el binario** del artefacto
(`install -Dm755 .../usr/bin/...`), así que el .conf existía en el store y nunca llegaba a
la imagen. Sin esa comprobación habría sido el fallo tardío de siempre: daemon que arranca,
no adquiere el nombre, y 25s de espera por servicio sin decir por qué.
Verificado de punta a punta con las políticas viniendo del artefacto: los cuatro nombres
del bus arriba (login1, PolicyKit1, Accounts, UPower) y el audio intacto.
El `zz-` de la de polkit no es decorativo y queda explicado en su receta: a diferencia de
login1, ese nombre YA tiene política —la trae el artefacto de polkit— y permite `own` sólo
al usuario polkitd; dbus lee system.d en orden alfabético y las reglas posteriores ganan, así
que un fichero que ordene después AÑADE el permiso sin descartar el resto de upstream.
ColorManager sigue sin aparecer: es lo de colord, ya diagnosticado hasta dónde llega y
fuera del alcance de este cambio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La receta llevaba una bandera de include que su propio comentario marcaba EN DUDA: se
había puesto porque el build cortaba con `../lib/wp/wp.h:13: fatal error: 'client.h' file
not found`, un header que SÍ existe justo al lado del que lo incluye. La explicación real
era que **otro agente construía en el mismo repo y borraba árboles de work/sources/ en
pleno build** — la carrera del ADR 0012, que produce exactamente esa firma: ficheros que
existen cuando los mirás después y no existían al compilar.
Re-probado CON EL REPO QUIETO —comprobando primero que no hubiera ningún `hammer build`
vivo— y sella igual sin la bandera. Confirmado, no supuesto. Verificado además de punta a
punta: audio sigue dando `48. HDA Intel [alsa]` con sink y source reales, 0 page-flips
fallidos.
La lección queda en la receta: antes de agregar una bandera que no se explica, mirar si hay
otro build vivo. Es barato y evita inventar arreglos para síntomas que no son del código.
**GOTCHA DEL LAB, aprendido a la mala en el mismo movimiento: los BYTES del fichero .patch
entran al ArtifactHash.** Corregir la PROSA obsoleta de `pipewire-sound-initialized.patch`
—decía que la decisión libudev-zero-vs-eudev seguía pendiente cuando ya está resuelta—
re-hasheó pipewire y arrastró wireplumber. La distinción que conviene tener presente:
**comentar una RECETA es gratis** (hash_inputs toma source/compiler/target/link/flags/fases/
deps, no los comentarios del TOML) **y comentar un PARCHE cuesta un rebuild**. Anotado en
pipewire.toml, que es donde se va a leer.
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>
La receta iba con `-Ddaemon=false` y el razonamiento era «mutter enlaza libcolord, no
necesita el demonio». Cierto para COMPILAR mutter y falso para el escritorio andando: el
artefacto INSTALA el `.service` de activación (`Exec=/usr/libexec/colord`) y ese binario no
existía, así que cada arranque se comía 25s de timeout. **No era «colord apagado» sino
colord roto de forma lenta** — el peor de los dos, porque no falla, tarda.
Su propio comentario marcaba la condición de vuelta: «si alguna vez hace falta el demonio
de verdad, vuelve con polkit encima». Polkit ya está (arje-polkit-compat). Y medido: prender
el demonio **no agrega una sola dep nueva** salvo polkit-gobject-1, ya sellada — el bloque
de dependency() de colord 1.4.7 es de nivel superior y pedía gusb/gudev/libudev igual con
daemon=false. El coste estaba pagado desde el 2026-07-27 sin que nadie lo cobrara.
**PERO EL TIMEOUT SIGUE**, y lo que aprendí es dónde NO está:
- El binario existe y arranca: `/usr/libexec/colord` crea sus tres bases en
/var/lib/colord (mapping.db, storage.db) y lo dice en el log.
- Con `--verbose` NO hay una línea más después de abrir la tercera base.
- La política D-Bus SÍ permite `own` a root, y el `.service` corre como root: no es el caso
de polkit (donde `own` estaba restringido al usuario `polkitd`).
- Los cuatro `cd_main_load_introspection` que van entre las DB y `g_bus_own_name`
(cd-main.c:2434-2460) leen de un **GResource compilado en el binario**, no de disco, así
que no pueden faltar. Los XML instalados en /usr/share/dbus-1/interfaces son para otros.
⇒ Queda entre `cd_main_load_introspection` y `g_main_loop_run`, y el siguiente dato es si el
proceso sigue vivo en ese momento. **Esa comprobación me faltaba en el script** — reportaba
«colord lanzado (pid N)» sin verificar nada, que es exactamente el error que yo mismo había
señalado para upowerd («un pid no es un servicio») y no apliqué acá. Ya está puesta: sin
ella, «no apareció el nombre» no distingue MURIÓ de SE COLGÓ, y son dos investigaciones
distintas.
Verificado que no hay regresión en lo que sí funciona: audio (48. HDA Intel, sink y source
reales) y vídeo (0 page-flips fallidos) siguen bien con el demonio en la imagen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El kernel ya traía el driver (SND_SOC_SOF_TIGERLAKE); faltaban los blobs, y sin ellos SOF
carga y falla: en el laptop no hay sonido aunque ALSA esté. Mismo patrón que i915 con su
DMC/GuC — driver desde fuente, firmware pineado por contenido, porque Intel no libera el
código y la soberanía build-from-source no aplica a datos fijos.
Tres piezas, cada una por un motivo distinto:
- `sof-tgl.ri` + `sof-tgl-h.ri`: el firmware del DSP. Se copian LOS DOS porque el driver
elige según el SKU y no quiero hornear la suposición. **`cp -L` es obligatorio**: en
linux-firmware son SYMLINKS a `intel-signed/`, y un symlink relativo copiado a otro
árbol apunta a la nada. Verificado: los tres quedan ficheros reales (525K/447K/95K).
- `sof-tgl.ldc`: el diccionario de logs del DSP. No es opcional en la práctica — el
driver lo pide al inicializar y sin él el firmware arranca SIN TRAZA, o sea que el día
que algo falle no hay por dónde mirar.
- 47 topologías (`sof-hda-generic-*`, `sof-tgl-*`): describen el grafo de audio. El driver
pide UNA por nombre derivado de la máquina, y no se puede saber cuál sin el hardware
delante. Copiar de más cuesta megas; copiar de menos cuesta un viaje físico al laptop
para descubrir qué nombre pidió.
~3 MB en total. Si no hay SOF en el origen, AVISA y NO falla: el audio del laptop se
pierde pero la imagen sigue booteando y en QEMU suena por HDA legacy — fallar bloquearía
builds que no necesitan SOF.
Verificado que no hay regresión: con los blobs en la imagen, el audio de la VM sigue
funcionando por la ruta HDA (48. HDA Intel [alsa], sink y source reales) y cero page-flips
fallidos. **El camino SOF en sí queda SIN VALIDAR hasta el próximo viaje al metal** — en
QEMU no se ejerce, y eso está escrito en la receta del kernel en vez de dado por bueno.
De paso, la cabecera del script deja de mentir: se llama «firmware» y no «wifi» porque
copia las TRES familias de blobs que el metal necesita (iwlwifi, i915, SOF).
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>
ALSA =y en linux-metal (b3:613bca15): HDA legacy + codecs (lo que emula QEMU y usan las
máquinas pre-SOF), SOF para TigerLake (el laptop del target NO suena por la ruta legacy:
Intel movió el audio al DSP) y SND_USB_AUDIO. Todo =y porque el producto es monolítico.
⚠ Falta inyectar el FIRMWARE de SOF en la imagen (intel/sof/*.ri, sof-tplg/*.tplg), igual
que metal-firmware.sh hace con los tgl_* de i915: sin blobs el driver carga y falla.
FUNCIONÓ LA MITAD: en la VM `/dev/snd` ya trae controlC0 + pcmC0D0p/c y /sys/class/sound
lista card0. El kernel detecta la tarjeta. Pero wpctl sigue con `Devices:` vacío.
**Y LA CAUSA ES ESTRUCTURAL, no una propiedad que falte.** `get_card_nr` de SPA
(alsa-udev.c:178-183) sólo acepta el device CARD —`/sys/.../sound/card0`—, que es un
device de CLASE: sin major:minor, sin nodo en /dev. Y `udev_enumerate_scan_devices` de
libudev-zero recorre EXCLUSIVAMENTE /sys/dev/block y /sys/dev/char (udev_enumerate.c:281),
o sea sólo devices CON nodo; el udev real enumera /sys/class entero. **El device que SPA
necesita nunca entra en la enumeración**: no hay guarda que sacar, falta la mitad del
espacio de búsqueda. Salidas: (a) enseñarle a libudev-zero a recorrer /sys/class —radio 51
sellados— o (b) empaquetar eudev. Es decisión de arquitectura, no parche.
CORRIJO ALGO QUE ESCRIBÍ ANTES: el parche `pipewire-sound-initialized.patch` se hizo
creyendo que SOUND_INITIALIZED era el bloqueo, y NO lo era — con el parche aplicado el
resultado no cambió. Se conserva porque la incompatibilidad que describe es real (sin
udevd nadie pone esa propiedad y SPA descartaría toda tarjeta en cuanto la enumeración
funcione), pero su prosa ahora empieza avisando que no es la solución. Sacarlo del camino
importa: dejarlo presentado como el arreglo mandaría al próximo a buscar en el lugar
equivocado.
Dos arreglos de andamiaje que costaron un ciclo cada uno:
- **`-nic none` por defecto.** Agregar la tarjeta de sonido CORRIÓ LAS RUTAS PCI, la entrada
de disco cacheada en las VARS de OVMF dejó de coincidir, y la firmware se fue al orden por
defecto: PXE v4, PXE v6, HTTP… minutos de timeouts. Con un TIMEOUT corto eso se lee como
«la VM no arrancó» y el serial sólo dice `PXE-E16: No valid offer received`.
- El filtro del log de wireplumber era `alsa|udev|sound|card|monitor` con `tail -40`, y se
llenó de bluez/v4l2/libcamera —tres monitores que avisan que su plugin no está— dejando
fuera justo las líneas de ALSA. **Un filtro ancho con cola corta es peor que ninguno.**
Ahora filtra `alsa` y además copia el log entero a la raíz ext4 (tmpfs muere con la VM).
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>
adwaita-icon-theme b3:429aef43 + hicolor-icon-theme. No es cosmética: con el cursor por
SOFTWARE —obligatorio en virtio-gpu— mutter dibuja la imagen que le da el tema, y sin
tema el puntero se movía INVISIBLE. Ahora se ve en la captura, y la notificación del
shell tiene su icono. Colores distintos 582 → 618.
hicolor arrastrada por `Inherits=hicolor` del index.theme de Adwaita: la cadena de
fallback tiene que terminar en algo que sea un TEMA (con su index.theme), no sólo un
directorio. No trae un solo icono propio — es el contrato, no el contenido.
Dos gotchas medidos:
- **hicolor 0.18 pasó de autotools a meson**: su tarball ya no trae `configure` (127).
- adwaita declara `gtk-update-icon-cache` como `required: true` para un
`add_install_script` que **su propio autor marcó `skip_if_destdir: true`** — exige un
binario que en un build empaquetado no puede ejecutar. Se borran los dos bloques.
`required: false` NO alcanza: meson no propaga el disabler dentro de
add_install_script y revienta con «Unhandled python exception». Se descartó declarar
gtk4 como dep: acoplaría el hash de un paquete de DATOS al del toolkit.
**El setuid del launch-helper es la causa raíz de dos síntomas, no de uno.** El
`dbus-daemon-launch-helper` comprueba sus propios permisos antes de activar nada y se
niega si no es setuid root — de ahí el «The permission of the setuid helper is not
correct» de colord. Sin eso NINGUNA activación por bus de sistema funciona, que es
también por qué UPower timeouteaba a los 25s. La imagen ahora lo deja root:messagebus 4750.
Y `gnome-start` lanza upowerd, pero **verificando**: la primera versión decía «lanzado»
y el shell seguía esperando 25s. Un pid no es un servicio. Ahora comprueba que siga vivo
y, si murió, vuelca su log. Además crea los directorios de estado que upower deriva de
--prefix y sin los cuales se muere en silencio.
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>
== gnome-qemu :: compositor OK (wayland-0) — el shell ES el display server
== gnome-qemu :: STATUS +15s … +315s: gnome-shell=2
Sin una sola `JS ERROR`. gnome-shell corre 5 minutos seguidos sobre DRM real.
Dos cierres, los dos por auditar en vez de adivinar:
1. GL-1.0 y libxml2-2.0 sumados a gi-foreign-typelibs. La primera auditoría de
`<include>` la hice sólo sobre los girs de /usr/share/gir-1.0 y me faltaron los que
entran por los girs PRIVADOS de mutter (Clutter-16, Cogl-16 → GL-1.0, o sea que sin
él no carga `Meta`: el compositor entero) y por los de eds (Camel, EBook,
EDataServer → libxml2-2.0). Un ciclo de imagen+arranque perdido por auditar de menos.
La forma correcta —y ahora escrita en la receta— es cruzar los `<include>` de TODOS
los .gir del rootfs hidratado contra los typelibs presentes. Queda un solo huérfano,
`xlib-2.0`, que sólo incluye `xft-2.0`, a quien no incluye nadie: no es una falta.
2. libgdm vuelve a construir su `data/`. La había borrado entera por parecer «cosas del
greeter», y ahí vive el gschema **org.gnome.login-screen**, que gnome-shell lee al
arrancar: sin él muere con `Gio.IOErrorEnum: GSettings schema ... not found`. Un
esquema de GSettings no es un fichero de datos del demonio — es una interfaz publicada
que consume otro programa. Se borra sólo `subdir('dconf')`, la única pieza que necesita
el binario `dconf`.
Lo que queda son avisos, no muros: falta un tema de cursor, colord no arranca por el
setuid del helper, y `org.gnome.settings-daemon.peripherals.touchscreen` no existe
porque g-s-d está aparcada (rompe quick-settings, no la sesión).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con los siete de `dependencies.js` cerrados, el arranque avanzó y murió en uno que NO
está en esa lista:
JS ERROR: Requiring GIRepository, version 2.0: Typelib file ... not found
El que lo pide es **gjs**, desde su propio JavaScript embebido: su GResource trae
literalmente `imports.gi.versions.GIRepository = '2.0';` (verificado con strings sobre
libgjs.so.0). Dep de runtime del INTÉRPRETE — invisible al grafo de build Y a la lista
del shell. O sea que `dependencies.js` es necesario pero no suficiente: hay una capa
más abajo.
HAY DOS GIRepository Y NO SON LO MISMO, y los números confunden a propósito:
· GIRepository-3.0 = la API NUEVA, la que GLib absorbió (libgirepository-2.0). La
produce glib-introspected y ya estaba.
· GIRepository-2.0 = la API VIEJA, la de libgirepository-1.0.so.1, contra la que gjs
está enlazado. La produce gobject-introspection, pero sólo con
-Dbuild_introspection_data=true, y el nuestro va con false.
La 2.0 es la vieja porque nombra la librería 1.0; la 3.0 es la nueva porque nombra la 2.0.
Receta aparte en vez de prenderle la opción a g-i: su radio alcanza toda la cadena GNOME
(catorce recetas la declaran para escanear) y además traería de vuelta los typelibs de
X11/cairo que motivaron apagarla. Acá el radio es cero.
Replica el custom_target('gir-girepository') de upstream (gir/meson.build:494) pero
escaneando contra la libgirepository-1.0 ya instalada. **La lista de fuentes va enumerada
a mano y no como glob**, y no es prolijidad: `girepository/*.h` barre también
`gitypelib-internal.h`, que declara G_TYPELIB_ERROR; el scanner emite entonces el stanza
del error-quark y su binario temporal no linkea, porque `g_typelib_error_quark` es LOCAL
en la .so instalada. Upstream nunca lo escanea — el glob era el error.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5