9941ab3cea8c009f305866e2150329a02259e2fd
52
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 SergioandClaude Opus 5
|
95e0d4964a |
brush como /bin/sh: pasa el banco POSIX entero y no construye una sola receta autotools
Medido en el worker, con el único cambio de /bin/sh en una copia por hardlinks del lab (sed/grep/awk siguen siendo busybox) y stores tirables. Control busybox: 3/3 recetas selladas. brush: 0/3. Lo que pasa: 56/57 del banco POSIX (igual que busybox), 0 rechazos sobre las 1130 fases de shell del corpus, parsea el configure de ffmpeg, funciona como argv[0]=sh y con el patrón de las cards de arje. Lo que falla: el configure corre entero pero el libtool que GENERA sale con un nivel de escapado de menos en 25 líneas, y ese fichero ya no lo parsea ningún shell. El parser de brush está bien — parsea sin quejarse el libtool del control. Mecanismo exacto no determinado: echo, sustitución de comando y el propio func_quote_for_eval de libtool dan idéntico en ambos shells aislados. Y un dato independiente del bug: 813us de arranque contra 91us de busybox (8,9x), sobre decenas de miles de shells por configure. El binario son 7,25 MB contra los 1,23 MB del busybox con sus 401 applets. De paso: brush selló con el mismo hash que traía build-state del otro hub. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
SergioandClaude Opus 5
|
8b8bac5523 |
evidencia: anotar que el log de una colgada se perdió al archivarla
El cp nunca corrió: zsh aborta el comando entero cuando un glob no casa, y ese directorio no tenía ningún .txt, así que tampoco se copió el .log — y el rm -rf siguiente se ejecutó igual. Borrar sin comprobar que la copia existía. Se deja un PERDIDO.md en vez de un directorio vacío, que es lo que la regla 3 de CLAUDE.md advierte: un directorio vacío no es evidencia, es un nombre. La firma medida antes de la pérdida (7/1/6, cero screenshot) sí está registrada en la cabecera del cazador. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2 |
||
|
SergioandClaude Opus 5
|
20a719f9c0 |
cuelgue headless: verificación A/B y evidencia — 98 segfaults contra 0
arnés viejo (sólo CONTENT) 98 segfaults · 1 colgada · 49/50 screenshots arnés nuevo (los cinco) 0 segfaults · 0 colgadas · 50/50 screenshots Queda dicho en la cabecera qué prueba esto y qué no. El MECANISMO sí: 98 → 0, exactamente 2 por corrida, en el 100% de las corridas; un efecto determinista se refuta con pocas muestras. El CUELGUE no: 1 contra 0 en 50 pares no es significativo — con la tasa medida (3 en 130 ≈ 2,3%) ver cero en 50 tiene ~31% de probabilidad aunque nada hubiera cambiado, y harían falta ~200 corridas para un negativo convincente. Lo que sí sostiene: las tres colgadas observadas tienen la MISMA huella exacta (7 fallos de lanzamiento de pestaña, 1 de rdd, 6 messageManager is null, cero screenshot) y las tres cayeron donde los ayudantes revientan. Ninguna apareció sin el mecanismo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2 |
||
|
SergioandClaude Opus 5
|
8ff6ae7b3a |
pgo: el control que faltaba — el arranque eran 16 s y diluía todos los porcentajes
El banco medía el ciclo COMPLETO del proceso (arrancar → renderizar → capturar → salir) y nunca se midió cuánto de eso era arranque. Con una página vacía como control, y las 4 cargas × 2 variantes en UNA sola sesión intercalada (restar entre corridas de días distintos no vale: la misma variante deriva ~1%): maquetación trabajo 7281 → 4744 ms -34,8% (publicado: -10,9%) carga ajena trabajo 4550 → 4634 ms +1,8% = cero, y es buena señal SunSpider trabajo -34 → -6 ms bajo el ruido Dos correcciones al documento: 1. El -10,9% es correcto para el ciclo completo pero se leía como 'firefox 11% más rápido'. Sobre el trabajo de la página el PGO rinde -34,8%: tres veces más. El error subestimaba el propio resultado. 2. La explicación que di del SunSpider era aire. Su trabajo mide -34 ms, NEGATIVO: la página con el benchmark tardó menos que la vacía. No había nada que medir, y yo le colgué encima una teoría sobre el JIT. La teoría puede ser cierta; esta medición nunca la probó. Las tablas viejas se dejan sin retocar, con un aviso arriba: el error de método enseña más que el número corregido. Todo el rigor estadístico estaba puesto sobre una cantidad que no era la que yo creía medir, y ninguna repetición lo habría revelado — sólo un control, que costó siete corridas de una página vacía. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2 |
||
|
SergioandClaude Opus 5
|
ec45c3fa97 |
dunst-headless: --via-atuq — la cadena entera, empezando en una página web
El modo por defecto prueba la cadena del SISTEMA (`notify-send` → bus → dunst).
Éste prueba la que motivó todo el hilo del §6.10: una página llama a
`new Notification(...)`, `libxul` hace `dlopen("libnotify.so.4")` —que no es
NEEDED de ningún ELF, o sea invisible para cualquier auditor—, eso habla D-Bus,
el bus ACTIVA dunst y dunst dibuja. Cinco piezas, y la única forma de saber que
están las cinco es verlo.
El veredicto acá no puede ser el diff de píxeles solo: el navegador ocupa la
pantalla y repinta por su cuenta. Lo decisivo es el `onshow` del objeto
Notification, que es el motor diciendo que el sistema ACEPTÓ la notificación; el
diff queda como corroboración y la captura «antes» se toma con atuq ya pintado.
--via-atuq MOSTRADA #33 · 151.174 píxeles
--via-atuq --negative-control «ERROR al mostrar» · 0 píxeles
El control negativo también se lee distinto según el modo, y no por comodidad:
sin el .service, lo que tiene que faltar en el modo navegador es el onshow.
Captura en docs/evidencia/atuq-notificacion-web-sway-2026-09-07.png: dos globos
de dunst sobre la ventana de atuq, en sway headless, sin que nadie haya lanzado
el daemon a mano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
|
||
|
SergioandClaude Opus 5
|
4f9ee5430f |
dunst: sway ya atiende las notificaciones, y hay un píxel que lo prueba
Era la única mitad que quedaba abierta del mapa del §6.10: KDE atiende
`org.freedesktop.Notifications` con plasma-workspace, GNOME con gnome-shell y
COSMIC con cosmic-notifications; sway no tenía a NADIE, así que una página que
pedía notificar mandaba el mensaje al bus y se lo comía el silencio.
`dunst` 1.12.2 y no `mako` —que es el de la casa wlroots— por dos razones
medidas: el nombre `mako` YA ESTÁ OCUPADO en el corpus por el motor de plantillas
de mesa, y el cierre del perfil incluye las herramientas de build, así que la
imagen terminaría con dos artefactos homónimos peleando por las mismas rutas; y
mako habla D-Bus por sd-bus, que en musl es una receta nueva (basu), mientras
dunst habla por GDBus, que ya está sellado. Cero dependencias nuevas.
DOS GUARDIANES EN LA PROPIA RECETA, porque las dos cosas que importan no se ven
en que compile:
- `X11=0` es una intención; el hecho se lee en el ELF. dunst compila los dos
backends por defecto y su config.mk avisa: sin wayland «forzará xwayland». En
esta distro eso sella un binario que arranca, toma el bus y NO PINTA NUNCA. La
fase exige `libwayland-client` entre los NEEDED y prohíbe `libX11`.
- El `.service` de D-Bus es la mitad que importa: sin systemd, al daemon lo
levanta EL BUS. Se comprueba que reclame `org.freedesktop.Notifications` y se
le saca la línea `SystemdService=`, que acá no puede significar nada.
Y `DUNSTIFY=0`: entró primero en 1 y el binario **segfaultea hasta en
`--help`** (rc=139 en las tres pruebas). La causa es el cuadro que este repo ya
tiene escrito: nuestro `libnotify.so.4` es compartido y arrastra la cadena glib
`.so`, mientras esta cola enlaza la GLib estática ⇒ dos copias de GObject en un
proceso. No se pierde nada: el emisor de la casa es `notify-send`, que viene
DENTRO del artefacto de libnotify y ya está en las cuatro imágenes. Hay un
guardián que frena el día que alguien vuelva a poner DUNSTIFY=1 sin leer.
LA PRUEBA, en `scripts/wlr/dunst-headless.sh`: sway headless + bus de sesión +
`notify-send`, y NADIE lanza dunst a mano — lo activa el bus por el .service,
que es el mismo camino de una página web en atuq. La evidencia es un diff de
píxeles antes/después acotado al cuadrante donde dunst dibuja, porque un log en
verde es compatible con una pantalla vacía y el color no distingue (swaynag pinta
su barra de error en el mismo rojo).
positivo 14832 píxeles cambiados · servidor: dunst knopwob 1.12.2 1.2
control 0 píxeles · ServiceUnknown · notify-send rc=1
El control negativo borra el .service dentro del overlay temporal y EXIGE que no
se dibuje nada: probado en los dos sentidos.
Captura en docs/evidencia/dunst-sway-notificacion-2026-09-07.png.
Vigía de sonames: escritorio-sway 203 → 204 nodos, 512 sonames, 0 sin proveedor.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NNFzrqFBEt6W7maGJKf2Xs
|
||
|
Sergio
|
5b9777bdbd |
declarar gcc-libs como dep de EJECUCIÓN en las seis — y el navegador arranca
Las seis recetas que el audit daba por colgantes declaran ahora
`runtime = ["gcc-libs"]`. `deps.runtime` NO entra en el ArtifactHash —medido:
firefox sigue en b3:8116bdec, atuq en b3:f2960991, waterfox en b3:88b5a762—
así que esto NO reconstruye nada. Lo que cambia es la CLAUSURA, que es lo que se
hidrata en la imagen.
EVIDENCIA DE QUE ARREGLA EL FALLO REAL, no de que compila: `atuq` bajo sway
headless, sin GPU, renderizando about:buildconfig con sus tablas y la barra de
contenedores de la v0.5. Antes moría con decenas de «Error relocating:
_ZNKSt5ctypeIcE13_M_widen_initEv: symbol not found».
docs/evidencia/atuq-arranca-con-gcc-libs-2026-09-06.png
Y el audit se corrige, porque SUB-REPORTABA en dos formas:
· Miraba sólo ejecutables y `head -12` por artefacto. El siguiente NEEDED que
faltaba estaba en una LIBRERÍA (libmozsandbox.so pedía libnspr4.so), así que
daba «6 recetas» cuando el artefacto de firefox declara 30 sonames. Ahora
recorre TODOS los ELF.
· No contaba lo que el propio artefacto TRAE. Firefox bundlea su nspr/nss y
las encuentra por el LD_LIBRARY_PATH que fija su lanzador; contarlas como
colgantes era un falso positivo.
Con las dos correcciones y gcc-libs en el store, el corpus baja de 25 artefactos
colgantes a TRES, y son otra cosa:
sqlite-shared libreadline.so.8
python3 libreadline.so.8
naabu libdl.so.2 libpthread.so.0 libc.so.6
Los dos primeros piden una receta que falta (readline). El tercero pide sonames
de GLIBC, que en una distro musl es un síntoma distinto y merece su propia
mirada. Quedan anotados, no arreglados.
|
||
|
Sergio
|
e88e4ab3d7 |
SDD 26 §3.ter: el muro del display del PGO está despejado, con evidencia
El PGO necesita correr el navegador para juntar el perfil, y las distros lo hacen bajo xvfb-run. Nosotros no tenemos X11 (Wayland-only), así que el plan decía «la salida es un sway headless». Ya no es plan: se corrió. sway con WLR_BACKENDS=headless y WLR_RENDERER=pixman arranca en gioser —un LXC SIN /dev/dri, o sea sin GPU ninguna— y dibuja píxeles reales. La captura va como evidencia: sway 1.10 / wlroots 0.18.2 / foot 1.27.0, los tres binarios nuestros, salida HEADLESS-1 a 1280x720. Ciclo completo ~2 min. Dos cosas que costó y quedan escritas para no repetirlas: · Hidratar BAJO el montaje del store. hydrate-profile.py enlaza, y un hardlink no cruza montajes: con --into work/... sale EXDEV porque el store está en otro disco. Con --into store/.rootfs/sway son 193/193 nodos y 4,9 G que no ocupan. · Inyectar el loader de musl. sway salió DINÁMICO y pide /lib/ld-musl-x86_64.so.1, que el cierre no trae. El error es «exec: /usr/bin/sway: not found», que se lee como «falta el binario» cuando lo que falta es su INTÉRPRETE. En musl el libc.so ES el loader, así que se resuelve con un --ro-bind. Misma familia que el resto de la noche: el mensaje nombra lo que buscó, no lo que falta. Queda el segundo muro del PGO, que es de diseño y no de infra: el profdata no es determinista, así que hay que generarlo UNA vez y sellarlo como artefacto propio consumido por hash. |
||
|
SergioandClaude Opus 5
|
914c1b72af |
kcoreaddons: prender el módulo QML — el menú de Plasma ABRE, y detrás de él konsole
`-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
|
||
|
SergioandClaude Opus 5
|
e04fdf4599 |
evidencia: el panel de Plasma con iconos, y el lanzador que NO abre por un módulo QML
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 (
|
||
|
SergioandClaude Opus 5
|
7e1474d135 |
evidencia: Plasma 6 pintando en QEMU tras declarar kactivitymanagerd
Fondo Breeze + panel + reloj, sobre virtio-gpu con llvmpipe y SIN KVM (TCG puro:
gioser es un vServer sin virtualización anidada). Antes de
|
||
|
SergioandClaude Opus 5
|
099e84703f |
imagen: inyectar libffi/expat/bzip2 COMPARTIDAS desde el store
El cierre hidratado sólo trae los .a de estas tres (sus recetas canónicas son
--disable-shared), pero libgobject, libgirepository, libwayland-{client,server},
libp11-kit y libgjs salen con símbolos ffi_*, mesa entero (iris/swrast/kms_swrast,
libEGL, libgbm) con XML_* y freetype con BZ2_*. En el host eso resuelve contra el
sysroot Alpine del LAB —así que el artefacto sella y el perfil da 100%— y en la
imagen el loader de musl aborta:
Error relocating /usr/lib/libgobject-2.0.so.0: ffi_call: symbol not found
gnome-shell moría con código 127 antes de exponer wayland-0, y con él login1,
Accounts, UPower, colord y wireplumber. Es el punto ciego que documenta
scripts/vigia-sonames.py, visto desde el lado de la imagen.
Con la inyección: 'compositor OK (wayland-0)' y el shell pinta (evidencia adjunta).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0164nrZWZc78Mr2srrsnoM8U
|
||
|
SergioandClaude Opus 5
|
1df77985fa |
tasas: T19 — el sandbox apila una capa overlay por dep, y lo caro no es lo que parece
Nadie había medido qué cuesta el apilado de capas de `bwrap_args`. El 95% de las recetas (1 108 de 1 171) construye con las deps APILADAS, hasta ~27. Un lookup que FALLA cuesta +1 925 ns por capa (a 64 capas, 124 µs = 1 580 syscalls nulas), pero se paga UNA VEZ POR RUTA: la dentry fusionada queda cacheada y el montaje dura toda la fase. Un `cc -O2 -c` toca 381 rutas distintas que fallan ⇒ 2,9 ms por fase a 24 capas, la misma décima de por ciento que la jaula de T17/T18. ⇒ `merge_deps_layer` no es una optimización de velocidad: sólo se pagaría sola a partir de ~35 200 primeros fallos en una misma fase. Es el rodeo de un muro, y el muro quedó bisecado al byte: `mount(2)` monta 41 capas (4 059 B de opciones) y falla en 42 con un `ENOENT` que miente. El `mount(8)` de util-linux se rinde entre 8 y 12, así que bisecarlo desde la shell da un muro FALSO. Consecuencias anotadas en sandbox.rs: no bajar el umbral «para que vaya más rápido», y podar `.dmerge` es gratis en rendimiento. Y hay puerta medida: la API de montaje nueva (`fsconfig lowerdir+`) monta las 64 capas que `mount(2)` rechaza. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
46dba58616 |
tasas: T17/T18 — la jaula cobra por syscall, y el filtro largo no es lo que cobra
SDD 25 tenía medido el sandbox por namespaces (T14, ~1 ms por proceso) pero no el grano fino que harkaq pone dentro, que cobra por SYSCALL. `bench_jaula.c` lo mide con control negativo en las dos mitades (si la jaula no quedó puesta, sale con 2). seccomp: el filtro de harkaq es una denylist lineal, así que toda syscall legítima recorre la cadena entera — y aun así es PLANO en su longitud (86,9 ns con 4 entradas, 88,3 con 250, sobre un piso de 75,0). Lo que lo hace plano es el bitmap de acción constante del kernel, y eso no se supone: un gemelo de la misma longitud con una carga de args[0] —que hace que el analizador se rinda— sí crece, 111,6 → 139,9 ns. La regla que sale de ahí es que un filtro es gratis mientras no mire un argumento. El bitmap se paga al instalar (1,5 µs por entrada) y se amortiza en 2 830 syscalls, o sea una invocación y media de gcc, una sola vez por fase de build. landlock: el precio es ESTAR enjaulado (+473 ns por open), no cuántas reglas hay — pasar de 1 regla a las 16 384 de una clausura fichero a fichero agrega +225 ns más. La política por-fichero de D1, que era la decisión discutible, resulta casi gratis. Y dos negativas medidas: `stat` no paga (Landlock no engancha getattr) y un open DENEGADO sale más barato que uno concedido, al revés de lo que se esperaba al medirlo. En total, la jaula le cuesta a un compilado 0,23–0,31%: una décima parte del presupuesto de <5% de SDD 16. De paso, dos cosas del filtro que salieron de mirarlo para medirlo: la denylist tiene un techo de ~252 entradas por el __u8 de los saltos de la BPF clásica, y el jf se calcula leyendo y modificando `k` en la misma expresión (UB en C11, benigno con gcc y clang, comprobado). Y §9.6 queda con el experimento de PTI bien planteado: no es «el laptop daría peor» (compara dos máquinas y mezcla cuatro variables) sino la misma máquina con pti=on y pti=off. momento no sirve ni forzándolo: este invitado no expone PCID, así que mediría el peor caso y no el de un TigerLake. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
56e59b821a |
SDD 25 H7: BTF cuesta +14,97% de bzImage — medido construyendo, no estimado
Era el ultimo hueco medible de SDD 25 en esta maquina: H7 tenia el precio en cuatro partes pero no el numero en bytes, que es como se pago H1. Se construyo una copia derivada de linux-generic con UNA sola diferencia en el .config (DEBUG_INFO_DWARF5 + DEBUG_INFO_BTF) y todo lo demas byte a byte igual: bzImage sin BTF : 16 937 984 B bzImage con BTF : 19 473 408 B (+2 535 424 B = +2,42 MiB = +14,97%) seccion .BTF : 7 888 166 B sin comprimir, entran comprimidos 3,11x Contra la unica vara comparable: H1 (MEMCG+PSI) costo +80 KiB / +0,49% del mismo bzImage => BTF cuesta 31 veces eso. No lo decide, pero lo saca de "un re-hasheo y ya". Sobre linux-generic y no sobre linux, que es mas barato: BTF tiene depends on BPF_SYSCALL y el .config sellado de linux lo trae APAGADO, asi que medir ahi habria mezclado dos precios. TRES cosas que salieron construyendo y no leyendo: 1. Una QUINTA parte del precio que nadie habia nombrado: hace falta python3. BTF hace que kbuild descienda a tools/bpf/resolve_btfids, que compila un libbpf vendorizado cuyo Makefile genera bpf_helper_defs.h con un script de Python (Error 127). 2. El numero de Artix fallaba en la direccion CONTRARIA a la esperable. El doc decia que sus 6,4 MB "no dicen nada de uno monolitico y pelado"; el nuestro sale MAS GRANDE, 7,5 MiB. Artix es modular y su .BTF cubre solo el core built-in; el nuestro es monolitico y los tipos de i915+nouveau+radeon+iwlwifi entran todos. 3. Una trampa de kconfig que es CLAUDE.md §3 dentro de make: scripts/pahole-version.sh imprime 0 si pahole no esta en el PATH, el depends on PAHOLE_VERSION >= 122 deja de cumplirse, y olddefconfig BORRA la linea en silencio. El build sale OK y sella un kernel SIN BTF diciendo que todo fue bien. Por eso la receta comprueba el .config PRODUCIDO y sale 1 si no esta. Salio OK, lo que ademas paga la parte (3) del precio: el pahole estatico de ayer se encuentra y se ejecuta DENTRO del sandbox. El artefacto de medicion se borro a proposito: `hammer kernel contract --sealed` lo listaba como SIN COMPROBAR (no declara [[target]], que es lo que exige H8), o sea un aviso permanente en un fichero que el cron commitea cada 30 min. Un aviso fijo que no corresponde a ningun problema es como se deja de leer un vigia. La receta derivada queda en la evidencia. Nada del corpus se re-hasheo: la derivada vive fuera de recipes/ y el catalogo se le presta por symlinks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
09168bf1e3 |
SDD 25 §9.5: el iterador BPF, medido — y H7 pasa a tener precio
Cae el quinto de los seis experimentos nombrados. Un `iter/task` que emite registros binarios saca la foto de procesos cerca de 7x mas barato que el barrido de /proc (6,9-8,0x en cuatro corridas de 33 rondas y las dos direcciones), pero el numero que decide es otro: cuesta 1,75x el piso de `readdir` contra 12,1x de /proc. Leer los campos deja de tener precio; lo que se paga es enumerar. Dos barreras comprobadas, no supuestas: el programa se ata por id de tipo BTF del vmlinux (attach_btf_id=80137, prog_type=26) — sin DEBUG_INFO_BTF no hay a que atarse, no hay version de esto que esquive H7 —, y hace falta CAP_BPF+CAP_PERFMON, o sea que el consumidor es el supervisor, no la Card. Y los dos caminos NO dicen lo mismo: 24 de 245 comm difieren, todos kworkers, porque /proc SINTETIZA el nombre pegandole la workqueue. Un reemplazo vendido como «la misma informacion mas rapido» tenia una diferencia de contenido, y solo aparecio cotejando registro contra registro. H7 deja de decir «pahole en el lab y un re-hasheo». Son cuatro cosas: DEBUG_INFO_NONE=y en los .config sellados (BTF exige DWARF antes), el kernel no declara la receta dwarves aunque este sellada, ese pahole es DINAMICO pese a link="static" (INTERP + 5 NEEDED) y corre dentro del sandbox del build, y BTF mete la version de pahole en la bit-repro con el lab fuera de hash_inputs. Ya hay dos consumidores nombrados, no cero: este iterador y sched-ext. Lo que sigue SIN medir es el precio en bytes del bzImage, que es como se pago H1 — se mide construyendo, y esa es la primera tarea el dia que se decida. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
6cd8a0410b |
tasas: H1 PAGADO — los cuatro kernels de Cards ya traen MEMCG y PSI
hammer kernel contract --sealed: 5 de 5 vigentes cumplen su perfil, exit 0. Antes eran 2 de 11. Una Card que pide memory.max ahora encuentra el fichero en vez de dejar un warn! y correr sin tope. Lo medido, no lo supuesto: - el x86_64_defconfig de 7.1 ya NO trae MEMCG=y ⇒ había que pedirlo explícito; - MEMCG no tiene ningún depends on, así que el olddefconfig no podía tragárselo — comprobado igual contra el .config producido, que es la regla del guardián; - precio: +80 KiB en linux-generic (+0,49%), +84 en linux-metal, +88 en linux-metal-dual, +80 en linux-gioser (+0,71%). Medio punto de kernel por contabilidad por unidad y presión. Evidencia cruda en docs/evidencia/tasas-kernel-2026-08-29/contrato-h1-pagado.txt, con el diff-back del plan de gioser sobre su config nuevo (35 cumplidos, 0 incumplidos). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
849c041446 |
tasas: los 4 experimentos que §9 dejó nombrados, medidos con root
SDD 25 §9 listó seis experimentos que no se pudieron correr y por qué. Cuatro de ellos sólo pedían privilegios, y esta sesión los tuvo. Programas y salidas crudas en docs/evidencia/tasas-kernel-2026-08-29/. 1. proc connector (bench_connector.c) — el sondeo de /proc no es lento, es CIEGO: 200 procesos de vida mínima lanzados uno cada 10 ms, sondeando cada 100 ms se ven **0 de 200**; por connector, **200 de 200**. Y esperar el evento no cuesta nada frente a waitpid (116,0 vs 114,8 µs, dentro del ruido), con 0 eventos perdidos en 1400. Sorpresa: taskstats por genetlink **no es más rápido** que parsear /proc/self/stat (2 688 vs 2 697 ns). Su valor es el CONTENIDO (delay accounting), no la velocidad. 2. reflink (bench_reflink.c) — el «copiar en O(1)» existe y NO está en ext4: FICLONE no soportado, y copy_file_range ≈ read+write (13,7 vs 14,5 ms). En xfs y btrfs es PLANO: 64 MiB en 0,010 ms y 512 MiB —ocho veces más— en 0,020 ms, contra 512,7 ms de read+write. **25 600× a 512 MiB.** 3. io_uring SQPOLL (bench_sqpoll.c) — no rescata el veredicto de T12: sobre datos cacheados pierde igual. ext4: pread 554 ns < io_uring 618 < SQPOLL 868. tmpfs: pread 749 < SQPOLL 1 409 < io_uring 2 030 (ahí sí mejora al io_uring normal, 1,4×, pero sigue perdiendo contra la syscall). Y se come un core. 4. syscalls por invocación de compilador — con el strace DEL PROPIO CORPUS (store/3c1fd8c0…-strace), que es la respuesta a «no hay strace en esta máquina». gcc: 1 803 syscalls por un `-c` trivial, **1 095 con error (61%), 919 de ellas readlink** — la canonicalización de rutas, que T8 no medía. Pero al piso de 78,7 ns son 0,14 ms sobre 30,5 ms de compilado: **el cruce al kernel es el 0,5%**. La tormenta de rutas vale milisegundos, no minutos. Condiciones distintas a la corrida original (load ~1,3 sobre 4 vCPU contra 7,3) ⇒ los absolutos NO se comparan entre corridas, sólo los cocientes dentro de una. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
aeeaa6d07f |
SDD 25: las tasas del kernel medidas, y el MEMCG que falta en las recetas
16 tasas de Linux medidas en momento (KVM, 4 vCPU, bajo carga): piso de syscall, /proc como API de texto, fork vs espacio de direcciones del padre, enlazado dinámico, VFS, io_uring, THP, namespaces. Programas en C y salidas crudas en docs/evidencia/tasas-kernel-2026-08-29/. Lo que sale de medir y después verificar contra las recetas: los kernels de hammer se construyen sin CONFIG_MEMCG (no está en x86_64_defconfig y no tiene default y), y arje/sandokan escriben memory.max descartando el error. Un tope de memoria pedido por una Card no se aplica y sólo deja un warn. Tres resultados que contradicen el consejo de manual y quedan documentados: THP 3x más lento que 4K con defrag=madvise, io_uring 2,8x más lento que pread sobre tmpfs, y stat cuesta lo mismo en tmpfs que en ext4 (es tasa del VFS). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
SergioandClaude Opus 5
|
f8f679d038 |
corpus: expat-shared y libffi-shared cierran la fuga al Alpine del lab
sway es `link = "dynamic"` A PROPÓSITO —un compositor dlopea los drivers DRI de mesa en runtime— y sale con doce NEEDED. Nueve los cubría la clausura (pixman, drm, evdev, input, udev, wayland-server, wlroots, xkbcommon, libc), porque esas recetas ya son dinámicas. Los otros tres —libz.so.1, libexpat.so.1, libffi.so.8— venían de recetas `--disable-shared`, así que NINGÚN artefacto sellado producía ese `.so` y el rootfs los resolvía contra el sysroot Alpine DEL LAB. POR QUÉ ERA PEOR QUE UNA DEP FALTANTE. Una dep ausente falla ruidosamente. Ésta no: el lab NO entra en `hash_inputs`, así que el store daba el artefacto por bueno mientras el binario sólo arrancaba en una máquina que tuviera Alpine debajo. La fuga era invisible para todo el sistema de medición. `zlib-shared` ya existía en el corpus y sólo faltaba declararla. `expat-shared` y `libffi-shared` son nuevas, calcadas del patrón: autotools con --enable-shared, sin el truco de --whole-archive que zlib-shared necesita porque SU configure aborta bajo zig cc. SONAMEs verificados contra lo que pide el ELF: libexpat.so.1, libffi.so.8, libz.so.1. Exactos. NO se tocó `link` en las canónicas: entra en `hash_inputs` y habría re-hasheado expat, libffi y todo lo que los lista en deps —fontconfig, dbus, mesa, glib, python3, los crates `-sys`— cientos de recetas selladas por libs que ya están bien. El nombre `*-shared` es distinto del canónico, así que conviven. Verificado antes de construir: recalculadas las 794 recetas, **0 hashes cambiados**, sólo las 2 nuevas. Van al CORPUS y no a incoming-wlr/ porque la resolución de deps es hermano→padre: una receta del corpus no ve una cola. Es donde ya viven zlib-shared, fontconfig-shared, freetype-shared… VERIFICADO CON PÍXELES, no con el log. Rootfs rehidratado desde cero (126/126), CERO ficheros de `.dev-fs/alpine`. Cero «Error relocating». La captura tiene el MISMO sha256 que la de las libs de Alpine: 177fea396caa9dca, 1280x720, 383 colores. Tercera vez que la evidencia sale bit a bit igual al cambiar la procedencia — la soberanía no costó ni un píxel. Perfil: escritorio-sway 126/128. Faltan strace (linux-headers del lab) y rsync (404 de upstream). QUEDA UN RESTO: el loader `/lib/ld-musl-x86_64.so.1` todavía se toma del host. `recipes/musl.toml` existe en el corpus pero está EN DEUDA y fuera de todo perfil — mismo agujero de declaración, un nivel más abajo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o |
||
|
SergioandClaude Opus 5
|
d68b750109 |
evidencia: sway headless 2026-08-26 — 1280x720, 383 colores, foot con texto vivo
Captura tomada por grim (del corpus) sobre sway 1.10 / wlroots 0.18.2 / foot 1.27.0, todo construido desde fuente con zig cc contra musl. Backend headless en bwrap: ni QEMU ni kernel de por medio. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016v9ozVm44p6DB7EMXeZK4o |
||
 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> |
||
|
sergioandClaude Opus 5
|
b5802bc651 |
📖 cosmic/metal: el 1er viaje físico, la carrera USB y la lección general
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> |
||
|
sergioandClaude Opus 5
|
11e6a3c78c |
🔩 cosmic/metal: imagen EFI con iris HW — el viaje que cierra ScreenCast
Hermano de kde/metal-desktop-image-dual.sh, pero con la decisión INVERTIDA y ése es el motivo de existir. La de KDE va por mesa-llvmpipe a propósito (tenía que aguantar también una NVIDIA Pascal, cuya mesa HW sólo existe como binario Alpine ⇒ rompería soberanía). Acá el objetivo es cerrar ScreenCast, y el diagnóstico de hoy midió que lo que falla es el COMPOSITOR en una llamada EGL —8 ms antes del `Paused`— porque en QEMU mesa es kms_swrast: software, SIN exportación dmabuf. El `mesa` del corpus se construye con -Dgallium-drivers=iris y YA está en el rootfs de COSMIC; en QEMU nunca se usaba, en un TigerLake es el driver correcto y trae dmabuf de verdad. O sea que este viaje no es "lo mismo pero en metal": es la única forma de saber si ScreenCast está bien. ⚠ Por eso NO se inyecta llvmpipe: mezclarlos no es aditivo — llvmpipe trae su propio libgbm/libEGL/libgallium y sobrescribirlos DESACTIVA iris. Si la máquina no tuviera Intel, la imagen correcta sería la de KDE, no ésta con un parche. Y lo que NO hace falta inyectar, medido: la de KDE mete libLLVM.so.18 + libgcc_s + libstdc++ porque el JIT de llvmpipe los NEEDea. Acá NO — iris_dri.so pide sólo libglapi/libdrm/libz/libzstd/libc (mesa va con -Dllvm=disabled) y cosmic-comp ocho NEEDED sin C++. CERO binarios ajenos de Alpine. Verificado con clausura ELF completa del rootfs: 472 objetos escaneados, 42 raíces de runtime, 0 con NEEDED sin proveedor (los 3 huecos son llvm-*/perl, herramientas de build que el escritorio no arranca). Se instala EL MISMO cosmic-start validado en QEMU, no una variante: nada de lo que hace es específico del emulador, y que corra el mismo fichero es lo que hace que "validado en QEMU" signifique algo para el metal. VALIDADO EN OVMF CON PANTALLA, que es la regla de oro que costó un USB en el 1er viaje de KDE (-serial null para simular metal sin puerto serie): arje-zero PID 1, las 4 particiones montadas, el motd VISIBLE y el prompt `/ #` en la pantalla — o sea que el getty de tty1 hace su trabajo. El shell responde: iris_dri.so presente, /dev/dri/card0, y cosmic-start/portal-probe/wireplumber en PATH. Falta quemar el USB, que es destructivo y necesita que el usuario confirme el device. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
b38f54e25c |
🧊 ScreenCast: la causa es EGL POR SOFTWARE en el compositor, no el portal
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>
|
||
|
sergioandClaude Opus 5
|
8d10bccf34 |
🔇 wireplumber: construido, corriendo… y NO era el bloqueo
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>
|
||
|
sergioandClaude Opus 5
|
ee037912a9 |
🎥 ScreenCast: el stream SE CREA — nodo cosmic-screencast vivo en pipewire
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>
|
||
|
sergioandClaude Opus 5
|
e43ce95786 |
🎥 cosmic: pipewire ARRANCA, y el portal ya figura como cliente suyo
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>
|
||
|
sergioandClaude Opus 5
|
2e26a45060 |
🎥 cosmic: ScreenCast — dos bloqueos, y el que importa es que NADIE ARRANCA PIPEWIRE
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>
|
||
|
sergioandClaude Opus 5
|
5f606111d1 |
📂 cosmic: FileChooser ejercido — pero NO desde cosmic-store, y el motivo importa
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>
|
||
|
sergioandClaude Opus 5
|
99e670ee4f |
🚪 cosmic: las cinco interfaces del portal, sondeadas — y Access no es un hueco
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> |
||
|
sergioandClaude Opus 5
|
ada054cf07 |
🚪 cosmic: LA CADENA DEL PORTAL CERRADA — cosmic-screenshot captura de verdad
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>
|
||
|
sergioandClaude Opus 5
|
520271ea2f |
📷 cosmic: cosmic-screenshot sellada y ROTA A PROPÓSITO — y la glib compartida YA existe
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> |
||
|
sergioandClaude Opus 5
|
04146ec77b |
🛍 cosmic: la tienda LISTA — el catálogo AppStream hubo que fabricarlo, y el <provides> la vaciaba
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>
|
||
|
sergioandClaude Opus 5
|
539e2acd5b |
✎ cosmic: cosmic-edit VALIDADO en QEMU — y el deadline del panel sí mira la carga del anfitrión
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>
|
||
|
sergioandClaude Opus 5
|
232f23c5a8 |
⚙ cosmic: cosmic-settings — el panel de control, y NO arrastra medio sistema
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> |
||
|
sergioandClaude Opus 5
|
23c0e82527 |
📁 cosmic: cosmic-files — la 2ª aplicación, y «ya está compilado» era falso por una línea
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> |
||
|
sergioandClaude Opus 5
|
e39610588d |
🖥 cosmic: cosmic-term — la primera APLICACIÓN, y la biblioteca deja de estar vacía
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> |
||
|
sergioandClaude Opus 5
|
9665cc29d4 |
cosmic: la calculadora del lanzador ANDA — el stdin de qalc era el stdout
=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> |
||
|
sergioandClaude Opus 5
|
505eaf5e44 |
cosmic: pop-launcher — el lanzador eran DOS programas, y ahora Super abre
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> |
||
|
sergioandClaude Opus 5
|
a232bcc0af |
cosmic: los atajos andan (Super+A, Super+W) y el panel tiene un deadline de arranque
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> |
||
|
sergioandClaude Opus 5
|
39b91b5146 |
cosmic: la entrada anda — click y teclado por QMP; y 29 atajos caídos por UNA línea
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> |
||
|
sergioandClaude Opus 5
|
cd1497d740 |
🏔 cosmic: EL ESCRITORIO ENTERO DIBUJADO — panel, dock y applets en QEMU
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> |
||
|
sergioandClaude Opus 5
|
d724f0e267 |
🎉 cosmic: LA SESIÓN ARRANCA ENTERA — el camino de producción, no el andamio
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>
|
||
|
sergioandClaude Opus 5
|
ab8cfc30c9 |
🎨 cosmic: un cliente PINTA — cosmic-bg entrega su buffer y el fondo aparece
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> |
||
|
sergioandClaude Opus 5
|
ef4b18bc88 |
🖥 cosmic: COMPONE EN QEMU — cosmic-comp presenta frames sobre el kernel de hammer
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> |
||
|
sergioandClaude Opus 5
|
c0055331c7 |
gnome: esperar el NOMBRE de PolicyKit1 antes de lanzar a sus clientes
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> |
||
|
sergioandClaude Opus 5
|
7f2fdd5a41 |
🔊 audio FUNCIONANDO — el muro era libudev-zero, y ensancharlo de más rompía el vídeo
Audio
├─ Devices: 48. HDA Intel [alsa]
├─ Sinks: * 52. HDA Intel Analog Stereo [vol: 0.40]
├─ Sources: * 53. HDA Intel Analog Stereo [vol: 1.00]
Y gvc con perfiles reales (`output:analog-stereo+input:analog-stereo`). Se fue el auto_null.
LA CAUSA: SPA pide el device `card` (alsa-udev.c:178-183), que no tiene major:minor, y
libudev-zero recorría SÓLO /sys/dev/{block,char} — sólo devices CON nodo. El device que
SPA necesita nunca entraba en la enumeración: no faltaba una propiedad, faltaba la mitad
del espacio de búsqueda.
**Y LA PRIMERA VERSIÓN DEL PARCHE ARREGLÓ EL AUDIO Y ROMPIÓ EL VÍDEO.** Recorría
/sys/class entero, y /sys/class/drm no trae sólo tarjetas: trae los CONECTORES
(card0-Virtual-1) y un fichero `version`, ninguno con nodo. Mutter los tomaba como
candidatos ⇒ `No available CRTC for monitor` + `Page flip failed: drmModeAtomicCommit:
Invalid argument` en bucle. Pantalla negra con el compositor vivo: el mismo síntoma de
antes por una causa nueva. El udev real también los enumera, pero les adjunta las
propiedades por las que mutter los descarta, y ésas libudev-zero no las sintetiza.
La lección, que vale para cualquier reimplementación parcial de una API: **ensanchar la
enumeración expone los huecos de PROPIEDADES a más consumidores. Los dos lados del
contrato tienen que crecer juntos.** El parche final lleva una LISTA ACOTADA de
subsistemas (`sound` hoy); agregar otro es una línea *y* una prueba de que el consumidor
lo necesita y no se rompe.
POR QUÉ NO eudev — y corrijo mi propia sugerencia de antes, que era la peor opción: el
repo ya lo había probado en otro frente y ROMPIÓ EL INPUT. Su libudev.so.1 pisa el de
libudev-zero y, sin udevd, no expone ID_INPUT ⇒ libinput ignora todos los dispositivos en
silencio. Verificación A/B en QEMU de aquel episodio: eudev = 0 «New device»,
libudev-zero = 5. eudev sin udevd es PEOR, y correr udevd contradice la arquitectura
(arje-zero es PID1). El arreglo va donde está el hueco.
Radio pagado: 51 sellados a deuda, 9 en el cierre GNOME (reconstruidos: libinput,
libgudev, colord, mutter, gnome-shell, libgdm, upower, pipewire, wireplumber). El resto
—base, cli, KDE— queda para el latido.
Captura actualizada: escritorio pintando (628 colores) Y audio, cero page-flip fallidos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
5faa259603 |
audio: PipeWire es el servidor de la distro (decisión del usuario) — gvc conecta
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> |
||
|
sergioandClaude Opus 5
|
3d01d5cb04 |
gnome: el bus de sistema COMPLETO — faltaba polkit, y lo dijo la lista de nombres
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> |