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>
sergioandClaude Opus 5