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>
26/26 recetas selladas, escritorio-cosmic 62/62. La captura (895 colores) muestra el
panel superior con Workspaces/Applications, reloj y los applets de a11y, audio, red,
batería y encendido; el dock inferior con lanzador, workspaces y biblioteca; y el fondo
en el color exacto que configura cosmic-start. 48 procesos cosmic estables a los 30s.
Y CORRIGE UN DIAGNÓSTICO MÍO. Cuando el panel selló y no dibujó, lo atribuí a que le
faltaban los applets. Hacían falta —sin ellos el panel está vacío— pero no eran la causa
de la pantalla lisa: -device virtio-gpu-pci no reemplaza la VGA por defecto de QEMU, la
SUMA. Dos cards, dos outputs, cosmic-bg pinta en los dos y el panel se ancla en uno; el
screendump capturaba el otro. Log impecable, pantalla lisa. Con -vga none sale entero.
Un síntoma puede tener dos causas suficientes: arreglar la primera no prueba nada.
También: PATH como primera línea de cosmic-start. El getty da un PATH sin /usr/bin y en
la imagen mkdir sólo vive ahí, así que los cuatro mkdir -p fallaban en silencio — gratis
hoy porque los directorios venían horneados, fatal el día que cambie la imagen.
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>
Los cuatro que faltan (applets, launcher, app-library, workspaces) quedaron sin
sellar porque se cortó la sesión de trabajo, NO porque fallaran: los tres clientes
venían compilando limpio y cosmic-applets ya había pasado el vendoreo y la dep de
libdbus. Se retoman con un 'hammer build' directo, sin nada que diagnosticar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
No lo lanza la sesión sino el PANEL, por AppID, así que ningún [deps] ni la lista
de cosmic-session lo alcanzan. Sin él la imagen se declara completa y el
escritorio sale sin barra.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-session levanta la cadena completa sobre el kernel de hammer con arje-zero
como PID1: cosmic-comp → settings-daemon → notifications → panel → osd → bg. El
fondo pinta (164 colores, el azul configurado) y el cursor está.
Los cuatro que faltan (app-library, launcher, workspaces, greeter) dejan una línea
de error! y la sesión SIGUE VIVA — exactamente lo que la tabla de .expect del
runbook predecía. Verificado, no supuesto.
cosmic-notifications sellado (b3:3e2a5478) completa el mínimo viable de cuatro.
Nota de método: esta corrida fue headless porque el Xwayland del laptop perdió la
autorización a mitad de sesión ('Authorization required, but no authorization
protocol specified'). El screendump por el monitor de QEMU sirve igual y es la
forma automatizable de la regla de validar con pantalla.
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 arranque en modo session murió con 'failed to start notifications daemon'
(main.rs:306). Grepeando '\.expect(' aparecen los tres:
main.rs:255 cosmic-settings-daemon
main.rs:306 cosmic-notifications
main.rs:325 cosmic-panel
O sea que el mínimo viable de una sesión COSMIC son CUATRO binarios: compositor
más esos tres.
Cómo me equivoqué, que es la parte reusable: leí start_component(), vi que sólo
logueaba, y generalicé a 'todos menos el settings-daemon'. Pero notifications y
panel NO PASAN por esa función — tienen su propio .expect() unas líneas antes.
Buscar la función que lanza no es lo mismo que buscar los .expect del fichero, y
grepear la construcción que mata cuesta lo mismo y no generaliza de más.
De paso, el bloque que configura el fondo de color sale del branch de modo bare:
estaba adentro, así que en modo session cosmic-bg se quedaba con el wallpaper por
defecto (que vive en git-lfs y no existe) y la pantalla salía negra por una razón
distinta de la que se estaba investigando.
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>
Faltaba la mitad del método. SÍ cruzaba incoming-cosmic (lo usé
antes de tocar libdisplay-info, pipewire y glib), pero la campaña no estaba en el
KHIPU: build-state.py sólo conocía --kde y --gnome, y targets.toml no declaraba
perfil.
Y eso no era cosmético. Antes de este commit, decía
21 dependientes transitivos y dos imágenes; ahora dice 31 y TRES —
escritorio-cosmic entre ellas, con incoming-cosmic=10 en el reparto por cola. O
sea que el próximo que tocara libinput, libudev-zero o mesa habría MEDIDO DE
MENOS, que es exactamente el punto ciego que la metodología existe para cerrar.
Tres piezas:
- build-state.py --cosmic (y su build-state-cosmic.json).
- perfil.escritorio-cosmic en targets.toml, con las raíces que cosmic-session
levanta MÁS los datos que ningún [deps] alcanza (iconos, xkb, fuentes, bash,
dbus). Primera medición: 54/61 listo, faltan 7.
- el LATIDO lo regenera, por la misma razón por la que se le agregó GNOME en su
momento: un frente que el cron no regenera envejece en silencio, y un grafo
viejo miente con la misma cara que uno fresco.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
start_component() sólo hace error!() y sigue (main.rs:558). Medido leyendo el
código, no probando: la sesión arranca con la suite incompleta y lo que falte
aparece como líneas de error. Cambia el orden en que conviene probar.
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>
El getty ejecuta cosmic-start sin ambiente heredable, así que probar el modo
session exigía editar el script. Ahora la imagen hornea /etc/cosmic-mode, mismo
truco que /etc/gnome-mode.
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>
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>
Hermano de hydrate-gnome.sh y con su misma propiedad: el cierre sale del GRAFO
REAL de recetas y el artefacto se elige por 'hammer hash' (la receta de HOY), no
por el más reciente del store, que con dos artefactos del mismo paquete miente.
Las raíces se nombran a mano porque en COSMIC la brecha entre cierre de build y
cierre de runtime es enorme: cosmic-session lanza a sus componentes por PATH y
por nombre, así que ninguno es dep de build de otro y el grafo no los ve. La
lista autoritativa es cosmic-session/src/main.rs.
Resultado: 207 binarios, 109 .so, y los siete NEEDED de cosmic-comp resueltos
dentro del propio cierre. Falta sólo el loader musl, que lo pone la base metal.
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>
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>
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>
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>
sergio
