takana

1,368 Commits 1 Branch 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
SergioandClaude Opus 5	f7ce610eb9	wlr: el escritorio DIBUJA — arranque headless en 2 min y 5 piezas que el cierre no traía `scripts/wlr/sway-headless.sh` corre el perfil escritorio-sway dentro de un bwrap, sin QEMU, sin kernel y sin imagen de disco, y captura con grim. Evidencia: PNG 1280x720 con 383 colores —#242424 fondo de foot, #285577/#4c7899 bordes de sway, #d0d0d0 el texto. sway 1.10 / wlroots 0.18.2 / foot 1.27.0, todo del corpus. Sirve porque el ciclo de diagnóstico pasa de ~40 min (product-rootfs + imagen EFI + arranque) a ~2 min. No sustituye al arranque en QEMU: no prueba kernel, initramfs, DRM ni PID1. Prueba lo que el arranque en VM tapa detrás de una pantalla negra. LO QUE SE MIDIÓ, y es lo que importa: el perfil da 121/121 y aun así NO arranca solo. Faltan cinco cosas, ninguna en la clausura: · libz.so.1 / libexpat.so.1 / libffi.so.8 — sway salió DINÁMICO y el corpus sólo produce `.a`. Sin ellas ni arranca. libz existe como artefacto `zlib-shared`; las otras dos hoy sólo están en `.dev-fs/alpine`, o sea que el escritorio depende del rootfs del lab. · xkeyboard-config y dejavu-fonts — HAY receta de las dos, en incoming-{kde,gnome,cosmic}. En la cola de wlr no, así que el perfil no las alcanza. Un escritorio sin una sola fuente. · /etc/passwd y /etc/fonts/fonts.conf. Y bash NO CORRE: enlazado dinámico contra ncurses, del que sólo hay `libncurses.a` ⇒ «Error relocating /bin/bash: tgetent: symbol not found». El modo de fallo vale más que la lista. Nada de esto se vio como un error: `foot` abría, sway registraba «New xdg_shell toplevel» —la ventana EXISTÍA en el árbol— y la captura salía con UN SOLO COLOR. El shell moría al instante y la ventana se cerraba antes del frame. Log entero en verde, pantalla vacía. Por eso la evidencia es contar colores del PNG y nunca leer el log: 1 color = sólo swaybg, ningún cliente dibujó. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o	2026-08-26 17:09:04 +00:00
sergioandClaude Opus 5	e3403ff20e	sway ARRANCA EN QEMU con pantalla — evidencia, y seis muros que el grafo no podía ver `docs/evidencia/sway-qemu-2026-08-08.png`: 1280×800, 102 colores distintos, sway con foot a pantalla completa y un prompt vivo, la barra de título del compositor arriba y el fondo #1a4b8c asomando en los bordes. Sobre el kernel de hammer con arje-zero como PID1, sin X11 y sin systemd. EL VEREDICTO ES CONTAR COLORES, NO LEER EL LOG — y esta campaña lo demuestra sola: hubo un arranque con TODO verde en el log (salida activada, modo 1280x800, «Commit of 1 outputs succeeded», workspace creado) y la captura salía 100% negra. Un compositor puede estar perfectamente vivo y no pintar nada. LOS SEIS MUROS, ninguno visible en un grafo de dependencias que decía 121/121: 1. `PATH` vacío — el console-getty no lo exporta y ni `mkdir` se encontraba. «mkdir: not found» se lee como «falta busybox» cuando busybox está entero: mismo engaño que el exit 127 de meson. 2. `libz.so.1` AUSENTE del rootfs. El zlib del corpus es sólo estático; la compartida vive en `zlib-shared`, en otra cola. Se cazó comparando los NEEDED del ELF contra el rootfs, no leyendo logs. 3. `LIBSEAT_BACKEND=builtin` NO EXISTE en nuestro libseat: `recipes/seatd.toml` construye con `-Dlibseat-seatd=enabled -Dlibseat-logind=disabled`, o sea UN backend, confirmado con `strings`. La receta manda sobre lo que uno cree recordar del proyecto — y la misma receta traía la salida: `-Dserver=enabled` construye `seatd-launch`. 4. `/run` de SÓLO LECTURA. La raíz de hammer es inmutable por diseño, y sway moría con «unable to open lockfile … check permissions», que suena a permisos de directorio y era un filesystem read-only. Se resolvió montando un tmpfs, que es lo que hace cualquier init. 5. `xkeyboard-config` — «failed to add default include path /usr/share/X11/xkb». Es EXACTAMENTE lo que dejé anotado en la receta de swaylock: «para que el teclado tenga distribución en una imagen real hará falta incluirlo por el lado del perfil». Apareció donde se dijo. 6. SIN TIPOGRAFÍAS no hay terminal. `fcft: failed to match font` → `failed to load primary fonts`: foot arrancaba y no dibujaba. `dejavu-fonts` estaba en el catálogo pero en otra cola. Va en la lista de §I.5 del SDD 20 («tipografías») y acá se ve por qué no es un detalle. Y un fallo de MÉTODO que costó dos ciclos: mandé el log de sway a /var/log/sway.log DENTRO de la VM, así que la primera captura negra vino sin una sola línea que la explicara — el diagnóstico estaba dentro de la caja que no arranca. Un log que no se puede leer desde fuera no es un log. Ahora va al serial. Los `exec` de la config de sway disparan ANTES de que exista el workspace (0,259 s vs 0,305 s) y mueren con «Failed to create launch context. No workspace». Los clientes se lanzan desde sway-start esperando el socket de Wayland, que es la condición real. Andamiaje reutilizable en scripts/wlr/: qemu-sway-image.sh (hermano del de COSMIC, sin logind ni dbus, que sway no necesita), sway-start.sh y sway-config. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-07 22:38:51 -04:00

