=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>
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>
`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>
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>
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>
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>
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>
accounts-daemon y upowerd morían al arrancar: el shim de polkit se lanza en
background y tarda ~2s en adquirir org.freedesktop.PolicyKit1, ellos llamaban a
polkit_authority_get_sync() en ese hueco, D-Bus intentaba ACTIVAR el servicio y
fallaba con 'Failed to execute program ... Permission denied'.
Lo peor era el informe: los tres esperar_nombre estaban al final, así que para
cuando corrían el shim ya tenía el nombre y el resumen daba 'PolicyKit1 OK'
sobre dos clientes ya muertos. Un chequeo posterior a la carrera no la mide.
esperar_nombre pasa a definirse antes del primer daemon y el bloque de polkit
espera su propio nombre antes de que arranque ningún cliente suyo. Lanzar en
orden no es estar listo en orden.
De paso queda cerrado el ítem 4 del runbook: validación CON PANTALLA (DISP=gtk)
del Overview con el PID1 sellado nuevo — 689 colores distintos, con evidencia.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Las 4 imágenes de escritorio (GNOME + los 3 de KDE: qemu, metal, dual) fundían `work/metal-rootfs`
por hardlinks y se llevaban SU arje-zero, que era del 2026-06-19: ese directorio se armó a mano en
la campaña de metal y nadie lo regeneraba al re-sellar la receta. Resultado: todas arrancaban con un
PID1 de hace mes y medio, en silencio.
No es hipotético — se comió un fix real. El `identity mismatch` del bus del fractal estaba arreglado
río arriba y la VM seguía imprimiendo el mensaje viejo porque el binario de la imagen no venía de la
receta (ver el comentario de recipes/arje-zero.toml).
El síntoma engaña porque el directorio base es LEGÍTIMO para todo lo demás —busybox, firmware, el
kernel EFI-stub, la estructura de /etc—: sólo la pieza que TAMBIÉN es receta se queda atrás, y justo
esa es PID1. La regla que queda escrita en el helper: si algo del rootfs tiene receta, la imagen lo
toma del artefacto sellado, no de la copia congelada.
El helper va en scripts/lib/ y no inline ×4 a propósito: el porqué es largo y vale una sola copia.
Elige el artefacto por `hammer hash` (el de la receta de HOY, no el más nuevo por fecha, que miente
en cuanto conviven dos) y ABORTA si falta, porque seguir con el PID1 congelado es exactamente el
modo de falla que cierra.
Probado: las 4 pasan `bash -n` y la imagen GNOME lo ejecuta bien sourceado (`✓ e570c1482432 (el de
work/metal-rootfs era de 2026-06-19)`), con la VM ya validada booteando ese PID1.
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 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>
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>
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>
Rsvg-2.0 librsvg b3:351f4658
IBus-1.0 ibus b3:d4d3750a
**1. PERILLA NUEVA DEL LAB: `[source] cargo_vendor`.** `detect_build_system` asume UN
sistema de build por árbol, y librsvg genuinamente tiene dos: `configure.ac` gana por
precedencia pero su Makefile llama a `cargo build`, que dentro del sandbox hermético
no tiene red. La perilla fuerza el vendoreo (que ocurre en el fetch, donde sí hay red)
sin tocar la detección. **No entra al ArtifactHash** —decide de dónde salen las deps,
no cuáles: eso lo fija el Cargo.lock, ya bajo el sha256 de la fuente— así que se puede
prender en una receta ya sellada sin re-hashear nada. Con test, y verificado en vivo:
libelogind no movió su hash tras el cambio.
**2. LA DEUDA DEL UNWINDER, PAGADA.** librsvg moría en
`undefined reference: _Unwind_DeleteException`. No es de librsvg: es de la `std` de
rustc, que trae landing pads y espera el runtime que en glibc vive en libgcc_s. Es la
deuda que el corpus arrastra desde matar-gcc —«las 12 recetas Rust son UN problema, no
12»— y el remedio estaba a mano: **zig empaqueta la libunwind de LLVM** y exporta los
`_Unwind_*` (verificado con nm). Alcanza `LIBS=-lunwind`. Va por LIBS y no por LDFLAGS
porque autotools pone LIBS al FINAL de la línea de enlace, que es donde tiene que ir
una librería que resuelve símbolos indefinidos.
librsvg va en 2.58.5 y no 2.59+: en 2.59 cambió a meson + cargo-c, y cargo-cbuild
enlaza el crate `cargo` entero (libgit2, libssh2, libcurl, openssl) — una campaña
propia por un binario que sólo corre en el constructor. 2.58.5 produce el mismo
Rsvg-2.0. Mismo criterio que gnome-desktop 44.5.
**3. `x11-compose-data`, y es una tensión que vale la pena tener escrita.** ibus COMPILA
la tabla de teclas muertas de X11 dentro de libibus (Makefile.am:310, incondicional, sin
`--disable-`). Sin datos no construye. Los datos viven en el tarball de libX11 por
historia, no por necesidad técnica: son 5192 líneas de reglas. La receta extrae SÓLO los
ficheros de locale reproduciendo la regla de upstream (`cpprules.in`: cpp crudo +
CPP_SED_MAGIC literal) y no compila una línea de X11. Un escritorio Wayland-only sigue
necesitando la tabla de composición del mundo Unix.
Gotchas de ibus, los tres medidos: su ayuda MIENTE (`--enable-gtk4`/`--enable-wayland`
sugieren default apagado; el default es `yes`); `--disable-emoji-dict` NO apaga
`--disable-unicode-dict`; y con `--disable-wayland` el build muere igual porque
`tools/main.c` llama wl_display_* sin `#ifdef` mientras WAYLAND_LIBS sólo se agrega si
la opción está prendida — bug de upstream en su propia configuración sin Wayland.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dos rondas del mismo patrón, las dos destapadas ARRANCANDO:
1. `Requiring Gdk 4.0: Typelib 'cairo' 1.0 not found` ⇒ cairo-1.0 sumado a
gi-foreign-typelibs. Necesita el mismo sed que gi-foreign-girs (viene como .gir.in
con dos placeholders), para compilar EXACTAMENTE el XML que está instalado: si
divergieran, el typelib describiría otra librería. NO segfaultea g-ir-compiler — el
crash que motivó -Dbuild_introspection_data=false era del g-i de antes de la isla
dinámica. La lista de cinco no se adivinó: sale de leer los <include> de TODOS los
.gir del cierre y cruzarlos contra los typelibs existentes.
2. `Requiring Gdm 1.0` ⇒ receta `libgdm`, SÓLO la librería cliente. gnome-shell la
importa sin condicional (js/misc/dependencies.js:12), o sea que **la librería
cliente de GDM es dep de runtime del SHELL, no del greeter** — y eso no se ve en
ningún meson.build. `gdm.toml` (el demonio entero) sigue aparcada por linux-pam,
pero PAM es del DEMONIO: libgdm/ no lo toca. La receta corta por ahí; cuando exista
linux-pam las dos conviven.
Para que libgdm compilara hicieron falta tres símbolos más en libelogind
(tawasuyu 9bf977a52, re-pineado a 98db584fd, re-sellado b3:c1fc4bd8):
sd_seat_get_sessions, sd_session_get_service y **sd_booted**, éste en una cabecera
nueva systemd/sd-daemon.h. sd_booted NO es un stub que devuelve 0: comprueba lo mismo
que systemd —que exista /run/systemd/system/— y bajo arje no está, así que responde 0
porque ES 0.
gnome-shell re-sellado b3:b2d5919b por la cascada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Con accountsservice adentro, la capa JS avanzó y murió un paso después:
JS ERROR: Requiring Atspi, version 2.0: Typelib file for namespace 'DBus', version '1.0' not found
`Atspi-2.0.gir` declara `<include name="DBus" version="1.0"/>`. El `DBus-1.0.gir` YA estaba en
/usr/share/gir-1.0 (lo pone gi-foreign-girs), pero gjs resuelve en runtime contra el TYPELIB
compilado, no contra el XML — el XML le alcanza al scanner, no al cargador.
Receta aparte y no un compile agregado a gi-foreign-girs porque `yupana radio` da **17 sellados
cayendo a deuda** ahí (catorce recetas la declaran para escanear, mutter y gnome-shell entre ellas).
Compilar cuatro typelibs no justifica reconstruir la cima. No se pisan: una instala sólo en gir-1.0
y la otra sólo en girepository-1.0. Mismo criterio que separó udev-pc de libudev-zero.
Se compilan CUATRO nombrados explícitamente —DBus-1.0, DBusGLib-1.0, fontconfig-2.0, freetype2-2.0—
y no un glob: los .gir de X11 y cairo arrastran includes que no tenemos y son justamente los que
hacían SIGSEGV a g-ir-compiler (la razón de nuestro -Dbuild_introspection_data=false).
Además: gnome-start lanza accounts-daemon explícito. Su .service de activación está instalado, pero
la activación por bus de sistema pasa por dbus-daemon-launch-helper, que acá no es setuid root;
correr como root probablemente alcanzaría, pero depender de eso es depender de un accidente.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los dos huecos que bloqueaban esta receta estaban medidos desde ayer símbolo por
símbolo, y ninguno era de accountsservice. Los dos cerrados:
1. libelogind pasa de 14 a 22 símbolos (tawasuyu 8d892151b, re-pineado a b56aeff46,
re-sellado b3:9650ee06). Los ocho nuevos son los que usa accountsservice, con
`sd_login_monitor_*` implementado sobre inotify en /run/systemd/{sessions,seats,users}.
2. `fgetspent_r` no existe en musl ⇒ accountsservice-fgetspent_r-musl.patch. NO es
sustituir por `fgetspent()` a secas: daemon.c guarda los buffers en un GHashTable
y `fgetspent()` devuelve un struct estático que se reescribe en cada llamada —
todas las entradas de la tabla apuntarían al último usuario leído. El parche copia
el registro al buffer del llamador, y sigue el patrón que el propio accountsservice
ya usa para /etc/passwd (`src/fgetpwent.c` bajo `#ifndef HAVE_FGETPWENT`).
Produce `AccountsService-1.0.typelib`, que es exactamente lo que la capa JS pedía.
De paso, dos cosas que este frente enseñó y quedan horneadas:
- libelogind necesitaba `cargo_vendor_dir` (el `vendor/` de smithay entró a la rama
selfhost con el merge de main; el mismo choque que ya tenía arje-logind-compat).
- `hydrate-gnome.sh` ahora hidrata DOS raíces por defecto. accountsservice no es dep
de build de nadie: es dep de RUNTIME, resuelta por gjs al arrancar. **El cierre de
build no es el cierre de runtime**, y lo que el shell carga por `imports.gi.*` hay
que nombrarlo a mano o no entra al rootfs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tres cambios de diagnóstico en `gnome-start` que, juntos, dieron el veredicto:
1. SONDA DE INPUT antes de lanzar el shell. `libinput list-devices` hace lo mismo
que `init_libinput()` de mutter (udev_new + create_context + assign_seat) pero
abriendo el devnode por su cuenta. Volvió con rc=0 y los tres dispositivos
listados ⇒ **la hipótesis libudev-zero del runbook queda REFUTADA**: la
enumeración por /sys funciona.
2. El volcado POR HILO corría DESPUÉS del `kill -ABRT`, o sea sobre un
/proc/<pid>/task que ya no existía: salía vacío. Movido antes. Ahí apareció el
dato: `tid 201 [Mutter Input Th] wchan=evdev_read syscall=0`. El hilo de input
dormido en un `read()` de evdev dentro del kernel. (El core no servía: gdb no
desenrolla a través de musl y devuelve `?? ()` para los 11 hilos no principales.)
3. `MUTTER_DEBUG` es una LISTA DE TÓPICOS (g_parse_debug_string sobre
meta_debug_keys), no un booleano: con `1` no encendía nada. Ahora
`backend,input,kms`, y el tópico `backend` imprime la última línea antes del
cuelgue: «Opening and taking control of device file '/dev/input/event0'».
Más: ping D-Bus a login1 en el diagnóstico (el daemon respondía: no estaba
tildado) y copia de los logs de /tmp —que es tmpfs— a la raíz ext4 para poder
sacarlos con debugfs junto al core.
La causa está arreglada en tawasuyu (3dd88f582): `TakeDevice` abría sin
`O_NONBLOCK`. Receta re-pineada a 2445fa31c y re-sellada b3:7ffa9256.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Los dos arreglos de arje-logind-compat (sesión eager + object path de Session
escapado como systemd) están commiteados y pusheados en tawasuyu, así que la
imagen ya NO corre un binario compilado a mano: corre el artefacto sellado, y se
verificó que da EXACTAMENTE el mismo resultado (mismo `Added virtual monitor
Meta-0` → `Using Wayland display name 'wayland-0'` → mismo muro en el typelib de
AccountsService).
El pin va a la rama selfhost, no a main: esa rama existe para que hammer pueda
construir con --locked de forma hermética (el monorepo gitignora el Cargo.lock).
Estaba MUY atrás — el artefacto viejo ni siquiera tenía el objeto Session que
mutter necesita —, así que se le mergeó main y se regeneró el Cargo.lock, que con
main al día había quedado viejo y habría hecho fallar el --locked.
Y ahí apareció una colisión ya conocida pero no aplicada acá: el monorepo COMMITEA
su propio `vendor/` (`[patch.crates-io] smithay = { path = "vendor/smithay" }`, la
copia parcheada que mirada usa para el tearing) y `cargo vendor` de hammer escribe
en `vendor/` por defecto, pisándolo. El build moría con
`failed to read /src/vendor/smithay/.cargo-checksum.json`. Se resuelve con el
campo que ya existía para esto: cargo_vendor_dir = ".hammer-cargo-vendor".
De paso, el script de imagen elige el artefacto por `hammer hash` sobre la receta
—el que corresponde a la receta de HOY— en vez de por el más reciente del store:
con dos artefactos del mismo paquete conviviendo, la fecha no dice cuál es el
vigente. Mismo criterio que hydrate-gnome.sh.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Experimento decisivo: `gnome-shell --headless --virtual-monitor 1280x800`. El
backend headless crea el seat con META_SEAT_NATIVE_FLAG_NO_LIBINPUT, o sea que
saltea init_libinput() — justo el último paso del hilo de input antes de señalar
`input_thread_initialized` (meta-seat-impl.c:3098). Resultado:
libmutter-Message: Added virtual monitor Meta-0
libmutter-Message: Using Wayland display name 'wayland-0'
== compositor OK (wayland-0) — el shell ES el display server
⇒ **CONFIRMADO: el bloqueo del camino DRM está en libinput/udev, no en el resto
del arranque.** Todo lo demás de mutter funciona. Primer sospechoso libudev-zero.
Y con el compositor arriba aparece el muro siguiente, que es de otra naturaleza:
Gjs-CRITICAL: JS ERROR: Requiring AccountsService, version 1.0:
Typelib file for namespace 'AccountsService' not found
LA LECCIÓN DE MÉTODO: gnome-shell selló con su cierre de build COMPLETO (108/108)
y aun así la sesión muere pidiendo este typelib. **El cierre de build no es el
cierre de runtime**: todo lo que el shell carga por `imports.gi.*` desde
JavaScript es invisible al grafo de deps. Se encuentra ARRANCANDO, no compilando.
Se autoró recipes/incoming-gnome/accountsservice.toml. El configure pasa entero
—tres seds verificados contra el build real: generate-version.sh (deriva la
versión del nombre del DIRECTORIO, que en el sandbox es /src, y la rama git usa
`date`, o sea no-determinista), la aserción de wtmp (musl no define WTMPX_FILENAME
ni _PATH_WTMPX) y subdir('tests') (arrastra mocklibc, que llama fgetgrent, ausente
en musl)—. Ojo: -Dsystemdsystemunitdir tiene que ser literalmente `no`; con la
cadena vacía el meson interpreta "averiguá el directorio" y aserta pidiendo
systemd.pc.
NO SELLA todavía, y la frontera está contada símbolo por símbolo, no estimada:
· libelogind exporta 14 símbolos (los que pedía mutter) y accountsservice usa
OCHO que faltan: sd_get_sessions, sd_seat_can_multi_session,
sd_session_get_display y los cinco de sd_login_monitor_*. Estos últimos son
la parte con enjundia: no son getters sino una API de NOTIFICACIÓN (un fd
poll-able). Sobre el diseño actual el camino natural es inotify sobre
/run/systemd/{sessions,seats,users}.
· fgetspent_r no existe en musl (extensión glibc de /etc/shadow, usada en
src/daemon.c:265): necesita shim o parche a la variante no-reentrante.
Ninguno de los dos es de accountsservice: son huecos de NUESTRA capa de compat.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Dos bugs REALES de arje-logind-compat, encontrados arrancando la imagen y
arreglados (con test) en el árbol de tawasuyu — todavía LOCALES, sin pushear:
1. La sesión se creaba PEREZOSAMENTE. `ensure_user` sólo corría dentro de un
método del Manager, y `write_login_state` vive adentro. Pero mutter no
empieza por D-Bus: lo primero que hace es sd_pid_get_session(), que
arje-sdlogin-compat resuelve LEYENDO /run/systemd/sessions. Huevo y gallina:
el estado en disco sólo se escribía después de un pedido que sólo ocurre si
el estado ya existe. Ahora se crea al arrancar (eager_session).
2. El object path de la Session estaba MAL ESCAPADO: era `/session/_1`. La
convención de systemd (bus_label_escape) codifica `_<hex>` todo lo que no sea
[A-Za-z0-9] **y también el primer carácter si es dígito** ⇒ el id "1" da
`_31`. Importa porque el cliente calcula el path por su cuenta y NO pregunta:
mutter reimplementa la misma regla en meta-dbus-utils.c. Con `_1` no había
nadie sirviendo ahí, la propiedad `Seat` volvía NULL y mutter —que no
chequea— moría de SIGSEGV en get_seat_proxy. Los objetos User NO usan este
escapado (systemd hardcodea `_<uid>`), así que user_path() queda igual.
Y ARJE_LOGIN_STATE=1 YA EXISTÍA: el comentario del daemon dice literalmente "en
arje (sin systemd) el launcher de sesión lo prende. Default off" — y el launcher
es gnome-start. El puente que escribía /run/systemd/ a mano era reinventar esa
perilla; queda de fallback inerte.
Resultado: el shell ya no crashea. Corre con 12 hilos, /dev/dri/card0 abierto
tres veces y /dev/input/event0 abierto — el TakeDevice de logind funciona y el
compositor tiene DRM master e input. Queda bloqueado en
meta_seat_impl_initable_init (meta-seat-impl.c:3154): espera en un condvar a que
la "Mutter Input Thread" avise que inicializó, y nunca avisa. Hipótesis principal
libudev-zero, que ya dio un episodio idéntico en el frente de la USB nvidia.
El gnome-start ahora le fuerza un core con SIGABRT al proceso colgado: sin gdb en
la imagen es la única forma de ver dónde está parado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnome-shell bootea, compila sus esquemas, toma el DRM de virtio-gpu y se declara
Wayland display server. Después SIGSEGV. El backtrace del core no deja dudas:
#4 g_variant_get (value=0x0, "(s&o)") ← GVariant NULO
#5 get_seat_proxy src/backends/meta-launcher.c:407
#6 meta_launcher_new (META_LAUNCHER_FLAG_TAKE_CONTROL)
Mutter pide la propiedad `Seat` del objeto **Session** de logind — `(s&o)` es su
firma estándar (nombre_del_seat, object_path). arje-logind-compat adquiere
org.freedesktop.login1 y sirve el Manager, pero NO expone un objeto Session con
esa propiedad ⇒ la lectura devuelve NULL y mutter desreferencia sin chequear. Que
mutter no valide es fragilidad suya; el hueco es nuestro.
Cinco eslabones hubo que armar antes de llegar a ese muro, ninguno anotado:
1. gschemas.compiled NO se genera con DESTDIR seteado (meson lo dice en el log
del build) ⇒ GSettings abortaba en el primer g_settings_new().
2. GI_TYPELIB_PATH tiene que incluir /usr/lib/gnome-shell: St/Shell/Gvc/Shew se
instalan aparte por ser privados del shell. Es el env sin análogo en KDE.
3. /var/run no existía en la base metal; arje-logind-compat busca el bus en la
ruta legacy y sin el symlink se iba a "modo idle".
4. La política D-Bus de login1 faltaba (system.conf trae <deny own="*"/> y
normalmente la instala systemd). PERTENECE al artefacto de arje: está en el
script de imagen sólo para dejar visible qué falta empaquetar.
5. /run/systemd/{sessions,seats,users} vacíos — libelogind resuelve la C-ABI
sd-login LEYÉNDOLOS y nadie los escribe (el Announce de arje-logind-compat al
bus del fractal falla con "identity mismatch"). gnome-start los escribe A
MANO y está MARCADO COMO ANDAMIO. Con ese puente desaparece el "Failed to
find any matching session".
Gotcha que costó una iteración: `kill -0` TIENE ÉXITO sobre un zombi (el padre no
lo cosechó todavía), así que el script reportaba "sin wayland-0 tras 45s" cuando
el shell había muerto en el primer segundo. Mirando State: de /proc/<pid>/status
sale el código real, 139.
Todo el ciclo (hidratar → imagen → bootear → sacar el core con debugfs → gdb) y
la lista de lo que falta quedan en docs/runbooks/gnome-qemu-desktop.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Proyecta al FHS el cierre de una receta GNOME desde artefactos SELLADOS, sin
rebuild. Resultado sobre gnome-shell: **108 recetas, 0 faltantes** — 614
binarios, 455 .so, 49 typelibs.
Diferencia con scripts/kde/hydrate-from-store.sh, y por qué importa: aquél
resuelve el cierre desde un index.json de repo y elige el artefacto por MTIME con
un CUTOFF. Eso es una heurística — si dos artefactos del mismo paquete conviven
en el store, la fecha no dice cuál corresponde a la receta VIGENTE. Acá el cierre
sale del GRAFO REAL de recetas (deps.build, resolución hermano→padre, la misma
que usa hammer) y el artefacto se elige por `hammer hash`. Cero ambigüedad, y si
falta algo el reporte dice qué receta y con qué hash lo buscaba.
Auditado además el cierre DINÁMICO del rootfs (452 ELF, 104 librerías NEEDED).
Sin resolver quedan cuatro, y sólo dos son hallazgos:
libc.so 359 consumidores — es el propio musl (en musl el loader
ES libc); lo aporta la base metal, no es hueco.
libc.musl-x86_64.so.1 17 artefactos (nss + spidermonkey) piden ESTE soname en
vez de libc.so. Es la MISMA libc: los construidos con el
gcc/clang de Alpine emiten un soname distinto al de
zig-cc. No rompe si el rootfs trae los dos nombres, pero
es una fisura de consistencia a documentar.
libstdc++.so.6 + SÓLO libmozjs-128.so y js128 ⇒ **la sesión GNOME arrastra
libgcc_s.so.1 el runtime C++ de Alpine por la cadena
gnome-shell → libgjs → libmozjs**. Es exactamente la
"última milla" de matar-gcc que se cerró para cmake con
-static-libstdc++ y que spidermonkey no cubrió. Radio
medido: 2 sellados (gjs, gnome-shell). Pendiente, y
conviene en el worker: el compile de mozjs come ~8GB+.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Las 3 fronteras que el propio comentario de gnome-desktop declaraba:
iso-codes receta nueva (datos + .pc). Ya no está en download.gnome.org (404);
Salsa es GitLab y su archive no es determinista (lección de cairo-shared),
así que la fuente es el .orig.tar.xz inmutable del pool de Debian.
Sin traducciones: i18n.gettext exige msgfmt completo y sólo hay
gettext-tiny — se vacían los 8 meson.build de dominio.
libseccomp receta nueva (autotools estático, gperf de build-dep real).
xkeyboard-config duplicada desde incoming-kde: fichero idéntico ⇒ MISMO ArtifactHash
(b3:bcf9b766) ⇒ ya está SELLADO. Frontera cerrada con cero rebuild.
Y un punto ciego del latido: cosecha-cron regeneraba build-state.json y el de KDE, pero
NUNCA el de GNOME. El grafo llevaba días mintiendo `never` sobre gobject-introspection y
toda la onda 2, que están selladas. Un grafo viejo miente con la misma cara que uno fresco.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Las 3 raíces de la onda 1 (gsettings-desktop-schemas, gobject-introspection,
gnome-desktop) copiadas a una cola propia + añadida al QUEUES del worker-loop.
Aislar evita que el worker dispare rebuilds de spidermonkey/mutter (onda 2/3).
El cierre real de RECETAS de las 3 es 39 nodos, 0 en incoming-kde: el "gap del
resolver" que temía era de seed-edges (.pc cairo→libX11), NO de deps declaradas.
El espinazo corpus (38 nodos: gtk4/cairo/pango/gdk-pixbuf en recipes/) está 100%
sellado ⇒ el worker cachea todo e sólo construye las 3. Hashes byte-idénticos a
los sellos de incoming-gnome (base_dir no entra al hash).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
drenar --perfil escritorio-gnome erraba 'no encontré un grafo (¿corriste
build-state.py?)' — mentira: el grafo GNOME existe, pero NINGUNA raíz del perfil
(mutter/gnome-shell/gdm) está autorada ⇒ 0 nodos etiquetados con el perfil, y la
comprobación por etiqueta en cargar() fallaba. Dos correcciones:
· cargar(): una cola NO-corpus identifica su grafo unívocamente ⇒ matchear por
cola; la etiqueta sólo desambigua dentro de corpus (perfiles solapados).
· main(): ámbito vacío con perfil ≠ 'imagen completa' — es 'SIN CIERRE todavía:
0 raíces autoradas', y apunta a autorar top-down.
KDE (162 sellados) y corpus (769/4-deuda) sin regresión. El yupana-gnome queda
armado en las 4 capas: objetivo, radio/grafo, keystones y drenar.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El motor JS de Mozilla, keystone del frente GNOME (gjs→gnome-shell cuelgan de él),
sella b3:c48dbd10: libmozjs-128.so + libjs_static.a + shell js128 + mozjs-128.pc +
550 headers. Compiló el C++ entero a -O3 -j8 sin OOM en el hub (31GB/0 swap, al filo).
Seis capas iteradas desde el borrador:
1-2. FIX DE INFRA: el rootfs builder tenía clang pero NO el paquete (Alpine
separa los binutils LLVM del compilador). Sin llvm-ar/llvm-objdump/llvm-profdata
configure aborta. bootstrap-devfs.sh: +llvm22 en NEEDED + paso 3a-ter que
symlinkea la suite llvm-* a /usr/bin (Alpine la deja en /usr/lib/llvm22/bin sin
exponerla). Aplicado ya al rootfs real (.dev-fs/alpine).
3. triple: mozjs no traduce vendor ; 4. debe COINCIDIR con el host de rustc
(); fijado ese exacto.
5. venv de mach: cada fase es un bwrap con /tmp fresco ⇒ el venv no sobrevivía de
configure a compile. Anclado a /src/.mozbuild (persiste, es scratch).
No re-hashea artefactos (el rootfs no entra al hash). OJO: el worker golden también
necesita llvm22 (ya cubierto por bootstrap-devfs.sh para la próxima provisión).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
build-state.py gana --gnome (análogo a --kde): carga recipes/incoming-gnome/ y sale
a build-state-gnome.json. drenar/yupana/seed-graph aprenden ese grafo (keystones,
drenar --perfil escritorio-gnome, radio de nodos incoming-gnome, frontera). Hoy la
cola está vacía ⇒ el grafo trae 0 nodos gnome; se poblará al aterrizar recetas y ahí
drenar/keystones reckonan solos.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1. targets.toml: [perfil.escritorio-gnome] (9 raíces de sesión, cola incoming-gnome)
⇒ `yupana objetivo` ya lo ve; fluye por targets.py. build-state lo SALTA hasta
que la cola se cargue (--gnome), así declararlo no reporta raíces fantasma.
2. seed-gnome.py OPTIMIZADO: hornea la triage (sustitución/tooling/opcional/espinazo)
como HIPÓTESIS con el caveat "el cierre de nixpkgs sobreestima ~5-10×", marca el
keystone (spidermonkey→gjs→gnome-shell), y deja de mentir con el 465 crudo. El
espinazo (353) se reporta como COTA ALTA, no como lista de build.
Falta (se activa al autorar): grafo build-state-gnome + flag --gnome ⇒ keystones/
drenar nativos sobre GNOME. Hoy la capa OBJETIVO del yupana-gnome está; la GRAFO no.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El loop del worker está SIEMPRE vivo (idle-loopea con la cola vacía). Contarlo
en hay_trabajo() reseteaba los ticks a 0 cada 10 min ⇒ el worker NUNCA acumulaba
idle ⇒ NUNCA se auto-mataba. Quedó 2h17m idle quemando € (2ª vez).
El loop construyendo YA se detecta por su hijo `hammer build`; el loop vacío NO
es trabajo. Se afina el match a `release/hammer.* build ` y se suma `campana-deuda`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cazado con el 1er worker real: el token vive en /etc/hammer-deadman.env (lo carga
systemd como EnvironmentFile), pero corrido A MANO (farm-up --puede-borrar) ese
fichero no se lee solo ⇒ mi cadena de fallback no lo veía ⇒ decía 'sin token' y
farm-up habría DESTRUIDO un worker que sí puede matarse. Fix: sourcear el
EnvironmentFile antes de la cadena de tokens desnudos. Verificado en worker real:
'SÍ: puedo borrar mi id=154276696'.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El worker DEBE matarse solo, sin depender de la laptop (es la razón de ser del
dead-man: vive en el worker; el volumen hace que morir no pierda nada). El reaper
del hub queda sólo como último recurso. El dead-man estaba TRIPLEMENTE roto:
1. TOKEN EN EL FICHERO EQUIVOCADO: hay 2 caminos de creación con el token en
lugares distintos (farm-up → /etc/hammer-deadman.env; harkaq-vol → /root/
.hcloud-token). La service lee sólo el primero ⇒ un worker del otro camino
quedaba sin token, disparaba pero salía 1 "sin HCLOUD_TOKEN". Fix: deadman.sh
busca el token EN CADENA (volumen primero, que es lo más persistente).
2. REGEX DEL ID ROTO: la API devuelve JSON con espacio ("id": 126, no "id":126)
y el dead-man usaba '"id":[0-9]+' ⇒ NUNCA resolvía su id, aun con token
válido. Fix: '"id":[[:space:]]*[0-9]+'. (Doblemente roto: por eso NUNCA murió.)
3. FIRING ≠ CAN-DELETE: farm-up sólo verificaba que el timer dispara. Ahora
corre `deadman.sh --puede-borrar` (token en cadena + ve su id en la API) y si
NO puede matarse, DESTRUYE el worker ahí mismo. Un worker que no se autodestruye
es inadmisible ⇒ jamás debe existir.
gioser DOBLE-BLINDADO en TODOS los sitios de borrado (lista negra por nombre +
label role=hammer-worker), igual que farm-down ya tenía: reaper, farm-up-destroy,
deadman, y el helper de harkaq-vol. "Ahí está nuestra vida." Verificado vivo (104d).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sin esto un server borrado se quedaba en .fleet para siempre (describe falla ⇒
'sin label' ⇒ nunca se dropeaba). Ahora si no existe en hcloud, se saca.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
INCIDENTE (2026-07-23): un worker quedó 3.5h idle quemando € mientras el usuario
dormía. El dead-man del worker estaba "activo" (timer disparando cada 10 min)
pero FALLABA con exit 1 en cada tick: llegaba a matarse pero su
/etc/hammer-deadman.env no tenía token válido ⇒ salía 1 "sin HCLOUD_TOKEN" y
nunca se borraba. Verificaron que el timer DISPARA, no que puede BORRAR —
firing ≠ can-delete.
Causa de fondo: la garantía dependía de que CADA worker se auto-provisione bien
un token, y eso falla EN SILENCIO. Un invariante que depende de una provisión
frágil no es un invariante.
FIX en dos capas (defensa en profundidad):
1. REAPER HUB-SIDE (cosecha-cron.sh): el hub tiene un token que funciona y el
latido corre cada 30 min aunque no haya sesión (setsid). Un worker sin trabajo
activo REAPER_MAX=2 ciclos (~1h) se BORRA desde el hub, con el MISMO blindaje
de label role=hammer-worker (gioser jamás pasa). Cubre "dead-man del worker
roto". El dead-man del worker sigue cubriendo "hub caído".
2. farm-up verifica CAN-DELETE, no sólo firing: que el token del worker vea su
propio id en la API (lo mismo que hace al morir). Si no puede, LO GRITA al
provisionar en vez de descubrirlo 3.5h tarde.
Acción inmediata tomada: worker borrado a mano (label verificado), €0 baseline
restaurado — sólo queda gioser (protegido, fijo). Todo estaba cosechado.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El grafo modela deps (R1: Receta×Receta). El entorno es OTRA capa: R2 (Receta×
Capacidad, qué exige un build) y R3 (Host×Capacidad, qué ofrece la máquina).
Construible = clausura(R1) ∧ R2⊆R3. Esos huecos viven FUERA del grafo (infra del
sandbox, toolchain, layout de fs) y una matemática de grafos sola no los ve —
pero SÍ se aprenden, como patrones con predictor, calibrados contra fallos reales.
`yupana preflight <receta>` corre los patrones ANTES de construir. Primer patrón:
overlay-lowerdir, la cicatriz de kio. Habría marcado kio antes de quemar la
campaña descubriéndolo a los golpes:
kio: 52 deps ⇒ lowerdir ~5346B > 4096B (una página) ⇒ depende del merge
CALIBRADO, no adivinado: el estimador daba corto (2974B "ok") hasta usar el
prefijo que bwrap VE en runtime (/oldroot/…, ruta del worker, no la del hub).
Con eso: kio estimado 5346B vs real 5315B — 31B de error, sin fudge. El primer
predictor "obvio" mentía con confianza; la lección de siempre.
preflight --perfil escritorio-kde destapa lo sistémico: las 40 recetas KDE
profundas CUELGAN del merge (plasma-desktop: 114 deps → 11708B, casi 3× el
límite). Todo el escritorio dependía del fix 6a0dc40. El pre-flight vuelve
VISIBLE y contable una fragilidad que antes sólo se manifestaba fallando.
Registro extensible (PATRONES_ENTORNO): futuros = capacidad-de-host (rootfs
laptop≠worker, techo MSRV — acumular observaciones), skew de toolchain (zig-skew
— fingerprint por artefacto). harkaq ya MIDE R2 (evidencia negativa); esto lo
vuelve consultable + pre-vuela. Guardián: kio marcado + estimador calibrado.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
merge_deps_layer funde las deps en UNA capa overlay por hardlinks (cp -al) para
no desbordar el lowerdir de overlayfs (tope ~4096B por página). Pero calculaba
la ruta del merge en deps.parent().parent() = <store>/../.dmerge, asumiendo que
el store está en <base>/store del MISMO fs. En el worker el store es un VOLUMEN
bind-montado (/opt/hammer/store en /dev/sdb, /opt/hammer en /dev/sda1) ⇒ el merge
caía en la raíz, cp -al fallaba cross-device, y el fallback apilaba las ~50 deps
de kio directo → lowerdir 5315B > 4096B → "bwrap: Can't make overlay mount" →
kio (EL keystone, gatea 36) imposible de construir. Por eso estaba clavado.
Fix de una línea: el merge va en el padre INMEDIATO de las deps (= el store
mismo), garantizado mismo fs. Confirmado en el worker: cp -al a /opt/hammer/.dmerge
falla "Invalid cross-device link"; a /opt/hammer/store/.dmerge funciona.
En el laptop andaba por casualidad (store y su padre en el mismo fs).
`.dmerge` (dot-prefix) es invisible para el store lookup/build-state como .times.
cosecha excluye /.dmerge del rsync (es scratch de hardlinks; sin -H rsync lo
expandiría a copias reales).
Descubierto levantando el worker para poblar tiempos: yupana keystones apuntó a
kio, la campaña falló ahí, y el radio de lowerdirs (5315B) destapó la causa. Una
"sorpresa de entorno" (infra del sandbox, fuera del grafo) que el frente de
timing sacó a la luz.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5