GitHub: sergiovelasquezzeballos/hammer -> takana (sigue privado). El segundo
pushurl del origin y el default de espejo-setup.sh actualizados; push real
verificado contra los DOS destinos.
Las dos colas las encontro hammer-4a y las verifique antes de aplicarlas:
1) CINCO scripts hardcodeaban /home/sergio/hammer y hoy funcionaban SOLO por el
symlink que puse al mover. El peor era respaldo-storagebox.sh, cuya RAIZ por
defecto salia de ahi: si alguien limpia el symlink dando el renombre por
cerrado, el RESPALDO apunta a una ruta inexistente. Un respaldo que no
encuentra su raiz no falla ruidosamente — se descubre el dia que lo
necesitas. Ahora apuntan a /mnt/vvv/takana, la ruta real, sin depender de
ningun enlace.
2) Cuatro referencias a gitea.gioser.net/sergio/hammer. El diagnostico del peer
era el correcto y lo comprobe: ese HOST no resuelve, y no por el renombre —
ya estaba mal antes, el remoto real es git.gioser.net. Cambiar solo
hammer->takana las habria dejado igual de rotas. Van a
https://git.gioser.net/sergio/takana, que responde 200.
El directorio se movio de verdad, asi que las referencias absolutas dentro del
repo ya eran incorrectas. Tambien los ejemplos que usaban ~/hammer.
NO se tocan docs/evidencia/: son REGISTRO de lo que se corrio ese dia, y
reescribir una ruta ahi adentro falsifica la evidencia. Que nombren una ruta que
ya no existe es correcto: existia cuando se midio.
250 líneas de comentario en 151 scripts. Control verificado: el diff no toca
NI UNA línea que no empiece por #, y la sintaxis de los 151 pasa.
El barrido saltea heredocs y cadenas triples, y el guardián DISPARÓ 3 veces:
las tres eran el MOTD que el script escribe DENTRO de la imagen construida —
texto del producto, no comentario del script. Se cambiaron aparte y a
propósito, que es rebranding, no limpieza.
Y el hallazgo caro: casaba contra ,
que es el TARGET de tracing — o sea el module_path!, o sea el nombre del crate.
La etapa 4 lo movió a y el script quedó casando NADA. No fallaba:
imprimía cero atribuciones, indistinguible de un log sin problemas. Comprobado
con el binario (RUST_LOG=info sobre zlib), no deducido. Ahora acepta las dos, y
tiene que seguir aceptándolas porque los logs viejos en disco dicen la vieja.
Además 14 rutas de módulo en docs, que el barrido anterior no tocó
porque no es frontera de palabra.
645 líneas. Los ADR entran porque en este repo SON documentos vivos, no
registros inmutables: el 0013 tiene 5 commits, el 0009 dos. Eso se comprobó
antes de decidir, no se asumió por convención general.
EXCLUIDOS por ser REGISTRO o generado: docs/evidencia/ (6), el HANDOFF de la
noche de KDE (1) y docs/state/ (24, se regenera solo). Reescribir un comando
dentro de una evidencia la falsifica.
Y el ADR 0016 se excluye de todo barrido, con un aviso adentro para el próximo
que barra: habla SOBRE el renombre, así que necesita seguir diciendo 'hammer'.
El barrido se lo llevó puesto y lo dejó titulado 'Renombre del sistema: takana
→ takana'; revertido.
Congelados, verificados uno por uno con controles: /opt/hammer, /var/lib/hammer,
/usr/bin/hammer, /mnt/vvv/hammer, la URL de gitea, hammer-farm.service,
hammer-live-install.sh, BRIEFING-hammer.md, hammerd, hammer-recover y
HAMMER_LIVE.
Los llamadores EJECUTABLES: scripts/ (incluida toda la granja), los runbooks y
CLAUDE.md. Seguro porque la 3a ya garantiza que el worker emite los dos
binarios, y porque en farm-lab-sync.sh el cargo build remoto precede a la
invocación remota en el mismo script.
Verificado: sintaxis de los 49 (bash -n / py_compile — ojo que
why-differs-barrido.sh es Python con extensión .sh) y `takana hash` devuelve
hash real sobre el store.
NO se toca en esta etapa, a propósito:
- La variable de entorno HAMMER=. Es interfaz de los scripts entre sí y hay
llamadores que la fijan; renombrarla va con la etapa 4.
- docs/evidencia/ y los HANDOFF: son REGISTRO de lo que se corrió ese día.
Reescribir un comando dentro de una evidencia la falsifica.
- docs/state/: es generado, se regenera solo.
- Los ADR y los docs de diseño: texto, y `hammer` sigue funcionando. Van con
la etapa 5, que es la de churn de texto.
`-DKCOREADDONS_USE_QML=OFF` estaba desde que se escribió la receta, con el argumento razonable de
que un framework tier-1 no debería arrastrar QML. El precio no se vio hasta hacer CLIC en el
lanzador dentro de QEMU: `kickoff` importa `org.kde.coreaddons` y ese módulo lo instala esta receta
y ninguna otra ⇒ **el menú de aplicaciones no abría**. La librería C++ salía completa, sus 70
consumidores enlazaban bien y el perfil reportaba 100%.
Es la forma más pura del «sellado ≠ arranca»: no falta una librería, falta una porción OPCIONAL de
una librería que sí está. Ninguna métrica de clausura puede verlo — mide recetas, no features.
`qtdeclarative` ya estaba en `[deps].build`, así que prenderlo no agrega una dep: deja de tirar lo
que ya se podía construir.
VERIFICADO CON UN SOLO BUILD (56 s), a propósito, en vez de pagar la cascada para averiguarlo:
· panel → menú abre (usuario, buscador, Favoritos/Todas, Aplicaciones/Lugares/Sesión)
· buscar «konsole» + Enter → la terminal arranca y corre:
uname -a → Linux (none) 6.16.12 #1 SMP PREEMPT_DYNAMIC … x86_64
konsole --version → konsole 25.04.3
Es la cadena completa del escritorio por primera vez: panel → menú → búsqueda → app → shell.
COSTO, medido antes de tocar y confirmado después: `yupana radio kcoreaddons` predijo 71, y el grafo
regenerado da exactamente **71 en deuda** (`escritorio-kde 192/263`). Queda como deuda DECLARADA
para una campaña de granja; la imagen de hoy corre con un kcoreaddons más nuevo que aquel contra el
que enlazaron sus consumidores, lo que es legítimo porque cruza un SONAME (misma ABI, sólo se suma
un módulo QML) — la misma regla que decidió la promoción de pipewire.
De yapa: `export SHELL=/bin/sh` en plasma-start-qemu.sh. El aviso rojo de konsole («Could not find
'', starting '/bin/sh' instead») era real y no venía de /etc/passwd —que dice /bin/sh— sino de que
konsole lee $SHELL y este getty no es un login shell.
Y el barrido que encuentra esto sin hacer clic queda escrito en el runbook: cruzar los `import` de
los `.qml` instalados contra los módulos con `qmldir`. Además de éste destapó `org.kde.kscreenlocker`
y `org.kde.newstuff.core`, sin diagnosticar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YGXe6mShYYw6V8ea1dQ13u
Verificado en QEMU tras declarar `breeze-icons`: el panel pasa de «reloj solo» a completo —
kickoff, gestor de tareas, bandeja (notificaciones, volumen, teclado, red), reloj y mostrar
escritorio. Confirma que el panel nunca estuvo roto: no tenía iconos que dibujar. Y el mensaje
`kf.iconthemes: Icon theme "breeze" not found` desapareció del log.
⚠ CORRIJO una atribución del commit anterior (d69c437): dije que la barra derecha vacía de la
captura de GNOME era el mismo hueco de iconos, y NO lo es — `scripts/gnome/hydrate-gnome.sh` SÍ
hidrata `adwaita-icon-theme`, así que ese rootfs tenía tema. El hueco de GNOME es real pero está
en el PERFIL (`targets.toml`, que es lo que define la imagen enviable), no en aquella corrida;
la barra derecha vacía tiene otra causa, sin diagnosticar.
Y la segunda captura es un hallazgo nuevo, encontrado haciendo CLIC en el lanzador desde el
monitor de QEMU:
kickoff/main.qml:191:25: Type FullRepresentation unavailable
Header.qml:18:1: module "org.kde.coreaddons" is not installed
`kcoreaddons.toml` pasa `-DKCOREADDONS_USE_QML=OFF` ⇒ el módulo QML no se construye ⇒ **el menú
de aplicaciones no abre**. `yupana radio kcoreaddons` = 71: prenderlo es campaña de granja.
El barrido que lo generaliza (cruzar los `import` de los `.qml` instalados contra los módulos con
`qmldir` del rootfs) encontró además `org.kde.kscreenlocker` y `org.kde.newstuff.core`.
El runbook queda con las tres piezas que hacen falta en gioser, que no tiene ni ventana ni socat:
STAGE en el volumen (o EXDEV), monitor por socket unix desde python, y cómo hacer CLIC con un
ratón RELATIVO (fijar contra una esquina y moverse desde ahí).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YGXe6mShYYw6V8ea1dQ13u
`diff-back` contesta «¿el .config honra el PLAN?»; el contrato contesta la otra
mitad, «¿el kernel trae lo que el userland usa por nombre?». Son distintas: un
kernel puede honrar su plan al pie de la letra y no tener MEMCG, que nunca
estuvo en ningún plan porque nadie lo pidió.
Queda dicho también que hoy sale ROJO a propósito (2 de 11) y por qué.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih
Deja escrito lo que costo 21 G el 2026-08-22: `farm-up.sh N` apunta los N
workers al mismo VOL_NAME y un volumen de Hetzner se adjunta a un unico server,
asi que correr sharded exige un volumen POR worker. Con el comando exacto.
Y la linea de crontab del latido, que vive FUERA del repo y se perderia si
gioser se rehace. Incluye por que las dos rutas van absolutas: cron arranca en
$HOME y la redireccion del log se abre ahi, no donde uno cree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xd5DComN9Nu47TBpYMBHBn
Primera vez que el armador se usa para lo que existe, con artefacto real al final:
b3:8ffd57109a2f7102c1bbbbc91cf0e729047312eee1a4e3fdb8b178680cc94264-linux-gioser
linux-metal derivada gioser
bzImage 14,5 MB 11,1 MB (-23%)
símbolos encendidos 1805 1647
diff-back contra el artefacto ... 35 cumplidos, 0 INCUMPLIDOS
gate contra el artefacto ........ ningún dispositivo en uso sin driver
La base la eligió el probe, no la intuición: linux (el de QEMU) apaga USB, HID e INPUT a
propósito y gioser tiene xhci_hcd, usbhid e i8042 bindeados ⇒ linux-metal. 13 bundles y 3
perillas, 34 banderas, clausura de 3054.
Segunda validación de la clausura contra el olddefconfig real, ahora sobre otra base y con
13 bundles: 154 aciertos, SOBRA 0, faltan 18 (todos de la clase «apagado ahora ≠
inalcanzable» del §12).
LA PRUEBA DE 30 s PREDIJO EL BUILD DE 45 MIN. El .config del artefacto y el de la prueba en
seco difieren en 14 líneas y NI UNA es funcional: son las siete versiones del toolchain que
el kernel graba en su propio config (CC_VERSION_TEXT, GCC_VERSION, AS_VERSION, LD_VERSION,
RUSTC_VERSION, RUSTC_LLVM_VERSION, PAHOLE_VERSION). Cero símbolos de diferencia ⇒ la prueba
barata es un sustituto fiel para todo lo que el armador decide.
Y de regalo, la mecánica exacta de por qué el lab TIENE que estar en hash_inputs: el kernel
graba la versión de su compilador DENTRO del .config, y el .config va dentro del artefacto.
No es que el lab «influya» en el resultado — es que el lab está literalmente en el
contenido sellado. Se ve línea a línea: gcc 15.2.0 del lab anclado vs 16.1.1 del host.
PAHOLE_VERSION=0 confirma además lo que dice la cabecera de linux.toml.
La receta derivada NO se deja en recipes/: build-state.py y yupana barren recipes/ y
recipes/incoming-*, así que dejarla ahí la mete en el grafo compartido como deuda. Va en
docs/state/kernel-plans/ con el comando que la regenera; para construir se copia a
recipes/incoming-kernel/ temporalmente y se saca después.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hasta acá el armador era análisis puro: la clausura decía qué debía morir y nadie lo había
contrastado con el resolvedor real. NO hace falta construir un kernel para hacerlo: lo caro
es la fase compile (35-60 min); toda la cadena del armador vive en configure y corre en
segundos.
Método: árbol 6.16.12 entero, `make defconfig` de base (el config de linux.toml NO sirve de
base: ya apaga wifi/audio/fs a mano, así que el lado disable no apagaría nada y la
predicción no se pondría a prueba — fue mi primer error), el fragmento del plan, y
olddefconfig. Verdad de campo = los símbolos que pasaron de encendidos a apagados.
sólo depends on ....... clausura 1775 aciertos 64/68 SOBRA 0 falta 4
+ huérfanos select .... clausura 1794 aciertos 65/68 SOBRA 0 falta 3
+ comparaciones ....... clausura 1795 aciertos 65/68 SOBRA 0 falta 3
SOBRA 0 en las tres: el predictor nunca dice que muere algo que sobrevive, que es la única
dirección en la que puede equivocarse sin fabricar un ladrillo.
Dos refinamientos que salieron de la medición, cada uno con su test:
· HUÉRFANOS DE SELECT. Un símbolo sin prompt no se marca a mano: sólo entra por select.
Si caen todos sus selectores, cae él, aunque nadie dependa de él (caso ACPI_NHLT). Se
exige >=1 selector: sin ninguno entra por un default, y darlo por muerto mataría media
tabla.
· `X = y` SÍ ES DEPENDENCIA DURA. Medio drivers/video/fbdev declara su dependencia de FB
como `depends on (FB = y) && ARM`. Tratar toda comparación como opaca dejaba esos
drivers fuera. `X = n` sigue fuera a propósito: con X en n es VERDADERA. De regalo, las
fugas select sin declarar de sin-graficos cayeron de 8+ a 1.
Los 3 que faltan NO son un fallo, son otra pregunta: CRYPTO_LIB_ARC4, REGMAP y
SYSTEM_DATA_VERIFICATION tienen selectores FUERA de la clausura (PPP_MPPE, 111 usuarios más
de REGMAP…). Se quedaron sin usuarios en ESE config; encendés PPP y ARC4 vuelve.
«Inalcanzable» y «apagado ahora» no son lo mismo, y la clausura contesta la primera.
Y un bug que sólo aparece corriendo el resolvedor: el diff-back contaba como promesa
incumplida todo símbolo pedido ausente del .config. Pero Kconfig NO EMITE un símbolo cuyas
dependencias no se cumplen ⇒ un `-d WLAN` cuya raíz ya cayó simplemente no sale. Con esa
cuenta un plan perfecto se reportaba roto (2 falsos incumplidos de 16). Ahora: ausente +
se pedía apagar = éxito; ausente + se pedía encender = fallo. La corrida real sale 14
cumplidos, 0 incumplidos.
GUARDIÁN NUEVO, y hacía falta: las cuatro recetas de kernel NO son el mismo kernel — linux
y linux-metal van por 6.16.12, linux-metal-dual y linux-generic por 7.1.2. Planear una
contra el árbol de la otra calcularía clausuras sobre símbolos que ahí no existen, y
saldría SIN RUIDO. KconfigTree lee ahora su versión del Makefile de arriba y `plan` FALLA
si no coincide con la de la receta (los diagnósticos sólo avisan). Aviso de la sesión de
granja/store, verificado antes de implementarlo.
Catálogo: las dos fugas que destapó la clausura más grande quedan declaradas con motivo
(FB_SYSMEM_HELPERS_DEFERRED por HID_PICOLCD_FB; DRM_DISPLAY_DP_TUNNEL_STATE_DEBUG por
DRM_I915_DEBUG), y las notas sobre THUNDERBOLT/REISERFS_FS pasan a pasado: ya se
corrigieron en 2602218.
Runbook §4.bis: cómo probar un plan entero en 30 s en vez de 40 min.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
«no encuentro el ejecutable zig en …» no quiere decir que falte zig: falta ESA versión.
hammer lo resuelve en .dev-fs/tools/zig-x86_64-linux-<ver>/, ni el symlink tools/zig ni el
PATH cuentan.
Medido para el caso concreto del kernel: linux.toml NO pinea zig_version, pero tres de sus
deps.build sí — flex, openssl y elfutils, las tres a 0.13.0 — y la receta derivada las
hereda enteras. En gioser están 0.13.0 y 0.16.0, así que el eje está cubierto.
Aviso de la sesión de granja/store; verificado contra las recetas antes de escribirlo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
work/.farm-build.lock, el mismo que toman farm-worker-loop.sh y campana-deuda.sh.
hammer build comparte work/sources/<dep>-<sha> entre todas las recetas: dos builds
simultáneos que compartan una dep se pisan (uno hace fetch y borra el árbol mientras el
otro lo usa) y el árbol queda roto PARA SIEMPRE — reintentar no lo arregla. Medido: al
invalidar libdrm, ~93 de 205 recetas KDE murieron por el wrapper .zwrap/cc barrido del
árbol de fuente. ADR 0012, sin decidir.
El runbook era el único sitio de este frente que mandaba a construir. El resto del armador
no toca el store: plan calcula el ArtifactHash con cómputo puro sobre las recetas, y
probe/gate/bundles/closure sólo leen.
Aviso de la sesión de granja/store, que comparte el repo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Paso 3 del §8 del SDD 22, y cierra el orden que fijaba: reversa, clausura, gate, diff-back.
La pieza que faltaba no era el gate sino el MAPA driver → símbolo. El kernel sabe qué
driver tiene bindeado cada dispositivo, pero no de qué CONFIG_* salió: esa relación sólo
existe en los Makefiles de kbuild. modmap.rs lee 15.789 reglas obj-$(CONFIG_X) += y.o en
3182 Makefiles. Dos trampas de nombres, cada una con su test:
· el módulo cargado usa _ donde el fichero usa - (snd-hda-intel.o → snd_hda_intel)
· un módulo puede salir de VARIOS símbolos, y sobrevive si sobrevive cualquiera
Sin resolverlas el gate no encontraría nada y diría que todo está bien, que es el peor
resultado posible para un portón.
POR OBJETIVO, no global. La regla es "todo dispositivo en uso debe seguir teniendo
driver"; aplicada global rechazaría recipes/linux.toml, que apaga USB, HID e INPUT A
PROPÓSITO por ser el kernel de QEMU con consola serie. El gate NO CORRE sin --objective, y
un allow_bundles con un id mal escrito es error de CARGA del catálogo (si no, autorizaría
nada y bloquearía sin que se entienda por qué).
Medido con el mismo plan (sin-usb + sin-entrada-humana + sin-graficos + sin-wifi) y el
hardware real de gioser:
qemu-serial ........ PASA — 5 pérdidas autorizadas
metal-escritorio ... BLOQUEA — las mismas 5 como regresiones, con el bundle culpable
Ése es todo el punto del §5.
Y lo que el gate no puede comprobar, lo dice: de los 38 drivers bindeados, 15 no se
mapearon a ningún símbolo (pcieport, serial8250 — built-ins cuyo nombre de driver no
coincide con el del módulo). Quedan listados como SIN COMPROBAR, nunca como aprobados.
hammer kernel hw vuelca la huella y los drivers de la máquina DESTINO, que no tiene por
qué ser la de build — el SDD lo pedía explícitamente.
Cuatro objetivos en el catálogo (qemu-serial, servidor, metal-escritorio, portatil) y un
runbook nuevo: docs/runbooks/armador-de-kernel.md, con el ataque de punta a punta y una
lista honesta de lo que todavía NO está (sonda en VM, atestación por huella, bisección,
curación del delta con modelo, perillas side=recipe).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documenta el diagnóstico del OptiPlex 3060: la GPU estaba perfecta (i915 inicializó,
fbcon en el framebuffer) y lo que fallaba era el hardcodeo de software GL, más la
preparación de sesión que la imagen de metal nunca tuvo.
Deja las dos reglas: un artefacto compartido entre QEMU y metal no puede llevar el
entorno hardcodeado (se detecta), y «llega al prompt» no valida NADA del escritorio
— hay que correr cosmic-start en la imagen que se va a quemar.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Documenta el diagnóstico completo: la AUSENCIA del `EXT4-fs mounted` como prueba de
que el root nunca se montó, la carrera contra la enumeración USB (invisible en QEMU
porque virtio está desde el instante cero), y la ceguera del /dev/console = serial.
La lección que generaliza: CADA capa del arranque tiene que escribir a /dev/tty0. Se
arregló la capa post-switch_root en el viaje de KDE y el initramfs quedó ciego; tapar
una sola capa garantiza que la siguiente vuelva a caer.
Incluye el comando para reproducir metal desde el laptop (qemu-xhci + usb-storage +
-serial null) y la evidencia en pantalla.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Qué correr con el USB en la mano, en orden, y —lo que importa— CUÁL ES EL VEREDICTO:
el `[4/4] OpenPipeWireRemote` con su fd, no que el diálogo aparezca (eso ya pasaba en
QEMU). Y el contrafáctico que hace falsable el diagnóstico de hoy: si vuelve a
colgarse en `Start` pero YA NO aparece `Erroneous EGL call` en el log del compositor,
entonces la causa era otra y lo de hoy estaba incompleto.
`ls /dev/dri` con renderD128 es la señal barata de que hay HW: con swrast no existe.
Gotchas del quemado, todos medidos y todos con su porqué:
· NUNCA a un NVMe y NUNCA POR NOMBRE — hoy mismo, tras el reboot, nvme0n1 y nvme1n1
se intercambiaron respecto de lo anotado en julio. Identificar por TRAN=usb.
· el progreso NO se mide con kill -0 (sudo dd corre como root ⇒ EPERM desde el
usuario y parece que terminó): se mide por /sys/block/sda/stat campo 7.
· no correr os-prober sobre el device que estás dd-eando.
· `pkill -f <patrón>` mata su propio shell si el patrón está en su cmdline. Volvió a
pasar hoy (exit 144), con el gotcha ya escrito. Usar pgrep -x.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con RUST_LOG=trace el log del backend tiene CINCO LÍNEAS en total y la última es la
de siempre ('Connecting' -> 'Paused'). Después no escribe nada más: ni error, ni
panic, ni progreso. O sea que el trace no aportó — screencast_thread no tiene más
instrumentación y buscar ahí estaba agotado.
La pieza que faltaba mirar era EL COMPOSITOR, que es quien entrega los frames:
15:19:02.301568Z WARN smithay::backend::egl::error: Erroneous EGL call didn't set EGLError
15:19:02.310127Z INFO …screencast_thread: state-changed 'Connecting' -> 'Paused'
↑ OCHO MILISEGUNDOS
Y la correlación no es casual: el contador de "Erroneous EGL" sube DE A DOS por cada
intento de screencast (uno al abrir el diálogo con su miniatura en vivo, otro al
pulsar Share) y no se mueve en ningún otro momento.
`ls /usr/lib/dri/` → iris_dri.so, kms_swrast_dri.so, swrast_dri.so. En QEMU con
virtio-gpu-pci sin virgl carga kms_swrast: mesa por software, SIN exportación dmabuf
real. Que es justo lo que un stream continuo necesita y una captura de una sola toma
no — por eso cosmic-screenshot SÍ funciona (va por shm) y ScreenCast no.
EL FRENTE NO ESTÁ BLOQUEADO POR UNA RECETA SINO POR EL ENTORNO. Esto reencuadra el
día entero: pipewire no era, wireplumber no era, el backend no era. Las tres piezas
están construidas, corriendo y haciendo su trabajo —el nodo `cosmic-screencast` existe
en el grafo— y el que no puede cumplir es el compositor sobre una GPU de software. Es
el MISMO muro que documenta el frente KDE (GBM/EGL de software), llegando por otro
camino.
Y no se puede verificar acá: `qemu-system-x86_64 -display help` da sólo none/gtk/sdl
y no existe virtio-gpu-gl-pci — este binario no se compiló con virgl, aunque
libvirglrenderer.so.1 esté en el host. Las salidas son metal (donde iris_dri.so YA
está en la imagen) o un QEMU con virgl.
Lo honesto: ScreenCast está verificado HASTA DONDE EL ENTORNO PERMITE — la cadena
D-Bus completa funciona, el stream se crea y se negocia, y el último tramo (los
píxeles) depende de una GPU que esta VM no tiene.
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>
El bloqueo decisivo de ScreenCast no era una receta que faltara: `/usr/bin/pipewire`
estaba en la imagen desde que entró como dep de `cosmic-settings-daemon`, pero NADIE
lo lanzaba. En una distro con systemd de usuario eso lo hace `pipewire.socket`; acá
no hay tal cosa, así que es tarea de `cosmic-start` — el mismo patrón que el bus de
sistema y que login1.
Va justo después de asegurar XDG_RUNTIME_DIR y NO junto al bus de sesión, a
propósito: pipewire no necesita D-Bus para arrancar, sólo el runtime dir donde abre
su socket. Ahí sirve para los dos modos (bare y session) sin duplicar el bloque. Y se
espera EL SOCKET, no el pid: un demonio que muere al instante deja el pid existiendo
un rato, y esperar por él da un OK falso.
Medido dentro de la VM, cada paso una pregunta distinta:
pipewire OK (socket pipewire-0, pid 189) ¿abre socket?
pw-cli info 0 → Core/4, 1.2.7, core.daemon ¿SIRVE a un cliente?
pw-cli ls Factory → "client-node" ¿tiene lo que ScreenCast usa?
pw-cli ls Client → "xdg-desktop-portal" ¡el portal YA está conectado!
La última línea es el veredicto: el frontend del portal aparece como cliente del
demonio, una conexión que antes no podía existir y que es justo la que `Start`
necesita para negociar el nodo. `client-node` es la factory con que el backend lo crea.
Sin regresión, con la cadena entera: `cosmic-screenshot` levanta la UI INTERACTIVA
del portal (región/ventana/pantalla + Capture + Save to Pictures) y el click deja un
PNG de 53.590 bytes. Esa UI no estaba documentada — el registro anterior sólo probaba
la ruta no-interactiva. Escritorio completo: 2414 colores (el panel mutilado da 130).
Lo que sigue faltando son DOS cosas distintas, y ninguna es un one-liner:
· el handshake de punta a punta pide un cliente `ashpd` PERSISTENTE — el portal
asocia la sesión al *sender*, así que CreateSession con un dbus-send y
SelectSources con otro se rechazan por venir de nombres únicos distintos;
· wireplumber, que separa "hay stream de video" de "hay audio". Ni construido está.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
BLOQUEO 1: dbus-send no puede manejarlo, al revés que FileChooser. El
selector se abre con UNA llamada; ScreenCast necesita un handshake de tres
pasos con estado (CreateSession → SelectSources → Start) y la sesión queda
atada a la CONEXIÓN que la creó — cada dbus-send es una conexión distinta
que muere al terminar, así que el paso 2 nunca encuentra la sesión del paso
1. Es límite de la herramienta, no del portal.
Lo que sí se midió: CreateSession FUNCIONA. El frontend devuelve
/org/freedesktop/portal/desktop/request/1_106/sc1 con nuestro handle_token.
BLOQUEO 2, y éste no lo arregla ningún cliente: NO HAY DEMONIO DE PIPEWIRE.
ls /usr/bin/ | grep -i pipewire → pipewire, pipewire-aes67,
pipewire-avb, pipewire-pulse
ps ax | grep -c pipewire → 1 (el propio grep)
Los binarios están —el backend del portal enlaza libpipewire-0.3.so— pero el
demonio no corre: cosmic-start no lo lanza y no hay systemd de usuario. O
sea que aunque se escribiera el cliente ashpd, Start no tendría con quién
negociar el stream. Arreglo: lanzarlo desde cosmic-start. Para AUDIO además
falta wireplumber, que ni está construido.
Y se corrigió un comentario DESACTUALIZADO de cosmic-start que decía que
cosmic-settings-daemon «todavía no se puede construir acá (arrastra
pipewire)»: es falso hace tiempo, ese daemon está sellado y corre. Un
comentario viejo manda a buscar un bloqueo que ya no existe, y eso cuesta
igual que un bug.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
NO SE PUEDE DESDE LA TIENDA. cosmic-store se compila con la feature
xdg-portal, pero su ÚNICO uso del selector (src/update.rs:505,
Message::RepositoryAddDialog) arranca con
`if backend_name == BackendName::FlatpakUser`: el diálogo sólo se abre para
añadir un repositorio flatpak, y esta imagen no construye el backend
flatpak. La feature está compilada y el punto de llamada es INALCANZABLE.
Tener la feature encendida no es tener el flujo disponible.
El camino que sí ejerce la interfaz es llamarla directo por D-Bus, que
además prueba los tres eslabones sin depender de qué app la use:
dbus-send --session --print-reply --dest=org.freedesktop.portal.Desktop \
/org/freedesktop/portal/desktop \
org.freedesktop.portal.FileChooser.OpenFile \
string:"" string:Prueba dict:string:variant:handle_token,string:hammer1 &
Medido: el frontend devuelve el objeto Request con NUESTRO token
(/org/freedesktop/portal/desktop/request/1_113/hammer3) y el backend dibuja
el diálogo REAL — título «Prueba», el FS de verdad (run/tmp/dev/proc/sys),
panel de detalles (inode/directory, 963 items), Cancel/Open. La navegación
anda: doble clic en dev cambia la miga a «Filesystem › dev» y lista sus 129
entradas; seleccionar y pulsar Open lo cierra.
⚠ LO QUE NO QUEDÓ CAPTURADO: la URI devuelta. El Response de la spec de
portales es una señal UNICAST al llamador, y dbus-send termina apenas recibe
el method return, así que ya no está para recibirla; dbus-monitor con un
match rule normal tampoco la ve. Pide un cliente que implemente el ciclo
Request/Response, que es lo que hace ashpd dentro de las aplicaciones.
El diálogo está probado; la entrega del fichero a la aplicación, no.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Del lado CLIENTE (org.freedesktop.portal.Desktop): Screenshot 2,
FileChooser 3, ScreenCast 5, Settings 2.
`org.freedesktop.portal.Access` NO EXISTE, y está bien: Access vive sólo
como org.freedesktop.impl.portal.Access, del lado del BACKEND — es como el
frontend le pide al escritorio que muestre el diálogo de permiso. Mi primer
sondeo la pidió al frontend y el «No such interface» era un error DEL
SONDEO, no del portal.
Del lado BACKEND (impl.portal.desktop.cosmic): Screenshot 2, ScreenCast 4,
Settings 2; Access y FileChooser devuelven UnknownProperty 'version'. Ese
error PRUEBA que la interfaz está: si faltara, D-Bus contestaría «No such
interface». UnknownProperty = la encontró y esa implementación no publica
esa propiedad.
Y el ListNames muestra impl.portal.desktop.cosmic ACTIVADO junto a
impl.portal.PermissionStore: el frontend levantó al backend por D-Bus
activation, que es el eslabón que habilita el .service con @libexecdir@
sustituido.
ALCANCE HONESTO: esto prueba DISPONIBILIDAD y ENRUTADO, no los flujos
completos. La única ejercida de punta a punta —con fichero en disco— sigue
siendo Screenshot.
Próximo: ejercer FileChooser desde una app que use el portal (cosmic-store
se compiló con la feature xdg-portal; cosmic-edit NO la usa, va con el
selector propio de cosmic-files como crate) y ScreenCast, que es la que
ejercita pipewire de verdad.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cosmic-screenshot corrido desde cosmic-term dentro de la VM devuelve una
ruta en vez del panic de ayer, y el fichero existe:
/root/Pictures/Screenshots/Screenshot_2026-08-05_10-18-14.png
-rw-r--r-- 1 root root 42256 Aug 5 10:18
0000000 211 P N G \r \n 032 \n ← firma PNG
El veredicto es el FICHERO, no el código de salida: que no panickee sólo
prueba que encontró el servicio; que haya 42 KB con \x89PNG prueba que el
compositor entregó píxeles por la cadena entera
(cliente → portal.Desktop → impl.portal.desktop.cosmic → cosmic-comp).
Cinco recetas: fuse3, json-glib (sin introspección), xdg-desktop-portal
1.18.4, clang18 y xdg-desktop-portal-cosmic. Dos raíces del perfil, porque
son dos PROCESOS que se encuentran por D-Bus y ningún [deps] los relaciona.
El runbook queda con las decisiones y sus precios (pin 1.18.4 por gstreamer,
el choque de gvdb y los dos caminos descartados por medición, de dónde sale
libclang) y con cuatro gotchas de andamiaje que costaron tiempo real:
· --offline SIN --locked cuando la receta parchea el manifiesto
· el worker NO puede construir la cola COSMIC (golden de 2026-07-15,
cola posterior ⇒ nada es cache-hit allá): «rootfs laptop ≠ worker»
pero con el STORE
· farm-down cosecha /opt/hammer/store y farm-up ancla el store en
/mnt/cosecha/store — directorios DISTINTOS, no symlink
· pipewire sin --wrap-mode=nodownload: ante una dep faltante intenta
bajarse un subproyecto y el error miente («This is a Meson bug»)
Próximo: las otras cuatro interfaces (FileChooser, ScreenCast, Settings,
Access). El andamiaje QMP ya está.
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>
Validado con pantalla: «Popular apps» poblada (App Library, Files,
Launcher, Settings), «Recently updated», y la búsqueda `text` devolviendo
COSMIC Text Editor. 2564 colores sobre un escritorio completo.
DOS TRAMPAS ENCADENADAS, y la primera invalida lo que dije al escribir la
receta:
1. El backend `pkgar` NO lee /usr/share/metainfo/*.metainfo.xml —los
ficheros que instala cada receta—. Lee el CATÁLOGO, o sea
{/usr/share,/var/lib,/var/cache}/{swcatalog,app-info}/{xml,yaml}/, que en
una distro normal genera `appstreamcli compose`. Sin ese fichero la
tienda abre perfecta y no lista NADA. Lo genera ahora
qemu-desktop-image.sh agregando los metainfo en un <components>: doce
líneas de python, cero AppStream y cero glib.
2. Con el catálogo puesto listaba 2 de 7. Los metainfo que genera `xdgen`
escriben <provides> con los envoltorios <mimetypes>/<binaries>, y el
crate `appstream` espera los hijos PLANOS del esquema de catálogo: muere
con «The tag provide doesn't have a value» y DESCARTA EL COMPONENTE
ENTERO, callado. Los dos que se veían eran justo los que no tienen
<provides>. Se elimina el bloque al agregar.
Cómo se diagnosticó, que es lo reutilizable: desde el lanzador la salida del
proceso no llega al log de la sesión. Hay que abrir cosmic-term DENTRO de la
VM y correr `rm -rf ~/.cache/cosmic-store; RUST_LOG=info cosmic-store`. El
rm no es opcional: la tienda cachea el parseo en bitcode y sin borrarlo
repite el resultado viejo.
Y el deadline del panel es una CARRERA, no un umbral: un arranque de esta
tanda salió mutilado (130 colores) con el anfitrión ocioso y -smp 8. Si sale
mutilado con carga baja, rearrancar antes de culpar al propio cambio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El editor abre desde el lanzador (Super → «text» → primer resultado) y se
ESCRIBE: la evidencia tiene `hammer edita` tecleado sobre la línea 1 y el
punto de modificado en la pestaña. 2105 colores, icono en el dock con el
punto de «en ejecución». Hidratación 72 recetas (era 71).
CORRECCIÓN al runbook, medida acá: decía «no es carga del anfitrión (falla
con el anfitrión ocioso)», cierto para 4 vCPU pero se leía como que con
`-smp 8` el anfitrión daba igual. Dos arranques de la MISMA imagen con la
MISMA línea de QEMU:
load ≈ 6 (otro agente compilando) → 130 colores, mutilado, `deadline has
elapsed` en el log
anfitrión ocioso (load ≈ 1,8) → 1671 colores, completo
Este anfitrión tiene 8 núcleos, así que `-smp 8` le da la máquina entera a
la VM y cualquier compilación compite por los mismos hilos. Receta: mirar
/proc/loadavg antes de creerle a un arranque mutilado.
También: con las cuatro aplicaciones en el dock el escritorio completo da
~1670 colores, no 894. El umbral útil es «cientos vs miles».
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>
De las recetas de incoming-cosmic que declaran link="static", ninguna tiene NEEDED
indebido ni los símbolos de stdio compartiendo dirección. Era un caso, no un patrón.
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>
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>
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>
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>
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>
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>
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>
Sergio
sergioandClaude Opus 5