Author

SHA1

Message

Date

SergioandClaude Opus 5

f7ce610eb9

wlr: el escritorio DIBUJA — arranque headless en 2 min y 5 piezas que el cierre no traía

`scripts/wlr/sway-headless.sh` corre el perfil escritorio-sway dentro de un bwrap, sin QEMU, sin
kernel y sin imagen de disco, y captura con grim. Evidencia: PNG 1280x720 con 383 colores —#242424
fondo de foot, #285577/#4c7899 bordes de sway, #d0d0d0 el texto. sway 1.10 / wlroots 0.18.2 /
foot 1.27.0, todo del corpus.

Sirve porque el ciclo de diagnóstico pasa de ~40 min (product-rootfs + imagen EFI + arranque) a ~2
min. No sustituye al arranque en QEMU: no prueba kernel, initramfs, DRM ni PID1. Prueba lo que el
arranque en VM tapa detrás de una pantalla negra.

LO QUE SE MIDIÓ, y es lo que importa: el perfil da 121/121 y aun así NO arranca solo. Faltan cinco
cosas, ninguna en la clausura:
  · libz.so.1 / libexpat.so.1 / libffi.so.8 — sway salió DINÁMICO y el corpus sólo produce `.a`.
    Sin ellas ni arranca. libz existe como artefacto `zlib-shared`; las otras dos hoy sólo están en
    `.dev-fs/alpine`, o sea que el escritorio depende del rootfs del lab.
  · xkeyboard-config y dejavu-fonts — HAY receta de las dos, en incoming-{kde,gnome,cosmic}. En la
    cola de wlr no, así que el perfil no las alcanza. Un escritorio sin una sola fuente.
  · /etc/passwd y /etc/fonts/fonts.conf.

Y bash NO CORRE: enlazado dinámico contra ncurses, del que sólo hay `libncurses.a` ⇒ «Error
relocating /bin/bash: tgetent: symbol not found».

