main
668
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  sergioandClaude Opus 5
|
44820a3fa3 |
cosmic: los applets hablan D-Bus por la C, no por zbus
libdbus-sys cortó el build de cosmic-applets. El resto de la suite habla D-Bus con zbus (Rust puro), pero los applets de red, bluetooth y status-area usan la libdbus de verdad por FFI. Gotcha de diagnóstico: el build.rs de libdbus-sys hace 'panic!' a secas en la línea 25, sin mensaje. Lo único que dice qué falta es el NOMBRE DEL CRATE — no buscar una explicación en el error, no la hay. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
0e8abb8059 |
cosmic: la barra de más de cosmic-applets — no es un dedazo, es un truco, y hay que respetarlo
El manifiesto apunta a 'https://github.com/pop-os/cosmic-protocols//' con DOS barras al final. Es como upstream hace que cargo trate esa fuente como DISTINTA de la URL normal, para que el [patch] de al lado no se apunte a sí mismo. Pero GitHub devuelve 404 a '/pop-os/cosmic-protocols//info/refs' y cargo vendor muere en el fetch, antes de compilar una línea. El primer intento fue cambiar '//' por '.git', y falló POR LA RAZÓN QUE HACE QUE EL TRUCO EXISTA: cargo normaliza el .git, así que el patch pasaba a apuntar a la misma fuente que reemplaza — 'patches must point to different sources'. La barra de más no es reemplazable por cualquier variante cosmética: tiene que ser una que cargo considere OTRA fuente y que el servidor sepa servir. Sólo cumple las dos la barra en el MEDIO ('pop-os//cosmic-protocols'), que es justo la forma que usa cosmic-comp — y por eso aquél construyó sin parche. Se toca Cargo.toml y Cargo.lock juntos: cambiar uno solo rompe el --locked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
516610b307 |
cosmic: cosmic-panel selló y no pintó — le faltaban los HIJOS, no una librería
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> |
||
|
sergioandClaude Opus 5
|
5a4ee1a3bf |
cosmic: el settings-daemon toca TLS, y por donde uno no lo busca
openssl-sys cortó el build con 'Could not find directory of OpenSSL installation'. No lo pide el daemon: llega por native-tls, que llega por el crate geonames — la base de husos horarios que usa para el tema claro/oscuro por hora. Es el único de la suite que toca TLS, y por una función que nadie asocia con la red. El openssl del corpus ya publica openssl.pc, así que alcanza con declararlo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
95cf728991 |
cosmic: receta de cosmic-settings-daemon — la pieza sin la cual NO HAY SESIÓN
Escrita mientras compila su dep: cosmic-session lo lanza con .expect() en main.rs:255, así que si falta panickea la sesión entera JUSTO DESPUÉS de que el compositor arrancó bien. Eso es lo que lo hace confuso de diagnosticar y lo que lo puso último en la cola pese a ser obligatorio. Es el único de la suite con cadena propia en C (audio-server → cosmic-pipewire → libpipewire-0.3 por pkg-config), que es exactamente lo que costó traerlo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
d3c0545c4d |
cosmic: la cadena de pipewire entra a la cola — sale MUCHO más barata de lo estimado
Medido en vez de estimado: copiar pipewire a incoming-cosmic necesita CUATRO recetas hermanas (alsa-lib, dbus-shared, libsndfile, pulseaudio), no las seis que había contado a ojo, y de esas **tres dan hash idéntico y ya están selladas**. Sólo pulseaudio y pipewire hay que construir, porque su glib resuelve al corpus (b3:93d2cad0) en vez de a la sombra de GNOME (b3:f6ccdf98). Y eso refina lo que este runbook advertía: el peligro de las dos glib es MEZCLARLAS EN UNA IMAGEN, y la imagen COSMIC tiene una sola. Acá el costo es de builds, no de corrección. Lo que sigue vigente es no promover a ciegas entre colas. Gotcha del copiado: el se resuelve relativo a la receta, así que copiar el .toml sin su .patch da 'no pude leer patch' — el hash ni siquiera se calcula. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
13dc9e3488 |
cosmic: el juego fijo de deps de todo cliente son CUATRO, leído de una vez del comando del linker
La línea de enlace de cosmic-osd pedía '-ludev -linput -lxkbcommon': los tres llegan por la cadena de libcosmic (enumeración de monitores y de dispositivos de entrada), no por nada que el cliente haga a la vista. Los venía descubriendo de a uno por build —xkbcommon con cosmic-bg, udev con osd, ahora input— hasta leerlos todos juntos en el comando que rustc le pasa al linker. El error dice el que falta primero; el COMANDO dice todos. Entra además cosmic-idle rehecho dinámico (b3:e1806acc). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
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
|
616ea4a23c |
cosmic: las cinco recetas que faltaban de la sesión (panel, launcher, app-library, workspaces, notifications)
Escritas ya con el patrón medido —libxkbcommon + pkgconf en todas— en vez de descubrirlo cinco veces. Cada install sale del justfile/Makefile de upstream leído, no del parecido con el anterior; ahí estaban las tres diferencias que importan: - cosmic-panel: default_schema NO es un fichero sino un ÁRBOL de tres componentes de cosmic-config con un fichero POR CLAVE. Aplanarlo deja un panel que arranca con todo por defecto compilado: sin plugins, sin dock, sin tamaño. - cosmic-workspaces-epoch: los tres nombres NO coinciden — repo con sufijo -epoch, binario y AppID sin él, y cosmic-session lo busca por el del binario. - launcher y app-library instalan .desktop + metainfo + icono; notifications y osd no llevan ninguno porque no se lanzan a mano. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
2b5d518486 |
cosmic: libxkbcommon va en TODA la cola — la dep no se deduce de la función del paquete
cosmic-idle se escribió sin [deps] con un argumento que parecía sólido: no usa smithay-client-toolkit (el que hizo caer a cosmic-bg) y un demonio de inactividad no interpreta teclas. Reventó igual, pero en el ENLACE y no en un build.rs: -lxkbcommon lo arrastra cosmic-settings-config, de donde sale la tabla de atajos y que usa TODO componente de la suite. La dep no viene de lo que el paquete hace sino de la librería de configuración común. Dos veces el mismo error de método con dos razonamientos distintos, y las dos veces el mensaje decía exactamente quién y por qué. Queda en el runbook como regla, no como anécdota. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
1355fc1650 |
cosmic: dav1d 1.5.4 sellado (b3:aab7a874) — la feature de cargo la prende OTRO, no el paquete
cosmic-bg declara `image` con default-features=false y sin AVIF, y aun así se compila dav1d-sys: las features de cargo se UNIFICAN en el grafo, así que alcanza con que otro crate del árbol la prenda para que la decisión del que la apagó no mande. Mismo modo de falla que un '.pc Requires' arrastrando una dep que nadie declaró. Se podría parchear el Cargo.toml de upstream para cortarlo; no se hizo, porque eso es mentirle al paquete sobre lo que hace. Si el grafo dice que sabe decodificar AVIF, que lo sepa de verdad — y cualquier cosa del corpus que decodifique AV1 va a querer dav1d igual. Dos decisiones del build, las dos leídas del meson.build y no supuestas: nasm es dep REAL (find_program en :536, exige >= 2.14; copiado de la cola GNOME con hash verificado b3:33383070), y default_library=both porque quien consuma dav1d con enlace estático necesita la .a — publicar sólo la .so convierte cualquier link=static río abajo en una etiqueta falsa. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
b1bbdefc85 |
cosmic: sctk ENLAZA libxkbcommon — «habla Wayland en Rust» no quiere decir «no toca C»
cosmic-bg se escribió sin [deps] con ese argumento y reventó en el build.rs de smithay-client-toolkit pidiendo xkbcommon.pc. El que dlopea xkbcommon es winit, que es otra capa. Hablar el protocolo en Rust dice cómo viaja el byte, no con qué se interpreta un teclado. El link=static sigue siendo verdad: el artefacto de libxkbcommon trae .a además de .so. Corolario anotado en el runbook: todo cliente de la suite va a necesitar al menos libxkbcommon + pkgconf. Entran además cosmic-idle (cliente Wayland puro, SIN deps a propósito: no usa sctk y no necesita interpretar teclas) y cosmic-osd, que es el primer cliente de iced/libcosmic y por eso vale como sonda: panel, launcher, app-library, workspaces y notifications comparten su mismo sustrato exacto. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
bc6f664650 |
cosmic: recetas del compositor, del fondo y del tema de iconos (cola incoming-cosmic)
cosmic-comp es LA pieza y la receta salió casi gratis: mirada-compositor ya probó que smithay construye en este lab, y las deps en C de smithay dependen de las features del backend, no del compositor. La lista es la misma menos linux-pam y más libdisplay-info. libdisplay-info y hwdata entran COPIADAS byte a byte de la cola GNOME (idénticas a las de KDE): las deps resuelven hermano→padre, así que desde incoming-cosmic no se ven las de otra cola. Verificado que el hash NO se mueve (b3:260f0519 y b3:bdc36cf9) ⇒ los artefactos ya sellados sirven y la copia no cuesta un build. cosmic-bg va antes que el resto de los clientes porque separa dos preguntas: habla Wayland por smithay-client-toolkit y NO toca libcosmic/iced, así que si el fondo pinta y el panel no, el problema es de la capa de UI y no del transporte. Toda la suite está tagueada epoch-1.5.0, confirmado repo por repo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
e1564614e1 |
cosmic: primera receta del cuarto escritorio — cosmic-session SELLADO (b3:81f02351)
Sonda barata antes del compositor: Rust puro, sin una dep en C, y prueba las tres cosas nuevas que la cola COSMIC necesita — edition 2024 sobre el rustc 1.96 del sandbox, deps de git en el Cargo.lock (launch-pad, cosmic-dbus-a11y), y el patrón de instalación de la suite (binario + start-cosmic + cosmic.desktop). Salió a la primera: ELF estático, cero NEEDED. Toda la cola incoming-cosmic va pinneada al tag epoch-1.5.0: COSMIC versiona sus repos en lockstep y mezclar epochs no da error de compilación sino un escritorio que no se entiende consigo mismo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergio
|
7190cc48a3 | estado: cosecha granja 2026-07-30T23:20:59Z — avance del árbol KDE | ||
|
sergioandClaude Opus 5
|
2430528c16 |
dbus: las políticas de login1 y PolicyKit1 viajan en su ARTEFACTO, no en el script de imagen
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> |
||
|
sergioandClaude Opus 5
|
ef2668ad97 |
wireplumber: el -I$PWD/lib/wp NO hacía falta — era la carrera del ADR 0012
La receta llevaba una bandera de include que su propio comentario marcaba EN DUDA: se había puesto porque el build cortaba con `../lib/wp/wp.h:13: fatal error: 'client.h' file not found`, un header que SÍ existe justo al lado del que lo incluye. La explicación real era que **otro agente construía en el mismo repo y borraba árboles de work/sources/ en pleno build** — la carrera del ADR 0012, que produce exactamente esa firma: ficheros que existen cuando los mirás después y no existían al compilar. Re-probado CON EL REPO QUIETO —comprobando primero que no hubiera ningún `hammer build` vivo— y sella igual sin la bandera. Confirmado, no supuesto. Verificado además de punta a punta: audio sigue dando `48. HDA Intel [alsa]` con sink y source reales, 0 page-flips fallidos. La lección queda en la receta: antes de agregar una bandera que no se explica, mirar si hay otro build vivo. Es barato y evita inventar arreglos para síntomas que no son del código. **GOTCHA DEL LAB, aprendido a la mala en el mismo movimiento: los BYTES del fichero .patch entran al ArtifactHash.** Corregir la PROSA obsoleta de `pipewire-sound-initialized.patch` —decía que la decisión libudev-zero-vs-eudev seguía pendiente cuando ya está resuelta— re-hasheó pipewire y arrastró wireplumber. La distinción que conviene tener presente: **comentar una RECETA es gratis** (hash_inputs toma source/compiler/target/link/flags/fases/ deps, no los comentarios del TOML) **y comentar un PARCHE cuesta un rebuild**. Anotado en pipewire.toml, que es donde se va a leer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
17b86cf85e |
estado: deuda del corpus CERRADA — base, cli y mirada al 100%
sealed 765 → 768 debt 3 → 0 never 2 (los dos con bloqueo documentado) base 50/51 → 51/51 cli 73/74 → 74/74 escritorio-mirada 29/31 → 31/31 Cierre de la deuda que yo mismo abrí al parchear libudev-zero (una hoja del cierre de las CINCO imágenes): reconstruidas `usbutils` (b3:245c718b — depende de libudev por pkg-config), `mirada-compositor` (b3:c906e244) y `mirada-greeter` (b3:c7dfcf09). Ojo con la aritmética, que casi me confunde: `yupana radio libudev-zero` dice 58 dependientes transitivos y build-state sólo veía 3 en deuda. No es contradicción — **build-state cubre el catálogo canónico `recipes/`, no las colas `incoming-*`**, y 47 de esos 58 están en incoming-kde. Los 8 de incoming-gnome ya se habían reconstruido ayer. Los dos `never` NO son trabajo pendiente disfrazado; los dos tienen bloqueo real y ya escrito: - **dwarves**: su cmake no halla libdw. La receta ya lo documentaba y el build lo confirmó palabra por palabra («Could NOT find libdw include dir / library»): `elfutils.toml` empaqueta sólo LIBELF —lo que kbuild necesita— y es INTOCABLE porque es build-dep de los kernels sellados. La salida es una receta hermana `elfutils-libdw`, que en musl arrastra shims de argp/fts/obstack. Campaña propia, no un arreglo. - **llimphi-counter**: es una PLANTILLA, no un paquete. Su commit es `000…0`, un placeholder que nunca se llenó. Gasté un build en descubrirlo, así que ahora la receta lo dice en la primera línea: `⛔ ESTO ES UNA PLANTILLA, NO UN PAQUETE. NO INTENTES CONSTRUIRLA.` El estado `never` del grafo era técnicamente cierto y semánticamente engañoso. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
beb2851d99 |
colord: el demonio ya se construye (b3:8100fa39) — arranca, abre sus DB y NO adquiere el nombre
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> |
||
|
sergioandClaude Opus 5
|
888fdc31c7 |
firmware: SOF para TigerLake — el DSP de audio, pineado como el de i915
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> |
||
|
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
|
8c3bd323d5 |
audio: ALSA encendido en el kernel — y el muro real es libudev-zero, no el stack de audio
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> |
||
|
sergioandClaude Opus 5
|
51c6830f58 |
audio: wireplumber (b3:39a9a06c) + lua (b3:e6c35f98) — y el Devices vacío es del KERNEL
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> |
||
|
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> |
||
|
sergioandClaude Opus 5
|
3999b421da |
gnome: cursor visible, iconos y el setuid del launch-helper de D-Bus
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> |
||
|
sergioandClaude Opus 5
|
723f3ead33 |
gnome: 🏔🏔 EL ESCRITORIO PINTA — Overview de GNOME desde fuente, con captura
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> |
||
|
sergioandClaude Opus 5
|
417ba2a502 |
gnome: 🏔 LA SESIÓN ARRANCA Y SE QUEDA VIVA — cae el último muro de la capa JS
== gnome-qemu :: compositor OK (wayland-0) — el shell ES el display server
== gnome-qemu :: STATUS +15s … +315s: gnome-shell=2
Sin una sola `JS ERROR`. gnome-shell corre 5 minutos seguidos sobre DRM real.
Dos cierres, los dos por auditar en vez de adivinar:
1. GL-1.0 y libxml2-2.0 sumados a gi-foreign-typelibs. La primera auditoría de
`<include>` la hice sólo sobre los girs de /usr/share/gir-1.0 y me faltaron los que
entran por los girs PRIVADOS de mutter (Clutter-16, Cogl-16 → GL-1.0, o sea que sin
él no carga `Meta`: el compositor entero) y por los de eds (Camel, EBook,
EDataServer → libxml2-2.0). Un ciclo de imagen+arranque perdido por auditar de menos.
La forma correcta —y ahora escrita en la receta— es cruzar los `<include>` de TODOS
los .gir del rootfs hidratado contra los typelibs presentes. Queda un solo huérfano,
`xlib-2.0`, que sólo incluye `xft-2.0`, a quien no incluye nadie: no es una falta.
2. libgdm vuelve a construir su `data/`. La había borrado entera por parecer «cosas del
greeter», y ahí vive el gschema **org.gnome.login-screen**, que gnome-shell lee al
arrancar: sin él muere con `Gio.IOErrorEnum: GSettings schema ... not found`. Un
esquema de GSettings no es un fichero de datos del demonio — es una interfaz publicada
que consume otro programa. Se borra sólo `subdir('dconf')`, la única pieza que necesita
el binario `dconf`.
Lo que queda son avisos, no muros: falta un tema de cursor, colord no arranca por el
setuid del helper, y `org.gnome.settings-daemon.peripherals.touchscreen` no existe
porque g-s-d está aparcada (rompe quick-settings, no la sesión).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
8d1efca26e |
gnome: GIRepository-2.0 — el typelib que no pide el shell sino gjs
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>
|
||
|
sergioandClaude Opus 5
|
bc4d0c8aea |
gnome: los 7 typelibs CERRADOS — librsvg y ibus, y dos deudas viejas pagadas de paso
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> |
||
|
sergioandClaude Opus 5
|
4d48edac0d |
gnome: 5 de los 7 typelibs de runtime — gnome-desktop a la isla dinámica + 5 recetas nuevas
De los siete que faltaban quedan dos (Rsvg, IBus). Cerrados acá: GnomeDesktop-4.0 + GnomeBG-4.0 gnome-desktop b3:b3aed0d6 UPowerGlib-1.0 upower b3:95d1081a Geoclue-2.0 geoclue b3:50e9de94 GWeather-4.0 libgweather b3:d289ac66 gnome-desktop NO se duplicó en una variante `-introspected`, y la razón es la regla de los dos registros de GType: mutter y gnome-shell ENLAZAN libgnome-desktop y gjs además dlopearía la .so del typelib ⇒ convivirían la .a enlazada y la .so cargada, cada una con su tabla. Es el cuadro que costó el episodio de colord. `yupana radio` = 2 sellados a deuda (mutter, gnome-shell), el mismo par de siempre. Con introspección encendida los dos seds que borraban `libgnome_rr_gir`/`libgnome_bg_gir` dejan de hacer falta. Su cierre tuvo que pasar a las variantes `-shared`, y no por prolijidad: con `libpng` estática no hay libpng16.so, `libgdk_pixbuf-2.0.so.0` no relocaliza y el `ldd` con que g-ir-scanner resuelve las shlibs sale con 127. **Si una receta introspecta, su cierre entero tiene que ser CARGABLE** — el scanner compila y ejecuta un binario de verdad. Dos recetas entraron por transitividad, no por la lista del shell: - geocode-glib (b3:f24e4147), que pide libgweather. Su `-Dsoup2=false` es LA opción: con el default se construye `geocode-glib-1.0` contra libsoup2 —que esta distro no tiene— y libgweather no la encuentra aunque esté instalada. - py3-gobject/pygobject (b3:492930f2), y ésta ni siquiera va a la imagen: va al CONSTRUCTOR. `gen_locations_variant.py` de libgweather importa gi.repository.GLib para serializar la base de ciudades a un GVariant binario. El formato lo define GLib. Decisiones de alcance escritas en cada receta: geoclue va SIN demonio (-Denable-backend=false evita ModemManager, Avahi y libsoup; la librería cliente habla por D-Bus), upower sin libimobiledevice, y libgweather sin `po-locations` ⇒ las ciudades salen en inglés, la base de datos se genera igual. De upower, tres perillas que hay que fijar porque su `auto` significa "preguntale a un pkg-config de systemd": udevrulesdir/udevhwdbdir (nuestro udev-pc declara `udevdir`, no `udev_dir`) y systemdsystemunitdir=no. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
fd9f9dff6d |
gnome: libgdm (b3:46fac484) + cairo-1.0.typelib — la capa JS avanza dos muros más
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> |
||
|
sergioandClaude Opus 5
|
a98267468c |
gnome: gi-foreign-typelibs (b3:a159373c) — un .gir NO es un typelib
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> |
||
|
sergioandClaude Opus 5
|
08fc1d4b92 |
gnome: accountsservice SELLA (b3:0328b0d0) — cae la frontera de la C-ABI de logind
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>
|
||
|
sergioandClaude Opus 5
|
03bdd41b4a |
gnome: el muro de input NO era libudev-zero — el fd de TakeDevice era bloqueante
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> |
||
|
sergioandClaude Opus 5
|
8cf9a87dd2 |
arje-logind-compat: repineado al fix (b3:5e4b8e04) — la cadena vuelve a ser reproducible
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>
|
||
|
sergioandClaude Opus 5
|
f56bab72f5 |
gnome: el compositor SUBE ENTERO en headless — el muro DRM es libinput, y aparece accountsservice
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>
|
||
|
sergioandClaude Opus 5
|
fbd1e5fca1 |
gnome onda 3: json-glib con default_library=both (b3:52a20f22), no shared
Corrige el commit anterior, donde quedó `shared`. Con shared-only sus otros dos consumidores —libgusb y colord, que siguen siendo estáticos— cortaron pidiendo `libjson-glib-1.0.a`. `both` deja la .so que necesita el g-ir-scanner y la .a que necesitan ellos, sin obligar a de-estatizar media cola. Es el mismo fix que destrabó glib en su momento. Cascada re-sellada contra este hash: mutter (b3:a90e6bae), libgusb, colord y evolution-data-server (b3:28368c7a). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
794d9b595e |
gnome onda 3: 🏔 GNOME-SHELL SELLADO (b3:b6aec8a2) — LA CIMA
/usr/bin/gnome-shell construido desde fuente, con sus cuatro typelibs (St-16,
Shell-16, Gvc-1.0, Shew-0) y el NEEDED cerrando en artefactos sellados + libc.so:
cero fuga al sysroot de Alpine.
El draft estimaba "~10 recetas nuevas, dominadas por eds+icu". Fueron 13, pero
casi ninguna donde el mapa las esperaba. Lo que la última tanda destapó:
dbus-shared la cima enlaza atk-bridge-2.0, cuyo .pc Requires atspi-2 y ése
dbus-1 — el dbus canónico es estático no-PIC y el configure ni
llegaba a compilar. Cuarta variante -shared de la cadena, todas
por la misma raíz: el corpus se construyó para un userland
ESTÁTICO y el escritorio es dinámico por obligación.
pulseaudio la frontera llegó por el camino más indirecto de la campaña:
+ libsndfile gnome-shell incluye el subproyecto gvc (el control de volumen)
SIN condicional (meson.build:256) y gvc pide libpulse duro.
Se construye SÓLO EL CLIENTE (-Ddaemon=false): gvc necesita
HABLAR el protocolo, no implementarlo, y el demonio de sonido de
esta distro es una decisión aparte todavía abierta (PulseAudio vs
PipeWire) que construir el daemon habría cerrado de prestado.
libsndfile con --disable-external-libs = una receta, no cinco.
Dos parches al árbol, ambos verificados antes de aplicarse:
· subdir('po') fuera (:324). CUARTA vez que el msgfmt de gettext-tiny aborta
con SIGABRT, acá en po/ar.po; ya pasó en iso-codes, gcr y eds. La deuda está
clara: hace falta el gettext de GNU de verdad.
· los #include <X11/Xlib.h> y <X11/Xatom.h> de src/shell-app-usage.c son
VESTIGIALES — el fichero no usa un solo símbolo de X11. El código X11 real
(el tray XEmbed) SÍ está cerrado por have_x11_client, que sale de mutter y
acá es false. shell-app-usage.c quedó fuera del guard por olvido del upstream.
Y --undefined-version en pulseaudio: usa UN version-script para las tres libs
cliente, así que al enlazar libpulse.so el script nombra símbolos de
libpulse-simple y libpulse-mainloop-glib. GNU ld avisa; lld corta. Mismo flag que
libtiff-shared.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
0f7817a25f |
gnome onda 3: CAE LA ÚLTIMA FRONTERA — evolution-data-server SELLADO (b3:ad335cfb) + nss
La cima de GNOME ya no tiene fronteras: gnome-shell exige libecal-2.0 y libedataserver-1.2 (meson.build:72-73) y el artefacto trae los dos .pc más los 8 typelibs (ECal-2.0, EDataServer-1.2, Camel-1.2, EBook…). NSS: el atajo que no era. Primero se intentó esquivarla con -DENABLE_SMIME=OFF. eds declara esa opción y su cabecera promete honrarla, pero en 3.56.2 el guard NO EXISTE: include(FindSMIME) es incondicional (:303) y el fichero nunca vuelve a mirar la variable. Se cableó el guard que faltaba y el configure pasó… y el build cortó igual en el 11%: src/camel/camel.c incluye <nspr.h>/"nss.h"/<ssl.h> SIN guardar por el #ifdef y hace init/shutdown reales de NSS. ENABLE_SMIME=OFF sólo compila fuera camel-smime-context.c, no camel. El modo está roto de verdad. Así que se pagó: nss 3.126 (b3:d0659c9c), y selló A LA PRIMERA pese a coreconf. La receta absorbe lo que ese build system no da — no hay ./configure, no hay make install, el OBJDIR lleva la versión del kernel del constructor (se resuelve por GLOB, no se hornea, o el artefacto dependería del uname del anfitrión), y el nss.pc se rellena del template. nss_build_all no sirve: reconstruiría NSPR, y el nuestro ya está sellado desde spidermonkey. Tampoco era deuda huérfana: NSS es la base criptográfica del frente del navegador. json-glib dada vuelta a la isla dinámica (b3:9bc69a4b): su .gir es entrada del .gir de eds. El comentario viejo de la receta había previsto exactamente este caso. Radio medido con yupana ANTES de tocar: 3 sellados caen a deuda. El otro hallazgo: eds usa msgfmt DOS veces. Sacar add_subdirectory(po) no alcanza porque i18n_merge_file (I18n.cmake:19) fusiona traducciones dentro de los .desktop desde data/. Se reemplaza por `cmake -E copy`, y NO es aproximación: los templates traen las claves PLANAS y msgfmt --desktop sólo AGREGA variantes Name[xx]=. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
fd73295c94 |
gnome onda 3: las tres piezas de soporte de eds — libsecret, libxml2-shared, libuuid-shared
Leído el CMakeLists real de evolution-data-server 3.56.2, la frontera de la cima
son cuatro cosas, no una. Estas son tres; la cuarta (NSS) va aparte.
libsecret 0.21.7 b3:b75607c6 CMakeLists:932 la mete en el pkg_check_modules
(DATA_SERVER REQUIRED …) sin perilla, y libedataserver-1.2 es lo que
gnome-shell enlaza. En gcr se la había esquivado con -Dssh_agent=false;
acá no hay cómo: eds guarda ahí las credenciales de correo y calendario.
-Dcrypto=libgcrypt de las tres del combo — gnutls no existe en el corpus
y 'disabled' apagaría el cifrado justo en la pieza que guarda contraseñas.
libxml2-shared b3:87389636 en libical la libxml2 sólo la enlazaba un binario
de build y bastó la .a canónica; en eds entra en cuatro .so reales
(CMakeLists:932,936,937,938) y la .a no es PIC. Mismos patches de CVE que
la canónica: la superficie de seguridad no diverge.
libuuid-shared b3:d42cf850 `uuid` es REQUERIDA (:424). No es un
"util-linux-shared": --disable-all-programs apaga los ~100 binarios y deja
una sola librería. Duplicar la lista de --without-* del canónico para
conseguir un .so de 30 KB sería mantener esa superficie en dos lugares.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
98932ec477 |
gnome onda 3: libical SELLADO (b3:ada6e05f) — tercera pieza de la cadena eds
libecal-2.0 (lo que gnome-shell exige en meson.build:72) está construida sobre
libical-glib. Salió a la primera; leer el CMakeLists real ahorró otra receta:
LibXML → la pide ICAL_GLIB, pero SÓLO la enlaza ical-glib-src-generator, un
ejecutable de BUILD que parsea el XML de la API. No entra en ningún
.so ⇒ la libxml2.a canónica (no-PIC) sirve y NO hace falta
libxml2-shared. Segunda receta que se ahorra por leer el build real.
Perl → DURA (:193, sin perilla), y salió gratis: ya estaba promovida desde
que el barrido de harkaq en la granja la destapó como único irreducible.
ICU → opcional (RSCALE), encendida porque icu4c ya estaba paga.
-DUSE_BUILTIN_TZDATA=ON no es cosmético: por defecto libical lee la tzdata del
SISTEMA, o sea que el artefacto quedaría atado al /usr/share/zoneinfo del
constructor y se movería con cada actualización del host. Con la del tarball el
artefacto es autocontenido y entra entero al ArtifactHash. El CMakeLists avisa
"(Careful)" porque esa tabla envejece; es el precio correcto — un store
direccionable por contenido no puede depender del reloj del anfitrión.
Verificado: ICal-3.0.typelib + ICalGLib-3.0.typelib, cierre en sellados + libc.so.
Queda UNA receta para la cima: evolution-data-server.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
1283215173 |
gnome onda 3: libsoup SELLADO (b3:79d6bf81) + sqlite-shared
Segunda pieza de la cadena eds. Leer el meson.build real (y no el mapa de
memoria) corrigió dos cosas del presupuesto:
libxml2 → libsoup 3.x NO la usa (era de la era 2.x, SoupXMLRPC). Se ahorra
una variante -shared que estaba presupuestada.
sqlite3 → DURA, no opcional: meson.build:123-136 termina en dependency()
sin `required:false`. Y el libsqlite3.a canónico NO es PIC, así que
no entra en un .so — mismo muro R_X86_64_32 que frenó a mutter
contra freetype. De ahí sqlite-shared (b3:7aba78e7), hermana de
zlib-shared/cairo-shared, sin tocar la canónica.
El apagado que más compra es -Dtls_check=false: el meson ASSERTEA que exista
glib-networking para TLS, y eso arrastraba gnutls o openssl+p11-kit. Apagar el
CHECK no apaga el TLS — GIO resuelve el backend por módulo en runtime, así que
el día que haya receta de glib-networking basta hidratarla, sin recompilar.
Verificado: Soup-3.0.typelib producido (la isla dinámica lo exige) y el NEEDED
cierra en artefactos sellados + libc.so, sin fuga al sysroot Alpine.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
a9f40e15bc |
gnome onda 3: hojas de la cadena eds — nghttp2 (b3:5f35b06e) y libpsl (b3:824b4bb9)
Arranca la última frontera de gnome-shell: evolution-data-server. El comentario
de gnome-shell.toml estimaba ~10 recetas dominadas por icu, pero icu4c YA quedó
sellada por la campaña KDE (b3:dbda6797) y sólo depende de pkgconf+python3, o
sea del corpus padre ⇒ copiarla a incoming-gnome da hash IDÉNTICO y cero
rebuild (la resolución de deps es hermano→padre, nunca de reojo a otra cola).
Con icu ya pago, las dos hojas de libsoup salen a la primera:
nghttp2 1.64.0 b3:5f35b06e --enable-lib-only deja la frontera en CERO deps
nuevas; las apps arrastraban libev, libcares,
openssl, jansson y libevent.
libpsl 0.21.5 b3:824b4bb9 --enable-{runtime,builtin}=libicu, verificado por
NEEDED libicuuc.so.77 (no degradó a libpsl ciego).
Frontera restante de la cima: libsoup, libical, evolution-data-server.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
9f9f2303b4 |
gnome onda 3: MUTTER SELLADO (b3:50c37a83) — cae el muro de logind
El compositor construye: /usr/bin/mutter + gdctl, libmutter-*.so, los typelibs Clutter-16 y
Cogl-16, y libmutter-16.pc — que es exactamente lo que gnome-shell enlaza e importa.
LO QUE DESTRABÓ TODO: libelogind (b3:a6058906), receta nueva sobre `arje-sdlogin-compat`, un
crate que escribí en tawasuyu para esto. arje-logind-compat ya publicaba el estado de sesión
en /run/systemd/{sessions,users,seats}; faltaba la librería C que lo LEYERA, porque la API
sd-login no es cliente D-Bus: lee esos ficheros. mutter probó libsystemd (no), después
libelogind (sí) y siguió de largo. No es un stub: lee estado real que el daemon publica.
Después del muro aparecieron cinco cosas más, todas resueltas y ninguna de fondo:
udev-pc (b3:69e2d418) mutter pide DOS pkg-config: `libudev` (lo da libudev-zero) y `udev`
(metadata: udevdir). Receta aparte y no agregado a libudev-zero
porque `yupana radio` daba 51 SELLADOS cayendo a deuda en las cinco
imágenes. Un .pc de 4 líneas no justifica medio catálogo.
libxcvt (b3:ab8ede67) mutter corre `cvt` en build-time para generar meta-default-modes.h.
El app/cvt clásico vive en xorg.freedesktop.org, que desde acá no
responde (probé x.org, kernel.org y Lysator). libxcvt es la
extracción moderna del mismo código, está en el pool de Debian y no
arrastra nada de X11.
-Dbash_completion=false y el sed de subdir('doc/man') (pedía rst2man).
py3-setuptools el distutils del g-ir-scanner, mismo precedente que polkit y gjs.
cierre C dinámico freetype/fontconfig/cairo/libpng/zlib/libjpeg/libtiff pasan a sus
variantes -shared: mutter ya es .so y las estáticas canónicas no
entran («relocation R_X86_64_32 … recompile with -fPIC»). Mismas
variantes que usa gtk4.
Y gsettings-desktop-schemas pasa a introspection=true + isla dinámica: su gir GDesktopEnums
entra en el de Meta, y sin él el scanner cortaba en el ÚLTIMO target (721/722). Es exactamente
el caso que el comentario de esa receta dejaba previsto («si mutter/gjs lo pidieran vía
typelib, se re-activa»). Costo medido: 1 sellado (gnome-desktop), reconstruido acá mismo.
PENDIENTE: la receta apunta al commit de gitea que todavía NO está pusheado (ver el informe).
El artefacto ya es el correcto — la URL no entra al ArtifactHash, sólo el commit, así que
construir desde el clon local dio el MISMO hash que dará desde gitea.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
a79cc8d1ab |
gnome onda 3: gcr SELLADO (b3:698096b0) + p11-kit + las variantes shared de libgcrypt/libgpg-error
Tercera de la cima. gnome-shell la exige por gcr-4 (meson.build:74) y su JS importa gi://Gcr
(js/ui/components/keyring.js) ⇒ tenía que ser .so con typelib, no había opción estática.
Cadena nueva: p11-kit (b3:8dbec390) → gcr. p11-kit va con -Dtrust_module=disabled, que es lo
único que arrastraba libtasn1: una receta menos.
EL NUDO REAL fue el PIC, otra vez. libgcrypt y libgpg-error del corpus son estáticas SIN PIC
(y libgcrypt además está afinada para binarios -all-static -no-pie, con la advertencia escrita
de que el flag va en compile e install pero nunca en configure). Meterlas en un .so da
«relocation R_X86_64_32 ... recompile with -fPIC».
NO se tocaron las canónicas: `yupana radio` dio 5 sellados cayendo a deuda en base/cli, y
mostró además que existe OTRA libgpg-error en incoming-kde con 39 dependientes — justo el
tipo de colisión que el radio existe para ver. Se hicieron variantes -shared en la cola, que
es el idioma que este frente ya tiene (zlib-shared, cairo-shared, freetype-shared…).
libgcrypt-shared compiló con ZIG-CC, no gcc como la canónica: evidencia de que esa receta puede
migrar cuando le toque el turno de matar-gcc. Necesitó -fno-sanitize=undefined (el runtime UBSan
que inyecta zig deja __ubsan_handle_* sin definir en el .so), remedio ya documentado en zlib-shared.
Otros dos apagados de gcr, cada uno ahorrando una receta: -Dssh_agent=false (libsecret sólo la
pide el agente ssh) y -Dgpg_path fijo (gcr sólo quiere la RUTA de gpg para hornearla, no ejecuta
nada). Y el sed de subdir('po'): el msgfmt de gettext-tiny ABORTA con SIGABRT en po/ar.po. Es la
segunda vez que ese msgfmt marca el límite; si hay una tercera, conviene autorar el gettext de GNU.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
92977572a1 |
gnome onda 3: at-spi2-core SELLADO (b3:33f4a891) y retira el atk suelto que iba a chocar
Segunda de la cima. Da atk.pc, atk-bridge-2.0.pc y atspi-2.pc + los typelibs Atk-1.0 y Atspi-2.0. gnome-shell la exige por atk-bridge-2.0 (meson.build:71). El choque que atk.toml anticipaba se confirmó: el tarball de at-spi2-core trae `atk/` adentro e instala su propio atk-1.0. Dos recetas con el mismo .pc se pisan en el sandbox, y NO era hipotético: el cierre de gnome-shell contiene a las dos, porque mutter es dep suya. Se retira atk.toml y at-spi2-core queda como único proveedor — que es lo que hace upstream desde 2.51.90. Medido antes de tocar, con `yupana radio atk`: 1 dependiente directo (mutter), 0 sellados que caigan a deuda. mutter repuntado a at-spi2-core llega EXACTAMENTE al mismo muro de logind, sin ninguno nuevo. DBus-1.0.gir lo pedía el scanner y ya lo provee gi-foreign-girs (no hizo falta receta nueva). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
7de2ebd030 |
gnome onda 3: polkit SELLADO (b3:27d93b4c) — sólo librerías, el demonio ya lo pone arje
Primera de la cima. Da polkit-agent-1.pc (lo que gnome-shell enlaza en C) y los typelibs Polkit-1.0 + PolkitAgent-1.0 (lo que su JS importa: gi://Polkit aparece en polkitAgent.js, endSessionDialog.js, status/thunderbolt.js y environment.js — verificado, no supuesto). -Dlibs-only=true y acá la opción SÍ recorta, al revés que en colord: el bloque `if not libs_only` (:145-159) es justo el que pide expat, duktape y threads. Y no es un recorte a desgana — la Semilla de arje ya trae compat-polkit implementando el servicio D-Bus; construir polkitd sería competirle, no completarlo. -Dsession_tracking=ConsoleKit no es preferencia por ConsoleKit: es la ÚNICA de las tres que no exige una C-ABI de logind (logind→libsystemd, elogind→libelogind), y son LAS MISMAS funciones sd-login que traban a mutter (sd_uid_get_display, sd_pidfd_get_session). Con libs-only ese camino queda inerte. Cuando exista el shim, vuelve a `logind`. -Dauthfw=shadow (no hay linux-pam). Isla dinámica, como manda la regla del registro único de GType. Las 3 deps de tooling que faltaban salieron de precedentes ya escritos del frente: gettext-tiny (msgfmt), py3-setuptools (distutils de g-ir-scanner) y glib-introspected (Gio-2.0.gir para el scanner). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
43ec9a6933 |
gnome onda 3: frontera de gnome-shell medida contra el meson.build (la de memoria mentía)
La lista de FRONTERA de la receta se había escrito de memoria y tenía dos errores. Sobraban ibus y startup-notification: no aparecen en el meson.build de 48.8. Y faltaba la más cara: libecal-2.0 + libedataserver-1.2, o sea evolution-data-server entero (el calendario del panel), que arrastra libical, libsoup, nss e icu — ninguna en el corpus. No hay atajo por versión: verificado que gnome-shell 50.3, la serie más nueva publicada, sigue pidiendo eds incondicional en las mismas líneas. Las reales, todas incondicionales y de nivel superior (:71-89): atk-bridge-2.0 (at-spi2-core), libecal/libedataserver (eds), gcr-4, libxml-2.0 (ya sellada), polkit-agent-1. Costo de la cima: ~10 recetas nuevas dominadas por eds+icu. Es una campaña, no una tanda. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
7ebc5c51e8 |
gnome onda 3: g-s-d verificado en vivo — el muro GTK3/X11 sigue en 48.1, y no bloquea el escritorio
El comentario decía por lectura del meson.build lo que ahora dice un build corrido: el configure muere antes, en geocode-glib-1.0 (:100), y las de GTK3/X11 vienen enseguida y siguen incondicionales (gtk+-3.0 :106, gtk+-x11-3.0 :107, x11 :116, xfixes :117). Cerrar geocode-glib sólo movería el muro cuatro líneas. Aparcada junto con gnome-session. Lo que faltaba decir: gnome-shell no depende de g-s-d ni en build ni para arrancar. Sin él la sesión sube igual y se pierden teclas de medios, energía y perfil de color. Degradación, no ausencia. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |