96855001c6e9276014d68fc9f9f85ec765673e28
789
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Sergio
|
96855001c6 |
licencias: 96% (1124/1164) — --fetch para los tarballs que no estaban en caché
Ocho paquetes más (giflib, pcre2, nghttp2, libogg, libvorbis, speexdsp, libuv, tea) con la misma
regla de evidencia. Su tarball no estaba en `work/tarballs/`, así que el modo `--fetch` lo baja a un
temporal, lo verifica contra el sha256 QUE LA RECETA PINEA —o es el árbol exacto o no se mira— y lo
borra. No se escribe en la caché de hammer a propósito: es suya, y un fichero puesto ahí por otro
camino es una vía de envenenamiento que nadie audita.
Dos correcciones al criterio, las dos porque produjo una afirmación falsa:
· `gmp` salía GPL-3.0-or-later. Su `COPYING` es la GPLv3, pero al lado trae `COPYING.LESSERv3` y
`COPYINGv2` porque la biblioteca es LGPL. La regla anterior —«el `COPYING` a secas gana al
sufijado»— arregla socat, cuyo `COPYING.OpenSSL` es una excepción, y rompe gmp, donde el extra
nombra otra VERSIÓN y no una dep. Esa diferencia es demasiado fina para codificarla sin
equivocarse, así que ahora se identifican TODOS los ficheros de la raíz y sólo hay veredicto si
dicen lo mismo. gmp, ffmpeg y los tres `gi-*` quedan pendientes, que es lo correcto: en ffmpeg
la respuesta ni siquiera está en el árbol, la deciden los flags de la receta.
· Pero «varios ficheros» no es «ambigüedad»: el `COPYING` de pcre2 son dos líneas apuntando a
`LICENCE.md`, y los dos dicen BSD-3. Por eso se unen las identificaciones en vez de contar
ficheros — ambiguo es que digan cosas DISTINTAS.
Y el TSV pasa a ser ACUMULATIVO. Una receta ya sembrada sale del conjunto de entrada porque ya tiene
`license`, así que regenerar el fichero entero borraba su cita — y la cita es el rastro de
auditoría, lo único que deja revisar un veredicto sin repetir el trabajo. Un fichero de evidencia
que se olvida de lo que ya probó no es evidencia.
Los 10 ArtifactHash afectados, idénticos antes y después.
|
||
|
Sergio
|
ba1fb2d3a8 |
licencias: 95% (1114/1164) — la evidencia sale del tarball pineado, offline
`licencias.sh --sembrar` escribe desde una tabla curada a mano y `licencias-desambiguar.sh` resuelve
`-only` vs `-or-later` preguntándole a la búsqueda de código de GitHub. Los dos dejan fuera lo mismo:
lo que nadie curó y lo que no vive en GitHub.
Pero `work/tarballs/` indexa cada tarball por su sha256, así que el árbol EXACTO que la receta pinea
ya está en disco: la declaración del propio autor, en el commit que construimos, sin red. De las 76
sin licencia, 55 tenían su tarball cacheado y 25 salieron con evidencia citable.
`scripts/licencias-tarball.py` la busca en tres niveles: la declaración del autor (`Cargo.toml`,
`meson.build`), un único fichero en `LICENSES/` (REUSE, que usa KDE), y el texto del COPYING más la
CONCESIÓN buscada en las cabeceras de los fuentes — excluyendo COPYING/LICENSE, porque el apéndice
de la GPL trae literalmente «or (at your option) any later version» y buscarla ahí da siempre
positivo siendo plantilla. Es la regla que ya fijó `licencias-desambiguar.sh`, aplicada al árbol
pineado en vez de a GitHub.
La primera versión resolvía 40, y CUATRO estaban mal. Las dejo escritas porque son la forma del
error, no accidentes:
· `socat` salía BSD-2 por su `COPYING.OpenSSL`, que es la excepción, no la licencia. Un `COPYING`
a secas gana ahora a cualquier sufijado.
· `pigz` salía Apache-2.0 por `zopfli/COPYING`: la licencia de una pieza VENDORIZADA leída como la
del contenedor. Sólo se mira la raíz.
· `openssh` salía MIT porque su `LICENCE` es un compendio de cuatro y me quedaba con la primera
que pegara. Si el texto trae varias, no hay veredicto: lo compone un humano.
· `nano` salía GPL-3.0-**or-later** citando el «either version 2» de su `aclocal.m4` — plantilla de
autotools, no del proyecto, y encima de otra versión. Ahora la cita tiene que venir de un fichero
del autor Y hablar de la misma versión mayor que el COPYING.
Y dos bugs míos que producían el mismo daño en silencio: la marca de BSD-3 era «Neither the name of»,
que libpcap y libzip no usan («The names of the authors may not be used to endorse») ⇒ se declaraban
BSD-2; y el mayor de versión lo sacaba de `"GPL-3.0".rsplit("-",1)[0][-1]`, que da «L», así que la
comprobación de coherencia rechazaba TODA cita válida.
La validación final no es una regex: un identificador vale si tenemos su texto en `licenses/`. La
obligación legal es acompañar el binario del TEXTO, así que un SPDX que no podemos entregar no
adelanta nada y sí crea una afirmación que no se sostiene. Eso es lo que atrapa el «GPL2+» que meson
deja escribir en `gsd-schemas` y `libgdm`, que no es un SPDX sino taquigrafía.
Nada se sembró a ojo: cada línea de `docs/licencias-evidencia.tsv` lleva la cita que la decidió, y
las 50 que quedan salen listadas con lo que SÍ se encontró en vez de rellenarse.
Comprobado que no se invalida nada: los 26 ArtifactHash afectados son idénticos antes y después
(`license` no está en `hash_inputs`) — medido, no supuesto.
|
||
|
Sergio
|
37afec380f |
firefox: MOZ_REQUIRE_SIGNING se desactiva con el valor VACÍO, no con cero
El primer intento murió en un segundo:
mozbuild.configure.options.InvalidOptionError: MOZ_REQUIRE_SIGNING takes 0 values
Es una bandera booleana: el `0` no es «falso», es un VALOR que la opción no acepta. La semántica no
se dedujo, se leyó del parser de mozbuild sacado del propio tarball
(`python/mozbuild/mozbuild/configure/options.py`):
if values == ("",): return NegativeOptionValue() ⇒ VAR= (vacío) DESACTIVA
if values == ("1",): return PositiveOptionValue() ⇒ VAR=1 activa
Y el `export` con valor vacío es justo lo que hace llegar la variable PRESENTE y vacía: desexportarla
la dejaría sin definir y volvería al default, que acá es exigir firma porque el default sale de
`milestone.is_release_or_beta and not milestone.is_esr` — 154.0 es release.
Queda escrito en la receta con las dos líneas del parser, porque «=0 no es falso» es la clase de
detalle que cuesta una hora la segunda vez que aparece.
|
||
|
Sergio
|
1dc662c48d |
atuq v0.3: página de inicio y pestaña nueva — y la firma de complementos venía COMPILADA
La página de inicio va en una extensión de sistema (`inicio@atuq.tawasuyu`) y no en una pref, porque la pestaña NUEVA no se puede redirigir con prefs desde hace años: el único mecanismo soportado es `chrome_url_overrides.newtab`. La misma pieza resuelve la home con `chrome_settings_overrides`. La página: el medallón, el nombre y una barra que decide sola. Si lo tecleado PARECE una dirección, navega; si no, BUSCA CON EL MOTOR POR DEFECTO DEL USUARIO vía `browser.search.query`. No se cablea ningún buscador: una distro que hornea su motor en la página de inicio está tomando por el usuario la única decisión que esa página debería respetar. Y dice cuál es el motor, para que la búsqueda no sea una caja negra. DOS MECANISMOS MUERTOS Y UNO VIVO, TODOS MEDIDOS: - `distribution/extensions/` (el clásico de las distros) NO instala nada: Firefox retiró el sideloading. El `extensions.json` del perfil ni lo mencionaba y el log no decía una palabra — fallo perfectamente silencioso. - `policies.json` con `ExtensionSettings` SÍ se lee (`browser.policies.applied=true` en el perfil) y falla con un error que al menos se nombra: `ERROR_SIGNEDSTATE_REQUIRED`. - Y `xpinstall.signatures.required=false` TAMPOCO alcanza. PARA SABER SI EL AUTOCONFIG SIQUIERA CORRÍA, HIZO FALTA UN TESTIGO. `defaultPref` no deja rastro en `prefs.js` (sólo se guarda lo que difiere del default), así que un `.cfg` que no se ejecuta es INDISTINGUIBLE de uno que sí y no hace nada. `atuq.cfg` ahora escribe `atuq.autoconfig.ok` como pref de USUARIO, legible desde fuera sin abrir el navegador. Salió `true` ⇒ el .cfg corre, y la pref de firma se estaba ignorando: la exigencia viene COMPILADA. El default de `MOZ_REQUIRE_SIGNING` sale del MILESTONE (154.0 es release), no del canal — el nuestro es `default` y aun así estaba activa. De ahí `export MOZ_REQUIRE_SIGNING=0` en firefox.toml, con su precio escrito: este Firefox deja de exigir la firma de Mozilla para CUALQUIER complemento. La alternativa es firmar en AMO —cuenta y revisión de Mozilla por versión—, que es la dependencia externa que esta distro existe para no tener. Y no es un desvío: sin esto, el `sct` del SDD 26 §6.1 tampoco se podría shipear nunca. La prueba se hizo SIN reconstruir: se montó el `.cfg` con el testigo por encima del artefacto con `--ro-bind`, en vez de editar un hardlink del store (que habría corrompido el artefacto sellado). |
||
|
Sergio
|
082246da84 |
atuq: la marca de verdad — el zorro en medallón, y la paleta muestreada del propio logo
El operador pasó un tablero de identidad: zorro en medallón con cenefa andina, disco teal, anillo noche. Se adapta la FORMA y el COLOR. Los eslóganes NO — los descartó explícitamente, y de todos modos `brand.ftl` no es sitio para copy: lleva el nombre y nada más. EL ICONO DEJA DE DIBUJARSE EN CÓDIGO. Hasta la v0.2 `rebrand.py` generaba una marca geométrica en Python puro, con el argumento de que un PNG en el árbol no se puede revisar en un diff. Ese argumento valía mientras el icono era un marcador de posición inventado por falta de arte. Ya hay arte, así que el criterio se invierte: un asset de diseño ES la fuente, no un derivado. Lo que se conserva es la disciplina — los seis tamaños salen del MISMO master (recorte del medallón con máscara circular y alfa, LANCZOS desde 1024 px), se generan una vez y se copian, así que dos builds ponen los mismos bytes. LA PALETA SE MIDIÓ, NO SE ESTIMÓ. Los cuatro tokens salen del color más frecuente de cada zona del medallón: #c15728 el zorro, #1b6470 el disco, #04161d el anillo, #f5ecde los reflejos. Escribirlos «parecidos» a ojo es cómo una identidad se desalinea de su propio logo en tres ediciones. Con eso el CSS suma `accent-color` —un solo cambio alcanza decenas de widgets nativos del chrome sin enumerar ninguno— y el fondo de la barra de pestañas verticales, para que marco e icono cuenten lo mismo. ⚠ Anotado y no escondido: a 16 px el medallón pierde el detalle y queda como una mancha cálida redonda. Es intrínseco a un logo con cenefa; la salida sería un dibujo simplificado para ese tamaño y lo decide quien dibujó el zorro, no este script. Construido y sellado EN LOCAL en 3 segundos (b3:97328d1c), hidratado y abierto: 8 procesos vivos, anunciándose como `(atuq:9581)`. |
||
|
Sergio
|
5d06a3b83d |
atuq ABRE: el app_id estaba compilado en el binario, y el árbol copiado llegaba de sólo lectura
Con la cadena GTK3 arreglada, atuq arrancó de verdad: parent vivo, CERO procesos de contenido muertos, y pintando una página local. Quedaban dos cosas. 1. SE ANUNCIABA COMO `firefox-default`. El application.ini decía RemotingName=atuq y aun así el proceso se presentaba así — porque esa cadena es un MOZ_APP_REMOTINGNAME horneado en el ELF, y es la que Gecko pasa a g_set_prgname(), o sea el **app_id de Wayland**. Consecuencia visible: el escritorio no casaba la ventana con nuestro .desktop (StartupWMClass=atuq) ⇒ icono genérico y sin agrupar. Se parchea EN SITIO, no recompilando: cambiarlo en recipes/firefox.toml brandearía la BASE como atuq, y firefox tiene que seguir siendo firefox para los otros forks. Es seguro porque es una cadena C terminada en NUL en el pool de .rodata —`firefox-default\0` son 16 bytes exactos y se escriben 16—, y se EXIGE una única ocurrencia: si upstream la duplica o la renombra, falla en vez de parchear el sitio equivocado. Verificado después: 0 ocurrencias de la vieja, y el log dice `(atuq:26423)`. 2. UN BUG QUE SÓLO SE VE FUERA DE ROOT. `cp -a` preserva los modos y los ficheros del store están sellados sin permiso de escritura; todo lo que viene después los modifica. En el worker pasaba inadvertido porque corre como root, que ignora los bits. El primer build local murió con `PermissionError: /out/usr/lib/atuq/application.ini`. Se arregla con `chmod -R u+w` en la receta y no en el entorno: un artefacto no debe depender de con qué uid lo construiste. Y el runner pasa a hidratar las variantes `-shared`: en runtime una `.a` no sirve de nada, y son las que gtk3 declara NEEDED desde el arreglo del cuadro de las dos Pango. Este atuq se construyó EN LOCAL en segundos, que era la promesa entera del diseño derivado del SDD 26: iterar el envoltorio sin volver a pagar un build de Gecko. |
||
|
Sergio
|
a828e74c40 |
la cadena GTK3 se enlazaba estática dentro de dos .so: cuatro variantes -shared y xkeyboard-config al corpus
Con `atk` arreglado, atuq llegó más lejos y murió igual, ahora con Pango:
GLib-GObject-CRITICAL: cannot register existing type 'PangoFontMap'
… decenas de líneas … tipo '<invalid>'
MISMO CUADRO, CULPABLE DISTINTO Y MÁS GRANDE. `gtk3` produce DOS objetos compartidos —libgtk-3.so y
libgdk-3.so— y libxul declara NEEDED las dos, así que se cargan siempre juntas. Con las variantes
ESTÁTICAS de sus deps, cada una se llevaba adentro su propia copia. Medido con el mismo instrumento
que cazó a atk, `nm -D --defined-only`, preguntando quién DEFINE cada símbolo:
pango_font_map_get_type → libgdk-3.so, libgtk-3.so, libgailutil-3.so
cairo_create → libgdk-3.so, libgtk-3.so
gdk_pixbuf_get_type → libgdk-3.so, libgtk-3.so
hb_buffer_create → libgdk-3.so, libgtk-3.so, libgailutil-3.so
Y se comprobó el otro lado: libxul NO embebe ninguna —enlaza libgtk-3/libgdk-3 como debe—, así que
la duplicación es toda interna del par GTK3.
Cuatro variantes nuevas: harfbuzz-shared, cairo-shared, gdk-pixbuf-shared, pango-shared. Sólo cambia
el modo de librería; se conservan todos los switches del canónico para no arrastrar deps nuevas.
DOS DEUDAS ANOTADAS, NO OLVIDADAS: `fribidi` y `pixman` siguen estáticos —no existe variante— pero
quedan embebidos en UNA sola .so cada uno, así que no hay copia que colisione; y `libepoxy` sí queda
en las dos, y se deja porque no registra tipos de GObject ni mantiene estado global. Si algún día
otra .so del mismo proceso los embebe, vuelve el cuadro.
`firefox` swapea las mismas cuatro: declarar las ESTÁTICAS junto a un gtk3 que trae las compartidas
son dos artefactos peleando por el mismo `pango.pc`, que es la otra forma conocida de este fallo.
Y `xkeyboard-config` SUBE AL CORPUS. Existía idéntica en las cuatro colas de escritorio (un solo md5
entre las cuatro, verificado antes de mover) y atuq, que vive en el corpus, no podía alcanzar
ninguna: sibling-first y después el catálogo padre, nunca una cola hermana. Sin sus datos el
navegador ni pinta («xkbcommon: failed to add default include path /usr/share/X11/xkb»). Mismo hash
en el corpus que en las colas ⇒ cero rebuilds, y las copias de las colas se quedan donde están.
|
||
|
Sergio
|
0f7d19232e |
atuq: el lanzador deja de ser un symlink, y un runner para abrirlo en la pantalla que ya tenés
Dos cosas que salieron de intentar ABRIRLO, que es lo único que distingue «sellado» de «usable».
1. EL LANZADOR. Con `/usr/bin/atuq` como symlink, el navegador moría antes de pintar:
XPCOMGlueLoad error for file /usr/lib/atuq/libmozsandbox.so:
Error loading shared library libnspr4.so: No such file or directory
El motor carga sus propias librerías desde `/usr/lib/atuq` y ni el binario ni esas `.so` traen
RPATH/RUNPATH — comprobado con `readelf -d`, no supuesto. Pasa a ser un script que exporta
`LD_LIBRARY_PATH` (lo mismo que hacen Debian y Fedora) y hace `exec`, para que el proceso que
queda sea el motor y `/proc/self/exe` siga resolviendo el appdir. El `LD_LIBRARY_PATH` además
tiene que HEREDARSE: Firefox lanza un proceso por pestaña y todos cargan las mismas librerías.
La alternativa limpia es grabar RPATH=$ORIGIN con `patchelf` —es lo que hace Alpine— pero
`patchelf` todavía no existe como receta del corpus; cuando exista, esto vuelve a ser un symlink.
2. `scripts/atuq-nested.sh` — hidrata el cierre de runtime y abre atuq como ventana anidada en el
compositor que ya está delante (waypipe, mirada, sway). Trae dos cosas aprendidas a golpes:
· EL ROOTFS VA EN EL MISMO MOUNT QUE EL STORE. `hydrate` proyecta con hardlinks y `linkat()`
rechaza cruzar un punto de montaje aunque sea el mismo filesystem. Acá el store es /dev/sdb
bind-monteado y `work/` vive en /dev/sdc: hidratar a `work/…` muere con «Invalid cross-device
link (os error 18)». El volumen entero está en /mnt/cosecha, así que el rootfs va ahí. Se
comprueba con `findmnt -T`, nunca con `stat -c %d`.
· `dejavu-fonts` va en las raíces por necesidad, no por completismo: un navegador sin una sola
fuente arranca, pinta y muestra cuadraditos. Ya nos costó una tarde en GNOME.
Y no saltea en silencio: si falta un artefacto de la lista, sale con error en vez de armar un
rootfs al que le faltan tres paquetes y falla tres capas más abajo.
|
||
|
Sergio
|
c9c6727c3b |
atk: a las variantes -shared — su .so llevaba una copia entera de GObject adentro
Al abrir el primer atuq en pantalla, murió así:
GLib-GObject-CRITICAL: cannot register existing type 'gpointer'
… 45 líneas iguales … Segmentation fault (exit 139)
El síntoma no nombra a atk por ningún lado, y las dos glib no estaban como dos ficheros en el
rootfs —había UNA sola libgobject—. La segunda copia estaba EMBEBIDA: `atk` declaraba la variante
ESTÁTICA de glib y produce un objeto compartido, así que el enlazador le metió GObject entero
dentro de `libatk-1.0.so`. Todo proceso que cargue atk y libgobject a la vez —o sea cualquier app
GTK— acaba con dos sistemas de tipos peleando.
SE ENCONTRÓ MIDIENDO, NO LEYENDO: `nm -D --defined-only` sobre cada `.so` del rootfs, buscando
quién DEFINE `g_type_register_static`. Dos respuestas: `libgobject-2.0.so`, que debe, y
`libatk-1.0.so`, que no.
Es la regla que el corpus ya tenía escrita desde GTK4 y que esta receta se saltó: las deps de una
`.so` van a las variantes `-shared` EN LUGAR DE las estáticas, nunca junto a ellas.
RADIO MEDIDO ANTES DE TOCAR (`yupana radio atk`): 4 transitivos, 3 sellados caen a deuda —
atk, gtk3 y firefox. GNOME NO está en el radio: usa gtk4. El costo es un rebuild de firefox de
cuatro horas, y no hay forma de esquivarlo: sin esto el navegador no abre.
Esto es «sellado ≠ usable» otra vez, y la única razón por la que apareció es que alguien lo ABRIÓ
en una pantalla. La clausura decía 100%.
|
||
|
Sergio
|
1728fd65e5 |
firefox NO reproduce bit a bit: el BuildID es la fecha del build — medido y anotado, no arreglado de paso
Al abrir `application.ini` para el branding de atuq apareció esto:
BuildID=20260905035306
Es la fecha y hora del build. Dos construcciones de la MISMA receta, con el mismo ArtifactHash,
producen bytes distintos. Es justo el agujero que el invariante de reproducibilidad existe para
cerrar, y no se ve en `build-state.json` porque el hash es input-addressed y no se mueve por esto.
El arreglo es conocido y lo usa Alpine: exportar `MOZ_BUILD_DATE` con un valor determinista.
NO se aplica de paso, a propósito: vive en una FASE, así que re-hashea la receta y cuesta otro build
de cuatro horas más el re-sellado de atuq, que cuelga de ella. Es su propia unidad de trabajo y
queda como 4.c en el plan del SDD 26.
El comentario se comprobó que NO mueve el hash antes de commitearlo (b3:aa90192a antes y después):
un comentario fuera de las fases no entra en `hash_inputs`, así que el firefox sellado sigue válido.
Y el §2.ter del SDD queda con el estado real de atuq v0.2 y su evidencia.
|
||
|
Sergio
|
6f6c32bb9d |
atuq 0.2.0: branding real — el zip, el .ini, los binarios y un icono que no es de otro
Hash b3:7eff4ba4. La v0.1 dejó el branding fuera porque había que MIRAR el árbol antes de adivinar. Se miró, y lo que apareció decidió la forma de esta versión: - `application.ini` del appdir arranca diciendo «This file is not used». Es herencia del árbol de desarrollo: en un build empaquetado el launcher SÍ lo lee. `rebrand.py` no le cree al comentario: comprueba que las claves estén y falla si no. - Las cadenas que la gente VE están DENTRO de `browser/omni.ja` ⇒ sin re-empacar el zip no hay branding. Y el original no dice «Firefox», dice **Nightly**, porque construimos con `--with-branding=unofficial`. Sin tocarlo, atuq se presentaría como lo peor de los dos mundos. - Los ICONOS, en cambio, viven FUERA del zip ⇒ se reemplazan sin abrirlo. EL RE-EMPAQUE PRESERVA TRES PROPIEDADES DEL ORIGINAL, Y CADA UNA POR UNA RAZÓN MEDIDA: orden de las 5306 entradas (es el que Gecko lee al arrancar, y es lo que el jarlog del PGO va a refinar), `compress_type=0` (Mozilla lo deja SIN COMPRIMIR para poder mapearlo) y `date_time` 2010-01-01 (ya venía normalizado: Mozilla también persigue reproducibilidad). VERIFICADO CONTRA EL ARTEFACTO, NO CONTRA EL LOG: - diff entrada por entrada entre el omni.ja de firefox y el de atuq: **5306 → 5306, mismo orden, todo STORED, mismas fechas, y UNA SOLA entrada con contenido distinto**: brand.ftl. - re-empacar dos veces el mismo zip da el mismo sha256 ⇒ el paso es determinista. - application.ini: Vendor=tawasuyu, Name/RemotingName/CodeName=atuq. `ID` NO se toca: es el GUID con el que las extensiones declaran compatibilidad, y cambiarlo dejaría a atuq fuera del ecosistema de complementos. EL BuildID SE DERIVA DEL CONTENIDO DEL OVERLAY, no de la fecha. Es la clave con la que Gecko invalida su startup cache: si atuq cambia su chrome y el BuildID no se mueve, el navegador arranca con la interfaz vieja cacheada y PARECE que el overlay no agarró. Derivarlo del contenido lo mueve exactamente cuando hace falta y dos builds del mismo atuq dan el mismo número — con la fecha pasaría lo contrario en los dos sentidos. Se vio funcionar: al sumar `CodeName` el BuildID cambió solo, de 81921491609672 a 24128696592342. El icono se DIBUJA en código (PNG en Python puro, zlib + struct) y no se commitea como binario: un PNG en el árbol no se puede revisar en un diff, el código sí, y el resultado es idéntico en cada build. ⚠ Es un marcador de posición declarado —una marca geométrica plana, 5 tamaños—; lo correcto es que alguien dibuje el zorro. Su única función irrenunciable ya la cumple: que la ventana y el lanzador NO muestren el icono de otro producto. Binarios: firefox → atuq y firefox-bin → atuq-bin, con symlink `firefox` → `atuq` dentro del appdir porque hay scripts de terceros que invocan por el nombre histórico y Gecko resuelve su directorio por /proc/self/exe (entrar por el symlink resuelve al mismo sitio). Más `.desktop` con StartupWMClass=atuq, que casa con el app_id que da RemotingName bajo Wayland. |
||
|
Sergio
|
aeebb194dc |
atuq 0.1.0: la receta del envoltorio, derivada de firefox
Primera receta del navegador de la distro (SDD 26). No compila nada: depende de `firefox`, copia su árbol y le pone encima cuatro ficheros. Hash b3:2d6e4dcf. LA CAPA SON CUATRO FICHEROS Y CADA UNO ESTÁ DONDE ESTÁ POR UNA RAZÓN: - `defaults/pref/autoconfig.js` — el único gancho que corre ANTES de que exista un perfil. - `atuq.cfg` — prefs de fábrica + carga del chrome. Con `defaultPref` y no `lockPref`: son valores de arranque, no una cárcel; lo que de verdad se bloquea va en policies.json. - `chrome/atuq.css` — el aspecto. - `distribution/policies.json` — telemetría, updates, primer arranque. POR QUÉ EL CSS NO ES `userChrome.css`: ese fichero vive en el PERFIL y exige que el usuario prenda `toolkit.legacyUserProfileCustomizations.stylesheets`. atuq tiene que verse como atuq en el primer arranque, con un perfil recién creado, sin que nadie prenda nada. El único gancho a nivel de APLICACIÓN es nsIStyleSheetService desde autoconfig — y llegar a él es la razón de `sandbox_enabled = false`. Se registra como USER_SHEET, el mismo nivel de cascada que userChrome, para que el usuario pueda seguir pisándolo. DOS TRAMPAS DEL FORMATO, ESCRITAS EN EL PROPIO FICHERO: - la PRIMERA LÍNEA de un autoconfig se ignora siempre, por diseño (herencia de Netscape). Código en la línea 1 no corre y no da error: el fallo más caro de ese fichero es el que no dice nada. - el CSS va acotado con @-moz-document a browser.xhtml. Una hoja USER sin acotar alcanza CUALQUIER documento chrome —visor de PDF, inspector, diálogos— y un selector como `toolbar` termina pintando ventanas que nadie miró. `extensions.autoDisableScopes = 0` es la otra mitad del `--with-unsigned-addon-scopes` que ya viaja en el build de firefox: sin los dos, las extensiones de la distro se instalan DESACTIVADAS. LAS ASERCIONES VAN PRIMERO Y FALLAN RUIDOSAS. Un derivado que no encuentra su base produciría un directorio con cuatro ficheros de config, `Store::has` lo daría por presente y el fallo aparecería el día que alguien abra el navegador (regla 3 del CLAUDE.md). Y al final imprime el inventario de la capa con sus tamaños, que es la primera pregunta del diagnóstico cuando «atuq se ve como Firefox». LO QUE LA v0.1 NO HACE, A PROPÓSITO: no renombra el binario ni toca application.ini, y no re-empaqueta omni.ja. Las dos cosas necesitan mirar la forma real del árbol que selle `firefox`, y adivinarla desde acá daría un artefacto que arranca en una máquina y en ninguna otra. No se puede construir todavía: su dep `firefox` está en vuelo. |
||
|
Sergio
|
6dbe17f87d |
firefox: fuera clang18 y llvm18 — una dep del corpus tapaba el llvm-ar del lab
Primer build con clang+ThinLTO: murió a los 4 minutos, y el error nombra las dos versiones, que es
lo que lo hace diagnosticable de un vistazo:
/usr/bin/llvm-ar: error: …log.o: 'Unknown attribute kind (102)'
(Producer: 'LLVM22.1.8' Reader: 'LLVM 18.1.8')
`clang18` y `llvm18` estaban en [deps].build de cuando esta receta compilaba con gcc: aportaban el
libclang para bindgen y la suite llvm-ar/llvm-objdump que Mozilla exige. Con `compiler = "clang"` se
volvieron ACTIVAMENTE DAÑINAS: una dep del corpus se materializa en el sandbox y TAPA el binario del
lab, así que llvm-ar pasó a ser el de LLVM 18 con un compilador clang 22. Mientras los .o eran
objetos no se notaba; con ThinLTO son BITCODE, y el bitcode no es compatible hacia atrás.
Misma forma que la lección de los headers UAPI: una dep tapa al lab y el fallo aparece lejos del
sitio que lo causó.
El arreglo no es apuntar AR a mano, es no traer el 18: el lab ya expone
/usr/bin/llvm-{ar,objdump,profdata} → llvm22 y /usr/lib/libclang.so → llvm22 (paso 3a-ter del
bootstrap). Es además lo que hace Alpine: clang22 + clang22-libclang, sin un segundo LLVM en la mesa.
Y llvm-profdata del 22 es el que va a hacer falta para el PGO.
Nuevo ArtifactHash: b3:aa90192a141f9fc6d2b59acd074db6caa36854af7100fb08fb51c8fe441b72b7
|
||
|
Sergio
|
fe940887bf |
waterfox aparcada: no falló por los parches, le falta browser/locales en el clon
Primer intento en el worker: murió en CUATRO SEGUNDOS, no en cuatro horas. `mach build` abortó con «FATAL ERROR PROCESSING MOZBUILD FILE» sobre browser/moz.build porque referencia browser/locales/moz.build y ese fichero NO ESTÁ en el árbol traído. Lo que eso significa, y es la parte que vale: LOS ONCE PARCHES DE MUSL SÍ AGARRARON. La apuesta explícita de esta receta —reusar los parches de 154 sobre un árbol 153.1.0— no es lo que falló. Lo que falla es el FETCH: falta un trozo del árbol. Sospechoso número uno el `--filter=blob:none` contra cómo BrowserWorks compone su repo, no la receta. Se aparca por decisión del usuario: la prioridad pasa a firefox con la cadena de optimización y a atuq (SDD 26). El primer paso al retomarla es un `git ls-tree` del commit pineado, no un build. |
||
|
Sergio
|
cb3ecd5a00 |
firefox pasa a clang+lld con LTO: la puerta de las optimizaciones costaba apk add lld, no una receta de LLVM
El SDD 26 estimó que habilitar PGO/LTO exigía una receta `llvm-toolchain` (clang+lld+libc++ desde fuente). ERA CARO DE MÁS. Al mirar el lab en vez de suponerlo: - `.dev-fs/alpine` YA TRAE clang22 + llvm22 22.1.8 — la MISMA major que usa el APKBUILD de Alpine para este mismo Firefox (`_llvmver=22`). - `Compiler::Clang` YA EXISTE en hammer, cableado de punta a punta: `parse_compiler` lo acepta y `hammer-build/src/lib.rs` pone CC=clang, CXX=clang++ y AR=llvm-ar. NINGUNA receta lo usaba. - Lo único que faltaba era `ld.lld`. `apk add lld` ⇒ lld22 22.1.8, dos paquetes, cero upgrades. CON ESO CAEN LOS TRES MUROS QUE OBLIGABAN A gcc, sin perder lo que gcc daba: el sondeo de linker se satisface con `--enable-linker=lld`, el `ar` lo pone hammer solo, y el `NEEDED` de la stdlib de C++ existe porque clang++ de Alpine usa la libstdc++ COMPARTIDA — la prueba no es teórica, Alpine construye este Firefox con clang22 y sin libcxx en sus makedepends. LA HUELLA DEL LAB NO SE MOVIÓ, Y SE MIDIÓ ANTES DE TOCAR NADA. `lld` no casa ningún prefijo de TOOLCHAIN_PREFIXES (hammer-core/src/lab.rs), así que los 43 paquetes que entran en `hash_inputs` salieron idénticos ⇒ los 837 artefactos sellados quedan intactos. Eso es lo que hace barato el cambio HOY, y a la vez es un agujero escrito en los dos sitios: la versión de lld no es parte de la identidad del artefacto, y sólo expone a las recetas `compiler="clang"`, que hoy es una. Meter "lld" en la lista de prefijos es lo correcto y cuesta re-hashear el corpus entero: próxima campaña. En el mozconfig entran, además de lld: `--enable-lto=cross`, `--enable-packed-relative-relocs` y `--with-unsigned-addon-scopes=app,system`. El último no es cosmético: sin él un Firefox de release rechaza las extensiones que la distro deja en distribution/extensions/, así que la capacidad de atuq de shipear su propio `sct` se decide ACÁ, en la base, y no en el overlay del derivado. PGO no entra en esta pasada y el porqué queda escrito en la receta: el perfil se junta corriendo el navegador (Alpine y Arch usan xvfb-run; nosotros no tenemos X11 ⇒ sway headless) y el profdata NO es determinista, así que tiene que sellarse como artefacto propio y consumirse por hash. ThinLTO se capa con la misma cuenta que -j y por la misma razón que ella no es un literal: un número fijo ataría el ArtifactHash a la RAM de quien escribió la receta. Nuevo ArtifactHash: b3:6f2a3b2f6db4452ed0d2d3f4e2ff7cd6562a86878d4360653859720be1c3d94d (el firefox 154.0 sellado con gcc queda SUPERADO, no perdido). |
||
|
Sergio
|
a221300c30 |
waterfox 6.7.1.1 (Gecko 153.1.0) — el primer fork, y la prueba de la tesis del reúso
Waterfox es un fork de Gecko con árbol propio, así que consume EXACTAMENTE la misma plataforma que Firefox (gtk3, nodejs, clang18, cbindgen, variantes -shared) y hereda los seis muros ya resueltos sin volver a pagarlos: sin --enable-linker, compiler=gcc, RUST_TARGET, vaciado de checksums vendorizados, strip_debug y el build hermético. Medido con diff ignorando comentarios: las diferencias REALES con firefox.toml son TRES — la fuente, el branding y la versión. Si aparece una cuarta, conviene preguntarse si no debería estar en las dos. LA BASE ES 153.1.0 y los parches son de 154, una release por encima. Se reutilizan igual porque el código que tocan (LFS64, time64, prctl, sandbox) se mueve poco entre releases, pero es una apuesta EXPLÍCITA y no un hecho: si patch falla, falla temprano —antes de compilar nada— y el arreglo es rebasar el que se queje. ACÁ SÍ VA BRANDING OFICIAL, y no contradice a firefox.toml: allá va sin marca porque el nombre y el logo de Firefox sobre un binario parcheado entran en la política de marcas de Mozilla; acá browser/branding/official ES la marca del propio Waterfox, que BrowserWorks distribuye en su árbol para que se construya así. Fuente por commit y no por el tarball_url de GitHub, que es /archive/-style y se genera al vuelo. hammer clona con --filter=blob:none, así que el árbol Gecko no trae historia. |
||
|
Sergio
|
141eb9afd7 |
firefox: vaciar el checksum de los 5 crates vendorizados que tocan los parches
Sexto muro: «error: the listed checksum of third_party/rust/zeitstempel/src/unix.rs has changed». Los crates de Rust vienen VENDORIZADOS en el tarball y cargo verifica el sha de CADA fichero contra .cargo-checksum.json; en cuanto un parche de musl toca uno, el build muere. Cargo no ofrece forma de recalcularlo, así que la salida —la misma del APKBUILD de Alpine— es vaciar la lista de ficheros del manifiesto dejando el checksum del paquete. Se hacen los CINCO de una (audio_thread_priority, cc, zeitstempel, wgpu-hal, alsa) y no sólo el que reportó el error: cargo los destapa de a uno, y buscarlos por prueba y error costaría cinco vueltas de configure de las que cada una tarda minutos. El bucle falla RUIDOSO si un crate no está, en vez de seguir en silencio: si upstream mueve uno, quiero enterarme acá y no tres capas más abajo. |
||
|
Sergio
|
fee383ff64 |
cbindgen 0.27.0 → 0.29.4 — el configure de Firefox 154 exige >= 0.29.4
«cbindgen version 0.27.0 is too old. At least version 0.29.4 is required.»
Subir es gratis: yupana radio cbindgen = 0, ninguna receta la declara todavía —
es herramienta de la plataforma Gecko y nada más.
De paso pasa de tarball /archive/refs/tags/ a commit pineado. Esos tarballs los
genera la forja al vuelo y su sha256 cambia cuando el servidor actualiza git/gzip
(ADR 0006); ya que había que tocar la fuente, se deja anclada. El tag 0.29.4 es
LIGERO —una sola ref en ls-remote, sin ^{}— así que el sha ES el commit.
|
||
|
Sergio
|
c104a64462 |
firefox: RUST_TARGET — lo exige el parche de Alpine, no Firefox
Cuarto fallo de configure: KeyError: RUST_TARGET. Se lee como un bug de Firefox y es en realidad el CONTRATO del parche que trajimos: fix-rust-target.patch reemplaza la autodetección del triple de Rust por un os.environ["RUST_TARGET"] pelado, y el APKBUILD de Alpine lo exporta como $CTARGET. Traer el parche sin la variable es traer media cosa. El valor NO se adivinó: sale de ls .dev-fs/alpine/usr/lib/rustlib/ en el lab, que da x86_64-alpine-linux-musl. El rustc del sandbox es el de Alpine, no el del host — el del host es x86_64-unknown-linux-gnu y usarlo habría producido un cross-compile silencioso, que es peor que un error. Va en las TRES fases: mach lo vuelve a leer al compilar e instalar. Van cuatro muros de configure y cada uno destapó al siguiente: linker → ar → libstdc++ estática (que forzó compiler=gcc) → RUST_TARGET. |
||
|
Sergio
|
3ffca7c7fe |
firefox: pasa a compiler=gcc — zig-cc choca con una negativa de upstream
Tercer fallo de configure, y el que decide: «Firefox does not support linking statically with libstdc++». No es un flag. flags.configure:79 compila un C++ mínimo, lo pasa por llvm-objdump --private-headers y EXIGE encontrar un `NEEDED …libc++`; zig enlaza libc++ estática para musl, así que ese NEEDED no existe nunca. Es una negativa de Mozilla, no una opción. Cambiar a gcc derriba los tres muros que zig-cc levantó, de una vez: 1. el sondeo del linker (gcc se anuncia como «GNU ld», que Firefox reconoce), 2. «Cannot find ar» (hay un ar de verdad; se quitan los wrappers de zig), 3. libstdc++ COMPARTIDA — el gcc del lab es 15.2.0 con libstdc++.so.6. Es una excepción consciente y del mismo tipo que la que el repo ya mantiene para el kernel y cmake (ADR 0011), a la que se llegó por eliminación y no por comodidad: los tres intentos con zig-cc están documentados en la cabecera. ⚠ El precio queda escrito en la receta: el lab NO entra en hash_inputs, así que un Firefox construido con el gcc del lab queda más expuesto a la deriva del rootfs que uno con zig-cc — dos labs con gcc distinto pueden sellar bytes distintos sin que el store lo note. Misma deuda que ya cargan el kernel y las otras recetas compiler=gcc, y razón para no ampliar esa lista sin agotar antes el camino zig. |
||
|
Sergio
|
61143203f9 |
firefox: wrappers de ar/nm/ranlib — zig los trae como subcomandos
Segundo fallo de configure: «ERROR: Cannot find ar». moz.configure hace
check_prog("AR", …) y en el sandbox no existe un ejecutable llamado `ar`: existe
`zig ar`. Un AR="zig ar" con espacio tampoco sirve, se ejecutaría como un binario
único llamado «zig ar» — el mismo gotcha que ya documentan la receta de ffmpeg y
el de los crates cc en las recetas Rust.
Wrapper de UN SOLO TOKEN por herramienta (ar, ranlib, nm, objcopy), que es el
patrón ya establecido en el corpus, exportados en configure Y en compile porque
las dos fases los necesitan.
El linker ya pasó: este fallo es posterior, lo que confirma que quitar
--enable-linker fue correcto.
|
||
|
Sergio
|
2fd738bf82 |
firefox: quitar --enable-linker=lld — el sondeo de Mozilla no reconoce a zig
Primer intento de build: configure murió con «Could not use lld as linker».
NO era que faltara lld. toolchain.configure sondea con
`$CC -fuse-ld=lld -Wl,--version` y clasifica por la SALIDA, buscando «mold»,
«GNU ld», «GNU gold» o «LLD». zig se identifica como `zig ld 0.16.0`, que no casa
con ninguno ⇒ kind = "unknown".
«unknown» por sí solo NO rompe: el código lo acepta explícitamente. Lo que rompe
es PEDIR el linker por nombre, porque eso vuelve fatal cualquier fallo del sondeo:
if linker: result = try_linker(linker)
if result is None: die("Could not use %s as linker")
Sin el flag, unas líneas más abajo Firefox prueba lld igual —c_compiler.type es
clang y la versión 21.1.0 pasa el umbral de 15.0— y si el sondeo falla sigue a
gold y al linker por defecto, que es exactamente el lld que zig trae adentro.
Mismo linker, sin el die.
Diagnóstico hecho leyendo toolchain.configure en el árbol del worker, no
suponiendo: el comando sondeado devuelve rc=0 y sí imprime la versión cuando se
corre a mano.
|
||
|
Sergio
|
90364fabbf |
nodejs y firefox: strip_debug — medido, no supuesto
El nodejs que selló en el LXC sin strip pesa 984 MB, de los cuales .debug_info son 497 MB y .debug_line otros 43: MÁS DE LA MITAD del artefacto es información de depuración, para una herramienta que nadie va a depurar y que ni siquiera se publica. Se aplica también a firefox ANTES de construirlo, que es donde importa: Firefox es varias veces V8 y sin strip su artefacto entraría en varios GB. El store no es sólo disco — se sincroniza hub↔worker y se respalda. Es el hallazgo del SDD 23: el 79% del contenido binario del store era .debug_*, y quitarlo hace que artefactos que no reproducían PASEN a reproducir, porque lo que difería eran las rutas del árbol de build embebidas en esas secciones. El campo entra en hash_inputs a propósito (cambia el contenido) y usa zig objcopy, que siempre está en el sandbox ⇒ no agrega dep de build. Node se reconstruye. |
||
|
Sergio
|
428be5e8d1 |
firefox 154.0 — la cabeza de la familia Gecko (receta, sin construir todavía)
154 y no 155 pese a que Zen sigue 155.0.1 y Waterfox también va por release: los
parches de musl de Alpine son para 154.0, y son ONCE. Ese es el trabajo de
portabilidad que un import de nix pierde y sin el cual Firefox no compila contra
musl. Un Firefox que compila con el set probado vale más que uno con el número
correcto que no compila; y como Firefox se mueve cada 4 semanas, la paridad exacta
con Zen es una cinta de correr. Lo que se reutiliza entre los tres es la
PLATAFORMA (gtk3/nodejs/clang18/cbindgen, ya en el corpus) y este set de parches.
Subir a 155 después es un rebase, no un port.
Se traen los 11 de musl y NO los de ppc64le, loongarch ni Android: cada parche que
no hace falta es una forma más de que un rebase falle sin motivo.
TODO BUNDLEADO salvo GTK3. Alpine usa --with-system-{icu,nspr,nss,av1,libvpx,
webp,libevent} y de ésas el corpus tiene cero; Firefox las trae en el árbol.
Menos piezas móviles para el primer build, que es cuando conviene minimizar
variables.
SIN BRANDING OFICIAL, y no es descuido: el binario lleva once parches, y poner el
nombre y el logo de Firefox sobre un build modificado entra en la política de
marcas de Mozilla — es la historia de Iceweasel en Debian. Misma cautela que
dejavu-fonts-nerd con la licencia de Bitstream Vera: una fuente modificada no
puede llamarse como la original, y un navegador parcheado tampoco.
HERMÉTICO: --disable-bootstrap (su trabajo es descargar toolchains),
MACH_BUILD_PYTHON_NATIVE_PACKAGE_SOURCE=system (si no, mach arma un virtualenv con
pip y sale a la red) y MOZBUILD_STATE_PATH al árbol (por defecto escribe en $HOME,
que en el sandbox no es suyo). Los crates vienen vendorizados en el tarball.
Wayland-only heredado de gtk3 (-Dx11_backend=false) ⇒ este Firefox NO correrá como
cliente X11 ni bajo Xwayland. Escrito en las dos recetas.
|
||
|
Sergio
|
9c657efe61 |
plataforma Gecko: nodejs 24.18.1 — ./mach configure lo exige
Firefox aborta con «Could not find a Node.js executable»: lo usa para empaquetar los bundles de JS. Waterfox y Zen lo necesitan igual ⇒ al corpus con el resto de la plataforma. TODO BUNDLEADO, a diferencia de Alpine, que lo construye contra diez deps del sistema de las cuales el corpus tiene dos. La decisión de fondo: acá Node es un COMPILADOR, no software que la distro publique — entra al sandbox de Firefox y desaparece, así que el cierre chico gana al cierre puro y el precio (binario gordo, openssl bundleado que nadie expone) no lo paga ningún usuario. Si algún día se quiere PUBLICAR Node, esa es otra receta; queda avisado en la cabecera. Dos AVX-512 apagados, y los dos por la perilla que upstream mismo deja: · simdjson → SIMDJSON_AVX512_ALLOWED=0. ⚠ EN EL .h Y EN EL .cpp: la librería se distribuye AMALGAMADA y el .cpp lleva su propia copia (línea 2493), así que tocar sólo el header no sirve — y engaña, porque ninja sigue con otros objetos y el log parece avanzar. · simdutf (dentro de V8) → se antepone SIMDUTF_IMPLEMENTATION_ICELAKE 0, que es el override que habilita su #ifndef. No se pierde nada: todo el corpus va -mcpu=baseline y ambas eligen implementación en RUNTIME. CXXFLAGS NO sirve acá — GYP no lo propaga a la línea de compilación (verificado buscando el -D en el comando que ninja reportó al fallar). EL PARALELISMO SE CAPA POR RAM Y SIN ESCRIBIR UN NÚMERO. Sin cap, ninja lanza nproc+2 y muere con `job terminated due to signal 9` en el objeto 2936/4414 compilando lo que genera Torque (~2 G por job). Un `-j2` fijo ataría el ArtifactHash a la RAM de quien escribió la receta; la cuenta es un job cada 3 GiB de MemTotal, mínimo 1, tope nproc. Da 2 en momento (7,6 GiB) y 5 en el LXC (16 GiB, 6 cores) con el MISMO texto y el mismo hash. |
||
|
Sergio
|
dc8aa7367e |
plataforma Gecko: cbindgen sube al corpus
Genera las cabeceras C++ de los componentes Rust de Gecko (Stylo, WebRender) y el build de Firefox la exige. Mudanza gratis: [deps] vacío ⇒ no hay cierre que cambiar, mismo ArtifactHash (b3:bd2e6ca6) en las dos rutas, radio 0. |
||
|
Sergio
|
027d3a25ef |
plataforma Gecko: clang18 sube al corpus — bindgen necesita libclang
El build de Firefox corre bindgen sobre los headers de C++ y bindgen carga libclang.so en RUNTIME. La receta ya existía —nació en incoming-cosmic por un crate *-sys del portal, y su commit de origen dice «sólo libclang.so»— pero desde el corpus no se alcanza una cola hermana. Sin esto no hay Firefox, ni Waterfox, ni Zen. Mudanza medida ANTES, no después: sus cinco deps (cmake, samurai, python3, pkgconf, llvm18) viven sólo en el corpus, así que incoming-cosmic ya las resolvía por caída al padre y el cierre no cambia. hammer hash dio el MISMO ArtifactHash (b3:25d95279) en las dos rutas. Verificado que xdg-desktop-portal-cosmic —su único dependiente— sigue SELLADO y que la cola cosmic queda en 36/36 sin deuda: cero rebuilds. Se MUEVE y no se copia: dos ficheros para un artefacto es el cuadro de las dos glib esperando a que uno de los dos derive. |
||
|
Sergio
|
7c58f6b62e |
plataforma Gecko: atk + GTK3 Wayland-only — la base que comparten Firefox, Waterfox y Zen
GTK3 no existía en NINGUNA cola y es el único toolkit de Gecko en Linux. Como Waterfox y Zen son forks de Gecko, los tres navegadores consumen exactamente esta misma pieza: una receta sostiene a los tres. Por eso va al CORPUS y no a una cola —una receta resuelve sibling-first y después el catálogo padre, nunca una cola hermana—, que es la lección de mpv y justo lo que OBS no pudo cumplir al quedar atado a incoming-kde por Qt6. La plataforma nace bien puesta para que los tres navegadores no repitan ese error. Al medir el cierre antes de escribir, TODO estaba ya en el corpus salvo `atk`. Un ladrillo chico destrabando una pieza grande: por eso atk fue primero. WAYLAND-ONLY de verdad, no de intención: -Dx11_backend=false. A diferencia de OBS —que exigía find_package(X11) incondicional— GTK3 sí deja apagarlo, y eso saca libX11/libXext/libXi/libXrandr/… del cierre. Esa cadena vive sólo en incoming-kde y meterla en el corpus la pondría en las CINCO imágenes. Verificado en el artefacto: los .pc son gdk-wayland-3.0 y gtk+-wayland-3.0 (no hay gdk-x11-3.0), libgtk-3.so.0 no enlaza X11 ni xcb, y libgdk-3.so trae NEEDED libwayland-client/cursor/egl + libxkbcommon. ⚠ Consecuencia escrita en la receta: un Firefox contra este GTK3 no correrá como cliente X11 ni bajo Xwayland. Bajo Wayland nativo sí. Es la postura de la distro aplicada al navegador, no un accidente. Las deps van a las variantes -shared EN LUGAR DE las estáticas, nunca junto a ellas: libgtk-3.so es un objeto compartido y un .a sin PIC adentro da `relocation R_X86_64_32 against png_default_write_data`. Se sustituye y no se suma porque ambas variantes instalan los MISMOS .pc y cabeceras — declarar las dos serían dos artefactos peleando por lib/pkgconfig/glib-2.0.pc. |
||
|
Sergio
|
670a5b6b49 |
OBS Studio 32.2.2 — segunda app gráfica de usuario final, con el renderer portado a EGL
13 plugins sellados, entre ellos los que importan: linux-pipewire (captura de
pantalla en Wayland), obs-ffmpeg, obs-x264, obs-outputs (RTMP RTMP),
linux-pulseaudio/alsa y text-freetype2.
EL PORT. El glad de OBS hacía dlopen("libGL.so.1") + dlsym("glXGetProcAddressARB")
y devolvía 0 si no lo hallaba, o sea que el renderer no arrancaba: OBS estaba
atado a GLX —y por tanto a X11— aun corriendo en Wayland puro. Acá nadie publica
libGL.so.1 y el libglvnd del corpus va sin GLX a propósito. El parche carga por
libEGL.so.1 + eglGetProcAddress, que es lo que OBS ya usa para las extensiones.
Verificado en el artefacto, no en el log: libobs-opengl.so.30 tiene CERO
ocurrencias de glXGetProcAddressARB, sus NEEDED son libEGL.so.1 +
libwayland-egl.so.1, y el binario no filtra a glibc.
DÓNDE VIVE. En incoming-kde y no en el corpus porque su frontend es Qt6 y las 13
recetas Qt viven sólo en esa cola. Se midió antes de descartar el corpus: qtbase
sin X11 cierra en 26 nodos que YA están en el corpus, pero el qtbase de la cola va
xcb=ON, así que un qtbase de corpus tendría otro hash con el MISMO nombre de
artefacto ⇒ dos Qt peleando por /usr/lib/libQt6Core.so. Unificar obligaría a
apagarle xcb a KDE: radio 119.
Los símbolos indefinidos salieron por CAPAS y ninguno nombraba al culpable:
freetype (.a no PIC) → fontconfig (idem) → i2d_SSL_SESSION → inflateInit_. Las dos
primeras se arreglaron usando las variantes -shared que YA existían en el corpus;
las dos últimas con -lssl -lcrypto -lz, porque OBS resuelve curl con el FindCURL
de CMake, que toma libcurl.a por fichero y no lee su Libs.private. Un símbolo
indefinido nombra a la librería que lo USA, no a la que falta.
Huecos escritos en la receta para que no se descubran en la mano del usuario:
sin webcam (ENABLE_V4L2=OFF, libv4l2 no está en ninguna cola), sin salida MPEG-TS
(SRT/RIST ausentes) y sin scripting (falta swig). Grabar, capturar pantalla y
publicar por RTMP no pasan por ninguno de los tres.
|
||
|
Sergio
|
f3767f6361 |
corpus: pciutils-shared y mbedtls — dos deps duras de OBS
pciutils-shared: obs-ffmpeg (el plugin de codificación, sin perilla para apagarlo) hace find_package(Libpci) para identificar la GPU por su ID. La pciutils canónica va SHARED=no e instala SÓLO bin/sbin/share — provee.py confirmaba que libpci.so no lo publicaba NINGUNA cola. Patrón zlib-shared: una variante, sin mover el hash de la canónica. Verificado que NO colisionan listando los dos artefactos: la variante sólo pone usr/lib y usr/include; la canónica no pone nada en usr/lib. Rutas disjuntas conviven; rutas pisadas son el cuadro de las dos glib. Por eso el install usa el target `install-lib` y no `install`, que traería los binarios. mbedtls: obs-outputs (streaming RTMP) hace find_package(MbedTLS REQUIRED) y NO acepta OpenSSL — no hay opción en su CMake, está cableado. Va por TARBALL DE RELEASE y no por commit, que es excepción consciente al ADR 0006: mbedtls 3.6 tiene framework/ como submódulo y [source] de hammer no clona submódulos, así que el árbol llegaría incompleto. Un fichero de /releases/download/ lo sube upstream y su sha256 es estable; lo inestable es /archive/<tag>, que la forja genera al vuelo. La propiedad que el ADR exige —que la fuente sea la misma mañana— se cumple igual. PIC ON porque quien la consume es obs-outputs.so, un módulo dlopen. |
||
|
Sergio
|
99eb0071f6 |
corpus: simde 0.8.2 — libobs la exige REQUIRED
libobs/CMakeLists.txt:10 hace find_package(SIMDe REQUIRED) y linkea SIMDe::SIMDe, así que no es opcional para OBS. Sólo cabeceras, pero se instala por meson y no copiando a mano porque genera simde.pc, que es por donde el FindSIMDe de OBS lo encuentra: dejar las cabeceras sin su fichero de descubrimiento da el «está pero no lo encuentra», peor de diagnosticar que una ausencia. |
||
|
Sergio
|
c2feb3eab6 |
corpus: uthash, nlohmann-json, jansson y x264 — las 4 deps que a OBS le faltaban
Las cuatro no existían en NINGUNA cola (medido cruzando el grafo, no con grep).
Van al corpus y no a una cola porque OBS es una app que quieren las cuatro
imágenes, y una receta resuelve sibling-first y después el catálogo PADRE, nunca
una cola hermana.
Verificadas por CONTENIDO del artefacto, no por exit 0 (regla 3 del repo):
· uthash 5 cabeceras; no compila nada y la fase `compile` dice `true`
explícito, porque que una librería sea sólo cabeceras es un
hecho suyo, no un descuido de la receta.
· nlohmann-json pasa por CMake y no por un `cp` para que instale sus
nlohmann_jsonConfig/Targets.cmake: OBS hace find_package, y
copiar los .hpp a mano dejaría «está pero no lo encuentra».
· jansson libjansson.so.4.
· x264 libx264.so.165 + x264.pc, y `asm: yes` — con SIMD, que es la
lección que ffmpeg acaba de costar hoy.
⚠ jansson trajo su propia trampa: la perilla es JANSSON_BUILD_SHARED_LIBS, NO la
estándar BUILD_SHARED_LIBS de CMake (CMakeLists.txt:5, default OFF). Con la
estándar el build sale exit 0 y sella un artefacto con SÓLO libjansson.a — la
receta diciendo link="dynamic" y el artefacto estático. Se vio mirando usr/lib/
del artefacto, no el código de salida.
|
||
|
Sergio
|
666a681812 |
libglvnd 1.7.0: el GL de escritorio que a la distro le faltaba
Hasta hoy NINGUNA cola publicaba libGL.so, libGL.so.1 ni gl.pc (medido con
provee.py): mesa va -Dglx=disabled -Dglvnd=false, así que sólo había libEGL y
libGLESv2. Toda app de GL fijo compilaba —mesa SÍ instala GL/gl.h— y moría al
LIGAR. Lo destapó OBS: deps/glad linkea PUBLIC OpenGL::GL, que ES libGL.so, y eso
es un link, no un gate de configure que se pueda apagar.
SIN GLX Y SIN X11, que es lo que hace esto coherente con la distro: glvnd parte el
libGL.so.1 histórico en libGL.so.1 (GL+GLX ⇒ implica X11) y libOpenGL.so.0 (GL
pelado ⇒ no implica nada). Vamos por la segunda. Encender glx metería
libX11/libxcb/xorgproto —hoy sólo en incoming-kde— en el CORPUS, o sea en las
cinco imágenes, para servir a una sola app.
Entrega verificada en el artefacto: libOpenGL.so.0, libGLdispatch.so.0,
libEGL.so.1, libGLESv{1_CM,2}, y opengl.pc. Cero GLX.
El wrapper: meson emite `-Wl,--version-script <ruta>` con ESPACIO. Con gcc anda de
casualidad (reenvía al linker el argumento suelto que no entiende); zig-cc lo
rechaza con «unrecognized file extension». El wrapper une el par con `=`. No se
parchea upstream: el defecto es del contrato meson↔driver, no de glvnd.
⚠ Instala libEGL.so.1, que HOY la pone mesa. Mismo soname, otro dueño ⇒ mesa se
reconstruye con -Dglvnd=true en esta misma campaña, no después.
|
||
|
Sergio
|
8d48f1869f |
vaapi: mpv cierra su último hueco — decodificación por hardware
libva sube al corpus y la copia de incoming-kde se JUBILA (git mv, no copia: dos ficheros para un artefacto es el cuadro de las dos glib esperando a derivar). La mudanza fue gratis y medida antes: las cinco deps de libva viven sólo en el corpus, así que incoming-kde ya las resolvía por caída al padre y hammer hash dio el MISMO ArtifactHash en las dos rutas (b3:405c6211). libva pasa a -Dwith_wayland=yes, que eso SÍ cambia el hash. La razón está en mpv/meson.build:1464: el feature `vaapi` se requiere contra `vaapi-drm or vaapi-wayland or vaapi-x11 or vaapi-win32` ⇒ -Dvaapi=enabled a secas no habilita NADA. De los cuatro backends, x11/win32 están fuera por Wayland-only y vaapi-drm exige features[drm] de mpv, apagado porque vo=drm pide libdisplay-info. Queda vaapi-wayland, que pide libva-wayland.pc. Evidencia, no sólo sello: meson lista «vaapi vaapi-wayland» entre los features habilitados, y el binario sellado trae NEEDED libva.so.2 + libva-wayland.so.2. Radio medido antes de tocar: 2 dependientes (kpipewire, spectacle), los dos reconstruidos. Las 7 imágenes siguen en 0 en deuda. ⚠ El driver es RUNTIME (intel-media-driver / gallium VA por dlopen): que esto selle y que --hwdec=vaapi funcione en una máquina son cosas distintas. |
||
|
Sergio
|
269e8410fd | estado: cosecha granja 2026-09-04T15:02:12Z — avance del árbol KDE | ||
|
Sergio
|
814676ad26 |
ffmpeg: x86asm encendida — mpv decodificaba sin SIMD por una prohibición vencida
La receta llevaba --disable-x86asm heredado de cuando ffmpeg entró SÓLO para kpipewire (codificar un stream de escritorio, donde da igual). Para el reproductor era decodificar sin SIMD. Dos recetas —ffmpeg.toml y mpv.toml— prohibían tocarlo con la misma razón: un hash distinto dejaría DOS ffmpeg peleando por las mismas rutas en una imagen KDE, y el arreglo correcto sería «promover una sola y jubilar la de la cola». Eso ya había pasado: incoming-kde/ffmpeg.toml no existe y hay UNA sola receta ffmpeg en todo el disco. La prohibición sobrevivió a la condición que la justificaba. --x86asmexe=nasm explícito y nasm (2.16.03) a [deps].build: sin ensamblador declarado configure apagaría x86asm en SILENCIO, sellando un artefacto con otro hash y sin la SIMD que dice traer. Evidencia, no sólo sello: configure imprime «x86 assembler nasm», compila los objetos X86ASM, y libavcodec.so pasa de 12.685.744 a 14.454.288 bytes (+1,77 MB). Radio medido antes de tocar (yupana radio ffmpeg): 4 dependientes, ninguno transitivo de más — mpv, wf-recorder, kpipewire, spectacle. Los 4 reconstruidos y sellados; las 7 imágenes siguen en 0 en deuda. |
||
|
SergioandClaude Opus 5
|
02e93a02ea |
raíz sucia: 945 ficheros de perl en /, con guardián que nombra al culpable y el número que difiere el arreglo
Hidratando el rootfs de sway aparecieron 945 ficheros sueltos en la raíz — `AnyDBM_File.0`,
`App::Cpan.0`, … Son las páginas nroff de perl: su `Configure -des` no encuentra nroff, elige
`man1ext='0'` y `man1dir=' '` (la convención de perl para «no instales man»), pero `installman` las
GENERA igual y con el directorio vacío `make install DESTDIR=/out` las deja en `/out/`.
Ninguna métrica sobre recetas puede ver esto: hay que hidratar un rootfs de verdad y mirarlo.
El guardián va en `hydrate-profile.py` y mira **por artefacto**, no sobre el árbol fundido: en el
árbol fundido el nombre del culpable ya se perdió y 945 ficheros en `/` no se parecen en nada a
«una fase install con el destino vacío», que es lo que son. Barrido el store entero: **perl es el
único** — `.times`/`.dmerge` son internos del store y `product-rootfs`/`seed-zig` son especiales.
El arreglo es UNA línea (`-Dman1dir=… -Dman3dir=… -Dman1ext=1 -Dman3ext=3`) y NO se aplica hoy:
yupana radio perl → transitivos 347 · sellados que CAEN a deuda 305 · TODAS las imágenes
305 rebuilds para mover páginas de man de sitio no se paga solo. Queda escrito en la receta para ir
con el próximo bump de perl, cuando el re-hash ya esté pagado. Comprobado que el comentario NO entra
en `hash_inputs`: el ArtifactHash es idéntico antes y después (b3:1af26f6b).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CGyBj4QyeCZiwLMkP9GJp6
|
||
|
SergioandClaude Opus 5
|
8c4e1a6b24 |
cursores: cosmic y sway corrían con el puntero INVISIBLE — receta propia, y el vigía medía mal
`vigia-imagen.py` daba ✗ en cursores en DOS de los cuatro escritorios. No es cosmético: con el cursor por software —obligatorio en virtio-gpu y en todo render por CPU— el compositor dibuja la imagen que le da el TEMA, y sin tema el ratón se mueve invisible. cosmic llegó a 43/43 y sway a 173/173 así, porque un tema de cursor no es dep de build de nadie: sólo entra si se DECLARA. `adwaita-cursors` (corpus, 48.1, data-only): del mismo tarball que `adwaita-icon-theme` pero SÓLO `Adwaita/cursors/` — 39 ficheros y 14 MB, sin un icono. Promover el tema entero habría regalado a sway y a cosmic los iconos de GNOME, que está anotado como decisión pendiente y no como olvido. Las dos cosas que el tarball no trae y la receta fabrica: · los nombres X11 heredados (`left_ptr`, `xterm`, `watch`, `hand2`…) son enlaces que genera el `meson.build` de upstream. El mapa se PARSEA de ahí, no se copia: copiado envejece en silencio. Si el origen de un enlace no existe, la fase falla — upstream pone un `files()` como aserción. · `/usr/share/icons/default/index.theme` con `Inherits=Adwaita`. Sin `XCURSOR_THEME` en el entorno, libXcursor y wlroots buscan el tema llamado literalmente `default`; sin él no hay puntero AUNQUE Adwaita esté instalado. Es el eslabón que hace que ande sin configuración. ⚠ no declarar esta receta junto a `adwaita-icon-theme`: chocan en `Adwaita/cursors/*`. Y el vigía estaba midiendo el invariante de al lado: exigía `index.theme` en el directorio para contar un tema, que es correcto para ICONOS —la búsqueda XDG recorre `Directories=`— y falso para CURSORES, porque libXcursor abre `<tema>/cursors/<nombre>` directo y el índice sólo hace falta para seguir un `Inherits=`. Con la receta instalada seguía diciendo «NINGÚN tema de cursor». De paso queda anotado en `targets.toml` que el comentario de cosmic decía «sin ellos arranca sin puntero» sobre `cosmic-icons`, que no trae cursores: describía una protección que no existía. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CGyBj4QyeCZiwLMkP9GJp6 |
||
|
SergioandClaude Opus 5
|
fdce080d96 |
qorpa D8: sniper sellado al store, con la marca que evita que la cifra mienta
D8 decía que sniper «entra al store por `file_drop`». Dos correcciones, y la primera es de vocabulario: **`file_drop` en hammer es otra cosa** — una operación de `hammer apply` que coloca un fichero en el sistema instalado verificando su hash. No tenía nada que ver con sellar. Lo que sella es lo de siempre, una receta. Queda escrito en el ADR: un término inventado que suena a mecanismo existente manda a buscar el código donde no está. `recipes/steam-runtime-sniper.toml` sella el árbol del runtime (11196 ficheros) pineado por el sha256 que ya estaba verificado. Entra donde Arch y Ubuntu no pueden por una propiedad, no por simpatía: **no muta** —nadie le instala nada adentro— así que el mismo tarball da siempre el mismo árbol y sellarlo es una afirmación verdadera. **La marca: `foreign = true`.** No cambia el build en un byte y **no entra en `hash_inputs`** (describe procedencia, no identidad — hay test). Lo que cambia es contable: `build-state.py` la clasifica `ajeno`, la resta del denominador de las imágenes y la deja fuera del recuento de recetas. Sin eso, sellar un prebuilt habría subido la cifra que todo el mundo lee como «cuánto construimos» — el riesgo que el ADR escribió antes de que existiera la primera instancia. Verificado: sigue diciendo 821 recetas, y aparte `de las ajenas, 1 selladas al store (prebuilt pineado, sin procedencia de fuente)`. Y la diferencia con el otro ajeno: `xwayland` no se hashea (no hay receta, y un hash afirmaría que lo reproducimos); el sellado **sí conserva su hash**, porque está en el store y que un artefacto exista mientras el grafo lo niega sería otra forma de mentir. Comparten el estado, que es lo que protege la cifra. **`hammer qorpa import --from-store <hash>`** lo consume, y ahí está el detalle que hace que valga: la imagen se registra bajo el **sha256 del archivo de upstream**, no bajo el ArtifactHash. Al revés, la imagen del store y la traída con `pull` serían dos imágenes distintas con los mismos bytes y las instancias de dos máquinas dejarían de coincidir — justo lo que el pin existe para evitar. El árbol se **enlaza**: una imagen nunca se escribe (lo que escribe la instancia va a su `upper`), así que compartir inodos con un artefacto sellado y de sólo lectura es correcto por construcción y la imagen cuesta ~0 bytes. La contracara conocida de `.dmerge`: mientras el artefacto siga en el store, borrar la imagen no libera disco; `--copy` lo evita. Licencia `LicenseRef-qorpa-ajena-no-enumerable` a propósito: adentro hay cientos de paquetes Debian y no podemos enumerarlos; vacío se leería como «todavía no la poblamos». SDD 20 lo recoge y afila la distinción: replicarla a nuestras máquinas es lo que ya hace ADR 0013 con las fuentes; publicarla a terceros sigue pidiendo licencia y marca. 29 tests verdes. El sellado en sí corre aparte, esperando el lock de la granja. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QZjGRqvjWij9dew7NVFu4Q |
||
|
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
|
d69c437051 |
escritorios: KDE y GNOME corrían SIN tema de iconos — el panel vacío no era el panel
Medido sobre los artefactos del cierre de cada imagen, contando qué `usr/share/icons/*/`
trae un `index.theme` (que es lo que convierte un directorio en un tema):
escritorio-kde sólo Breeze_Light y breeze_cursors — que son CURSORES
escritorio-gnome CERO, ni siquiera hicolor
escritorio-cosmic Cosmic + hicolor <- el único que estaba bien
escritorio-sway CERO
Las dos capturas de QEMU de hoy ya lo mostraban y se leyeron como «arranca»:
- `plasma6-qemu-2026-09-03-kactivitymanagerd.png`: panel con el reloj y nada más. Los `.so`
de los applets estaban TODOS instalados; lo que faltaba era qué pintar. `kickoff`,
`systemtray`, `showdesktop` y `trash` SON un icono, así que sin tema quedan de ancho cero
— el reloj se ve porque dibuja TEXTO. El log lo decía en una línea:
`kf.iconthemes: Icon theme "breeze" not found.`
- `gnome-shell-qemu-2026-09-03-libs-compartidas.png`: barra superior con la fecha y el pill
de espacios, y la DERECHA vacía — red, volumen y batería son iconos.
`breeze` (ya declarado) es el tema de WIDGETS y CURSORES; los ~14.000 iconos viven en
`breeze-icons`, receta aparte, sellada desde siempre y declarada por NADIE. Igual
`adwaita-icon-theme` en GNOME, que además trae los XCursor (su cabecera dice por qué:
sin tema de cursor no hay puntero visible con el cursor por software de virtio-gpu).
Es la figura de las fuentes y de `foot` otra vez: data de RUNTIME, ninguna arista de BUILD
la alcanza, y la métrica de clausura no la echa de menos porque mide lo declarado.
`hicolor-icon-theme` —el fallback obligatorio de freedesktop— se promueve al corpus para que
lo alcancen las cuatro imágenes: hash IDÉNTICO desde la cola y desde el corpus
(b3:98ad44a5), y sus 4 consumidores (adwaita-icon-theme, cosmic-icons, cosmic-app-library,
cosmic-launcher) miden el mismo hash antes y después ⇒ un solo artefacto, CERO rebuilds.
Cierre tras declararlos, todo sellado y sin deuda:
kde 263/263 (+2) · gnome 158/158 (+2) · sway 173/173 (+1) · cosmic 133/133 (igual)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YGXe6mShYYw6V8ea1dQ13u
|
||
|
SergioandClaude Opus 5
|
6c37df6fa4 |
ncurses-shared: cierra la fuga de pw-top al lab, que llevaba desde agosto
recipes/pipewire.toml:85-88 afirma que quitando la dep de ncurses «meson saltea pw-top
y el resto construye». ES FALSO, y llevaba así desde al menos el 2026-08-29. Quitar la
dep no desactivó nada: el guardián de upstream es `if ncurses_dep.found()` y meson lo
encontró igual, en el sysroot Alpine DEL LAB. pw-top se construye, se sella y sale con
NEEDED libncursesw.so.6, que ningún artefacto del cierre publica porque el ncurses del
catálogo es --without-shared. Una herramienta rota dentro de las CUATRO imágenes,
invisible para el store porque el lab no entra en hash_inputs.
LA LECCIÓN, que es más grande que pw-top: QUITAR UNA DEP DE [deps] NO APAGA LA FUNCIÓN.
Cambia de dónde sale. Para apagarla de verdad hay que decírselo a la perilla del
proyecto; si no la hay, la dep tiene que estar declarada y satisfecha desde el store.
POR QUÉ UNA RECETA NUEVA Y NO RE-SELLAR PIPEWIRE. El arreglo limpio es declarar la dep y
reconstruir; cuesta 10 dependientes directos y 7 sellados que caen a deuda, entre ellos
xdg-desktop-portal-cosmic y cosmic-settings-daemon, que son Rust —el portal murió por
OOM tres veces y el que selló tardó 48 min con pico de 5,4 GiB de swap—. No se paga eso
hoy por una herramienta de diagnóstico, y menos con otro agente compilando en la misma
máquina. Lo que cruza acá es un SONAME, y para eso el repo ya tiene regla escrita:
enlazar contra una variante y CORRER contra otra es legítimo cuando lo que cruza es un
SONAME. Cero rebuilds.
⚠ QUEDA DEUDA ANOTADA: pipewire sigue enlazando contra el lab en BUILD. El día que se
re-selle por cualquier otro motivo hay que declarar ncurses-shared en sus [deps] y
corregir el comentario mentiroso. Esto tapa el síntoma en runtime, no la causa.
DOS COSAS QUE COSTARON, y están escritas en la receta:
- `-stats` es un flag de GNU ld que lld rechaza, y viene DENTRO del token
`-Wl,-soname,...,-stats,-lc` que arma el configure de ncurses. No se puede pasar por
LDFLAGS ni hay perilla MK_SHARED_LIB, y el patrón .zwrap de poppler tampoco sirve tal
cual porque filtra argumentos completos y acá hay que reescribir uno.
- Quitando `-stats`, el siguiente en caer es el `-lc` del mismo token. El driver de zig
valida lo que va dentro de `-Wl,` y no deja pasar ninguno de los dos; libc la liga él
solo, así que la cola `,-stats,-lc` se va entera. Se quita del Makefile GENERADO, con
un grep previo que FALLA si el configure deja de emitirlo (para no seguir en silencio).
EVIDENCIA, con control discriminante:
sin ncurses-shared -> Error relocating /lib/libncursesw.so.6: __vfprintf_chk: symbol
not found (símbolo de _FORTIFY_SOURCE de glibc que musl no
tiene: la fuga al lab, reproducida)
con ncurses-shared -> carga y corre; sólo falla en el runtime de PipeWire por no haber
demonio ni plugins SPA en la raíz de prueba
vigia-sonames en los cuatro perfiles: libncursesw.so.6 Y libpanelw.so.6 desaparecen.
Lo que queda son herramientas de build (go, python3, perl) más tres de RUNTIME que NO
son de este cambio y quedan anotadas: spidermonkey pide libgcc_s/libstdc++ en gnome,
libadwaita pide liblzma, y sqlite-shared pide libreadline.
Grafos: 820/820, 999/999, 883/883, 856/856, 833/833.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
|
||
|
SergioandClaude Opus 5
|
cab9439644 |
fuentes: dejavu al corpus (arregla un wanted que dejé), KDE con fuente, y la nerd de monospace
TRES COSAS, y la primera es un bug mío de hace un rato.
1. dejavu-fonts PROMOVIDA AL CORPUS — arregla un nodo `wanted` que introduje.
Al añadirla de raíz a escritorio-gnome quedó como `wanted`: la receta existía en
incoming-{kde,wlr,cosmic} y NO en incoming-gnome ni en el corpus, y una receta no
alcanza una cola hermana. O sea que la raíz no resolvía a nada y GNOME seguía sin
fuentes. `wanted` NO es `debt`, así que drenaje.json seguía diciendo deuda=0 y el
hueco no salía por ninguna métrica — se vio mirando el nodo en build-state-gnome.json.
Promoción gratis: las tres copias sellaban el mismo hash (b3:5b3a5df3) y sus deps
están vacías. Las tres se jubilan. Ahora los cuatro perfiles resuelven a corpus y los
cinco grafos quedan con CERO nodos `wanted`.
2. dejavu-fonts en escritorio-kde, como se pidió. Tenía UNA fuente y de rebote, dentro
de qtbase — apoyarse en un detalle de empaquetado de Qt deja sin nada a todo lo que
no es Qt.
3. dejavu-fonts-nerd 3.5.1 en los CUATRO perfiles: DejaVu Sans Mono parcheada con Nerd
Fonts. Lo que se midió antes de escribirla, porque cambia la forma de hacerla:
- SE AÑADE, NO REEMPLAZA, y no es prudencia: la licencia de Bitstream Vera exige que
una fuente modificada se RENOMBRE. Por eso upstream la llama «DejaVuSansM Nerd Font
Mono» — leído del name de la TTF, no supuesto. Una fuente nerdeada NO puede
responder al nombre de la original; sustituirla rompería a todo lo que pide «DejaVu
Sans Mono», empezando por foot, que ya murió una vez así.
- SÓLO LA MONOESPACIADA: upstream no publica DejaVu Sans ni Serif parcheadas, y en una
fuente de interfaz proporcional esos glifos no los pide nadie. «Todas nerdeadas» no
se puede cumplir al pie de la letra.
- SÓLO UNA DE LAS TRES VARIANTES: NerdFont / NerdFontMono / NerdFontPropo son los
mismos glifos con distinto avance. Las doce pesan 32 MB; las cuatro de Mono, 11 MB.
Se quedan las Mono, que son las correctas para una rejilla de terminal. Referencia:
la familia DejaVu ENTERA son 9,8 MB.
⚠ EL NÚMERO DEL .conf ESTÁ MEDIDO, NO ELEGIDO. fontconfig carga conf.d en orden
alfabético y el <prefer> que llega antes gana. Con 60-nerd-monospace.conf —que ordena
después de 60-latin.conf, que ya prefiere Noto/DejaVu/Inconsolata— `fc-match
monospace` seguía dando DejaVu Sans Mono: la conf estaba INSTALADA Y ERA INERTE, el
mismo modo de fallar que el plugin ALSA de PipeWire. A 59- gana. 45-latin.conf también
menciona monospace pero usa <default>, no <prefer>, así que no compite.
⚠ Y strip_components = 0, que tampoco es cosmético: el tarball de nerd-fonts es PLANO
y con el default de 1 el árbol de fuentes queda VACÍO — el build no se detiene ahí,
sigue y falla más tarde en el cp, con un mensaje que no menciona la extracción.
⚠ LA LICENCIA NECESITA UNA PASADA HUMANA antes de `hammer pack`: el LICENSE.txt del
tarball cubre sólo DejaVu/Bitstream Vera y no menciona los ~10 conjuntos de iconos
importados, que tienen licencias propias (Font Awesome CC-BY-4.0, Octicons MIT,
Material OFL, Powerline MIT…). El campo dice lo DOCUMENTADO, no el conjunto real; no
se inventa una cadena SPDX. Anotado en la receta.
EVIDENCIA, contra el conf.d REAL del artefacto de fontconfig:
monospace -> DejaVuSansM Nerd Font Mono (los iconos llegan)
"DejaVu Sans Mono" -> DejaVu Sans Mono (intacta)
sans-serif -> DejaVu Sans (sin tocar)
serif -> DejaVu Serif (sin tocar)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
|
||
|
SergioandClaude Opus 5
|
da0186d250 |
apps: zathura + backend de PDF, en gnome/cosmic/sway — y tres defectos de imagen que salieron
La cadena: 5 recetas nuevas (girara, xxhash, poppler-glib, zathura,
zathura-pdf-poppler) y 5 promociones GRATIS al corpus (json-glib, lcms2, glib-shared,
pcre2-shared, bzip2-shared — todas con hash idéntico desde la cola y desde el corpus,
medido con hammer hash antes de mover nada).
NO va en escritorio-kde, y está escrito en tres sitios para que no se liste por
descuido: su backend necesita una poppler con ENABLE_GLIB=ON, y esa imagen ya trae la
de Qt6 vía okular. Las dos instalan /usr/lib/libpoppler.so.146 y son artefactos
DISTINTOS ⇒ hidratar las dos pone dos ficheros en la misma ruta. La salida no sería
listarla igual, sería jubilar una de las dos popplers.
LAS TRES COSAS QUE SE ROMPIERON, que valen más que las recetas:
1. -DENABLE_GLIB=ON SE APAGA SOLO Y EL BUILD SALE OK. CMakeLists:260 hace
`if(NOT CAIRO_FOUND) set(ENABLE_GLIB OFF)`: no falla, obedece distinto. El primer
artefacto selló sin nada de glib, exit 0, sin aviso. La causa era una línea que este
repo ya tiene como patrón: `.pc Requires` → `[deps].build`. cairo.pc pide pixman-1 y
pixman no estaba declarado ⇒ `pkg-config --exists cairo` falso ⇒ CAIRO_FOUND falso.
Un .pc que falta a tres saltos apaga una FUNCIÓN, no una librería. La receta ahora
comprueba en install que poppler-glib.pc y libpoppler-glib.so existan.
2. DOS COPIAS ESTÁTICAS DE GObject EN UN PROCESO. Con la glib estática del corpus todo
sella y zathura arranca — y al dlopen del plugin escupe «cannot register existing
type 'gchar'» y no abre nada. No son dos ficheros en una ruta: son dos copias del
sistema de tipos dentro del mismo proceso, una en el ejecutable y otra dentro de
libpoppler-glib.so. Un .a NO duplica (sólo tiene símbolos sin definir, se resuelven
al ligar); el problema aparece sólo cuando dos objetos enlazados por separado meten
cada uno la suya. Arreglo: las TRES recetas de la cadena declaran glib-shared.
3. FUGA AL LAB, cazada por scripts/vigia-sonames.py: zathura selló con
NEEDED libsqlite3.so.0, un SONAME que ningún artefacto del cierre publica — meson
había resuelto dependency('sqlite3') contra el sysroot Alpine DEL LAB. Y declarar la
dep NO alcanzó: el .pc da un -lsqlite3 pelado y el linker prefiere la .so del lab
sobre la .a del store. Lo arregla -Dprefer_static=true. Medido: los NEEDED bajaron de
DIEZ a CUATRO y los cuatro los publica el cierre.
DOS DEFECTOS DE IMAGEN PREEXISTENTES que salieron de paso:
- libbz2.so.1 no lo publicaba nadie y freetype-shared lo pide, en los TRES perfiles.
Se vio de verdad al probar el visor (el plugin no hacía dlopen). bzip2-shared existía
sólo en incoming-kde; promovida y puesta de raíz junto a expat-shared/libffi-shared.
- escritorio-gnome NO TRAÍA NI UN FICHERO DE FUENTE. Contado sobre los artefactos del
cierre: gnome=0, sway=22, kde=1 (una de rebote dentro de qtbase). Tenía fontconfig,
que es el MOTOR que busca fuentes, no una fuente. Un PDF con base-14 se ve VACÍO y sin
error. Añadida dejavu-fonts, la única receta de fuentes del catálogo entero.
⚠ KDE queda igual y NO se toca acá: no lleva zathura y su árbol lo trabaja otro frente.
EVIDENCIA DE QUE ANDA, no de que sella:
- `zathura --version` con el plugin lista «(plugin) pdf-poppler (2026.07.18)» sin un
solo GObject-CRITICAL.
- poppler-render-check, receta-TESTIGO en el espíritu de gtk4-hello: arma un PDF a mano,
lo abre con poppler-glib, lo rasteriza sobre cairo y CUENTA PÍXELES — 9600 negros,
exactamente el rectángulo de 160x60. Un lienzo blanco no pasa. Su primera versión
medía el TEXTO y falló: el sandbox no tiene fuentes, que es cómo se descubrió el
hueco de arriba. El assert quedó sobre el rectángulo, que no depende de tipografía, y
el texto se informa aparte.
Los cinco grafos quedan en N/N con cero deuda.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
|
||
|
SergioandClaude Opus 5
|
058e3e9206 |
recetas: girara, xxhash y json-glib al corpus — la cadena de zathura, medida
⚠ CORRIGE UNA CREENCIA DEL REPO: zathura NO está bloqueada por GTK3. Upstream VACIÓ girara — en 2026.07.18 su árbol son siete .c (datastructures, input-history, log, template, utils) y su meson.build no menciona GTK ni una vez. Toda la UI se mudó adentro de zathura, que hoy pide GTK4 >= 4.12, y gtk4 4.18.6 está en el corpus. El plan de apps daba a zathura por «verificar si su cadena es GTK4 y no GTK3»: lo es. Las tres piezas que faltaban, medidas con scripts/provee.py --desde corpus: - girara: sella al primer intento; sus tres deps (glib/gobject/gio) salen del mismo artefacto glib. -Ddocs=disabled porque ese target es doxygen y produce HTML de API. - xxhash 0.8.3 (zathura lo usa para la caché de páginas). DISPATCH=0 no es preferencia, el build se cae sin eso: Makefile:58-62 hace `$(CC) -dumpmachine | grep x86_64` y enciende DISPATCH solo por detección de arquitectura — una perilla auto que hace depender el artefacto de dónde se construyó. Con ella, xxh_x86dispatch.c muere porque pide AVX-512 con -mavx512f a secas y el clang de zig ya exige además -mevex512 («AVX vector argument of type __m512i without evex512 enabled changes the ABI»). No se arregla subiendo flags: esa variante sólo la usa el despacho en runtime, que es justo lo que no queremos. Apaga las dos cosas de una. - json-glib PROMOVIDA al corpus, y salió GRATIS por la misma razón que pipewire: la variante de COSMIC resuelve sus deps enteras contra el catálogo padre ⇒ mismo ArtifactHash desde las dos partes (b3:62011e81, medido antes de mover nada). La de GNOME no podía: arrastra gobject-introspection, glib-introspected, gi-foreign-girs y py3-setuptools. La copia de incoming-cosmic se jubila, verificado como manda el repo: su único consumidor (xdg-desktop-portal) hashea b3:749fbffe ANTES y DESPUÉS ⇒ cero rebuilds. La de incoming-gnome SE QUEDA: variante deliberada, artefacto distinto. Falta todavía el backend de PDF, que es el hueco real: incoming-kde/poppler va con -DENABLE_GLIB=OFF ⇒ publica libpoppler.so pero NO poppler-glib, y encima sólo se alcanza desde su cola. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo |
||
|
SergioandClaude Opus 5
|
e2bcd96feb |
apps: swayimg sube a 5.5, que es lo que justificaba escribir luajit
Entró como 4.7 —la última sin Lua— sólo porque no había receta de luajit. Con luajit sellada, sube a la actual. Lo que se gana: el motor de configuración pasó a ser Lua (src/luaengine.cpp), y con él los perfiles de teclas y el .lua de ejemplo. Formatos: suma qoi, ttf y xbm a los de 4.7. Dos cambios de forma que sacan dos deps: `compositor` ya no pide json-c (la integración con sway se rehizo sin JSON) y la man page viene PRE-GENERADA en extra/swayimg.1 en vez de armarse con scdoc. -Ddoc=false porque ese target regenera markdown con dos scripts de Python y lo que instala son .md, no páginas de manual. Corregido de paso el comentario de las opciones apagadas: son DOS por cola, no una. `svg` pide librsvg-2.0 (sólo en incoming-gnome) y `exif` pide exiv2 (sólo en incoming-kde). Las dos existen en el disco y ninguna es alcanzable desde el corpus. Por eso este visor no muestra metadatos EXIF, y queda escrito dónde está el hueco. Evidencia de que la cadena cierra, no sólo de que sella: `swayimg -e` ejecuta Lua dentro del visor y reporta «Lua 5.1 · jit=true · LuaJIT 2.1.1787165859» — que es exactamente el relver de nuestra receta de luajit, o sea que el intérprete que corre es el que construimos. Un script con error de sintaxis se reporta como error de Lua. NEEDED sigue siendo sólo libc.so. Los cinco grafos quedan en N/N con cero deuda. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo |
||
|
SergioandClaude Opus 5
|
2d68e70a07 |
recetas: luajit 2.1 (rolling) — el intérprete que swayimg 5.x exige y mpv prefiere
Tercer Lua del catálogo y hay razón para cada uno: `lua` 5.4 para wireplumber,
`lua5.2` para el OSC de mpv, y ésta porque hay consumidores que piden LuaJIT POR
NOMBRE — swayimg >=5.0 hace dependency('luajit') sin alternativa. No es la misma ABI:
LuaJIT es Lua 5.1 + FFI + JIT. Convive sin pisar: todas sus rutas ya vienen
versionadas (include/luajit-2.1, libluajit-5.1.so.2, /usr/bin/luajit-2.1.<relver>).
⚠ EL PIN DE COMMIT NO ALCANZA. Desde que 2.1 es rolling no hay tags: la versión sale
de `git show -s --format=%ct` sobre el árbol, y NO es cosmética — entra en un SÍMBOLO
EXPORTADO (luaJIT_version_2_1_ROLLING). Dos builds del mismo commit con distinto
estado de .git publican símbolos distintos y el consumidor muere con símbolo
indefinido. Se escribe .relver a mano Y se borra .git, porque la rama que consulta git
gana si el directorio existe. Verificado: nm -D da luaJIT_version_2_1_1787165859.
LIBS=-lunwind: la misma deuda que ya paga librsvg. Sin esto, nueve _Unwind_*
indefinidos desde lj_err.o — LuaJIT usa unwinding DWARF de verdad y en glibc ese
runtime vive en libgcc_s, que musl no tiene. Va por LIBS= y no LDFLAGS= porque
TARGET_ALIBS se expande DESPUÉS de los objetos, que es donde el linker resuelve.
TARGET_STRIP=true: su Makefile strippea como parte de la compilación, lo que pediría
binutils y borraría el .debug_* antes de que hammer lo parta (SDD 23).
Evidencia de que anda: NEEDED = libc.so y nada más; jit.status() da true con todas las
optimizaciones; FFI llama a C; y los cuatro caminos de unwinding responden — pcall,
error DENTRO de un trace compilado (err_unwind_jit, el que pedía _Unwind_GetIP),
metamétodo y xpcall+traceback.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
|
||
|
SergioandClaude Opus 5
|
d8dd779812 |
apps: swayimg 4.7 sellada, visor de imágenes en las cuatro imágenes
El plan proponía `imv` como paso 4. Al medirla apareció un muro que el método de triaje no podía ver: imv dibuja con OpenGL de función fija (glBegin/glOrtho) y esta distro NO tiene proveedor de GL de escritorio — las tres variantes de mesa van -Dglx=disabled -Dglvnd=false y no publican libGL.so ni gl.pc ni opengl.pc, y no hay receta libglvnd. La trampa fina: mesa SÍ instala GL/gl.h, así que compila entero y muere al ligar. Darlo vuelta = autorar libglvnd + rehacer mesa (radio 139). swayimg cubre el mismo caso de uso sin tocar GL (rasteriza a wl_shm) y con CERO recetas nuevas: sus deps requeridas ya estaban en el corpus. De yapa trae backend DRM (imágenes en TTY pelada, sin compositor). Pineada 4.7 y no 5.5 a propósito: desde la 5.0 luajit es obligatoria y no hay receta (la lua5.2 del OSC de mpv es otra ABI). Escribir luajit es el próximo paso barato. -Dversion=4.7 no es cosmético: su default 0.0.0 dispara un `git describe` sobre el árbol ⇒ la versión estampada en el binario dependería del checkout. Misma familia que el -Dbuild-date de mpv. Evidencia de que anda, no sólo de que sella: NEEDED = libc.so y nada más (cero glibc, cero X11, cero GL), `--version` dice 4.7 con jpeg/png/gif/webp/tiff, prueba las dos UIs (Wayland → DRM) y el bucle de decodificación rechaza lo que no es imagen. Añadida a las raíces de los cuatro perfiles (sellado ≠ instalado). Los cinco grafos quedan en N/N con cero deuda. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo |
||
|
Sergio
|
39f5007cff |
wf-recorder 0.6.0: la primera app que cobra la promoción de pipewire
Sellada b3:25caa359 al primer intento. `--help` corre y los NEEDED traen `libpipewire-0.3.so.0`: graba CON audio, que era exactamente lo que anoche no se podía. Es la app que estaba bloqueada por el defecto del triaje —preguntaba «¿existe la receta?» en vez de «¿la alcanza quien la usa?»—: sus dos backends de captura de sonido vivían sólo en colas y una receta del corpus no alcanza una cola hermana. Con pipewire en el corpus, cae sola. `-Ddefault_audio_backend=pipewire` explícito y no `auto`: su meson resuelve `auto` mirando qué encontró en el sandbox (meson.build:95-101), o sea que el artefacto dependería de lo que quedó montado en el lab. Misma disciplina que en mpv y ffmpeg. ⚠ SE LISTA SÓLO EN `escritorio-sway`, y la razón es de PROTOCOLO: captura por `wlr-screencopy`, que implementan los compositores wlroots. KWin y mutter NO lo implementan —usan el portal/ScreenCast—, así que meterlo en esas dos imágenes sería enviar una herramienta que no puede funcionar ahí: deuda fantasma con forma de app. En COSMIC hay que verificar si cosmic-comp expone el protocolo antes de listarlo; no se listó a ciegas. Cubre el caso de uso principal por el que uno instala OBS, con UNA receta en vez de las 20 + Qt6 + X11 que OBS pedía. escritorio-sway 146/146. |
||
|
Sergio
|
e08add24be |
pipewire al corpus: mpv habla PipeWire nativo, y pulseaudio NO se promueve (medido)
Cierra la decisión que quedó abierta anoche en `docs/plan-apps-usuario-final.md`: el corpus no tenía ningún cliente de audio salvo ALSA, y eso bloqueaba a toda app multimedia. GANA LA VARIANTE DE COSMIC y la promoción es GRATIS: era la única cuyo cierre ya resolvía entero contra el catálogo padre, así que `recipes/pipewire.toml` sella b3:e240653a — el mismo hash que tenía en la cola. Con ella suben `libsndfile` (las tres copias sellaban idéntico) y `dbus-shared` (gnome y cosmic, idénticas). Se jubilan 9 copias de cola. POR QUÉ ESTO NO REPITE EL EPISODIO DE LAS DOS GLIB — leído de los artefactos sellados, no razonado: **ningún pipewire de los tres enlaza glib.** Los NEEDED de las tres variantes son exactamente `libdbus-1.so.3`, `libpulse.so.0` y `libsndfile.so.1`; glib entraba sólo como Requires transitivo de pkg-config, en tiempo de build. ⇒ `libpipewire-0.3.so` es glib-free y se comparte entre las cuatro imágenes sin riesgo. ⚠ Y POR ESO `pulseaudio` NO SE PROMUEVE, aunque sea la dep de al lado. Ahí la objeción SÍ aplica y el número lo dice solo: `libpulse-mainloop-glib.so.0.0.6` mide **45.712 bytes** en la variante de GNOME (NEEDED `libglib-2.0.so.0`) y **2.455.600** en la del corpus, que se traga la glib ESTÁTICA del catálogo. Meter ésa en el proceso de gnome-shell —que ya carga la glib sombra dinámica— es literalmente el cuadro de colord. `incoming-kde/pulseaudio` e `incoming-gnome/pulseaudio` se quedan donde están: son variantes deliberadas, no duplicados. La copia del corpus existe sólo para que pipewire tenga contra qué enlazar `libpulse.so.0`, y ese enlace es por SONAME — en runtime lo sirve la libpulse de cada imagen, ABI-compatible (misma 0.24.3). Enlazar contra una variante y correr contra otra es legítimo cuando lo que cruza es un SONAME; lo que NO se puede es hidratar dos artefactos distintos en la misma ruta. Esa distinción es la que decide qué se promueve y qué no. mpv (b3:392e9690) pasa a `-Dpipewire=enabled`, con ALSA encendida detrás: prueba pipewire primero y cae a alsa si no hay demonio —KDE todavía no lista PipeWire entre sus raíces—. Evidencia: NEEDED … libasound.so.2 **libpipewire-0.3.so.0** libEGL.so.1 libc.so --ao=help → pipewire (PipeWire audio output), alsa, null Impacto medido antes de tocar, hasheando las 336 recetas de cola y comparando: 9 retiradas, **5 rebuilds** (wireplumber, xdg-desktop-portal ×2, kpipewire, spectacle) — los 5 sellados. Sin la salvedad de pulseaudio habrían sido 8, incluido gnome-shell. Perfiles: KDE 188/188, GNOME 132/132, sway 145/145. ⚠ COSMIC 105/106: `xdg-desktop-portal-cosmic` murió por OOM por TERCERA vez (7 G de RAM sin cgroups, con otro agente compilando Rust). Sigue siendo la máquina, no la receta. |