El modo de fallo vale más que la lista. Nada de esto se vio como un error: `foot` abría, sway
registraba «New xdg_shell toplevel» —la ventana EXISTÍA en el árbol— y la captura salía con UN SOLO
COLOR. El shell moría al instante y la ventana se cerraba antes del frame. Log entero en verde,
pantalla vacía. Por eso la evidencia es contar colores del PNG y nunca leer el log: 1 color = sólo
swaybg, ningún cliente dibujó.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o

2026-08-26 17:09:04 +00:00

sergioandClaude Opus 5

e3403ff20e

sway ARRANCA EN QEMU con pantalla — evidencia, y seis muros que el grafo no podía ver

`docs/evidencia/sway-qemu-2026-08-08.png`: 1280×800, **102 colores distintos**, sway con foot a
pantalla completa y un prompt vivo, la barra de título del compositor arriba y el fondo
#1a4b8c asomando en los bordes. Sobre el kernel de hammer con arje-zero como PID1, sin X11 y
sin systemd.

EL VEREDICTO ES CONTAR COLORES, NO LEER EL LOG — y esta campaña lo demuestra sola: hubo un
arranque con TODO verde en el log (salida activada, modo 1280x800, «Commit of 1 outputs
succeeded», workspace creado) y la captura salía **100% negra**. Un compositor puede estar
perfectamente vivo y no pintar nada.

LOS SEIS MUROS, ninguno visible en un grafo de dependencias que decía 121/121:

1. `PATH` vacío — el console-getty no lo exporta y ni `mkdir` se encontraba. «mkdir: not found»
   se lee como «falta busybox» cuando busybox está entero: mismo engaño que el exit 127 de meson.
2. `libz.so.1` AUSENTE del rootfs. El zlib del corpus es sólo estático; la compartida vive en
   `zlib-shared`, en otra cola. Se cazó comparando los NEEDED del ELF contra el rootfs, no
   leyendo logs.
3. `LIBSEAT_BACKEND=builtin` NO EXISTE en nuestro libseat: `recipes/seatd.toml` construye con
   `-Dlibseat-seatd=enabled -Dlibseat-logind=disabled`, o sea UN backend, confirmado con
   `strings`. La receta manda sobre lo que uno cree recordar del proyecto — y la misma receta
   traía la salida: `-Dserver=enabled` construye `seatd-launch`.
4. `/run` de SÓLO LECTURA. La raíz de hammer es inmutable por diseño, y sway moría con «unable
   to open lockfile … check permissions», que suena a permisos de directorio y era un
   filesystem read-only. Se resolvió montando un tmpfs, que es lo que hace cualquier init.
5. `xkeyboard-config` — «failed to add default include path /usr/share/X11/xkb». Es EXACTAMENTE
   lo que dejé anotado en la receta de swaylock: «para que el teclado tenga distribución en una
   imagen real hará falta incluirlo por el lado del perfil». Apareció donde se dijo.
6. SIN TIPOGRAFÍAS no hay terminal. `fcft: failed to match font` → `failed to load primary
   fonts`: foot arrancaba y no dibujaba. `dejavu-fonts` estaba en el catálogo pero en otra cola.
   Va en la lista de §I.5 del SDD 20 («tipografías») y acá se ve por qué no es un detalle.

Y un fallo de MÉTODO que costó dos ciclos: mandé el log de sway a /var/log/sway.log DENTRO de
la VM, así que la primera captura negra vino sin una sola línea que la explicara — el
diagnóstico estaba dentro de la caja que no arranca. Un log que no se puede leer desde fuera no
es un log. Ahora va al serial.

Los `exec` de la config de sway disparan ANTES de que exista el workspace (0,259 s vs 0,305 s)
y mueren con «Failed to create launch context. No workspace». Los clientes se lanzan desde
sway-start esperando el socket de Wayland, que es la condición real.

Andamiaje reutilizable en scripts/wlr/: qemu-sway-image.sh (hermano del de COSMIC, sin logind
ni dbus, que sway no necesita), sway-start.sh y sway-config.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-07 22:38:51 -04:00