Files

T

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

2026-09-03 12:14:07 +00:00

16 KiB

Raw Blame History

Plan — apps de usuario final (montón A del ADR 0015), MEDIDO

Fecha de la medición: 2026-09-03 · Catálogo contra el que se midió: 1079 recetas (corpus + las cuatro colas) · Instrumento: makedepends+depends del APKBUILD de Alpine de cada candidata, cruzados contra los nombres de receta que existen en el disco.

Por qué existe este documento

El ADR 0015 parte las apps que faltan en tres montones y dice del A —Firefox, Chromium, LibreOffice, mpv, GIMP, Inkscape, Blender, OBS— que no lo bloquea «nada estructural: son Wayland-nativos y compilables. Falta escribirlas», y propone el orden mpv → OBS → Firefox.

mpv se escribió el 2026-09-03 y esa parte se confirmó. Al ir por el segundo, la medición desmiente la premisa para el resto del montón: OBS y Firefox no están a una receta de distancia, están detrás de muros que esta distro levantó a propósito. Este documento deja el dato escrito para que la decisión se tome mirándolo y no de memoria.

Cómo leer la tabla

Dos columnas, y la que importa es la segunda:

recetas que faltan — cuántos makedepends de Alpine no tienen receta acá. Es una cota superior floja: Alpine construye con todo activado y nosotros no. El control lo da mpv, que YA ESTÁ SELLADA y aun así aparece con 16 faltantes — son exactamente las perillas que su receta apaga a propósito (jack, sndio, libbluray, zimg, rubberband…). O sea: un número alto no prueba que sea caro.
muros de diseño — dependencias que NO son «una receta más», sino decisiones ya tomadas de esta distro: GTK3 aparcado, X11 al tacho, Qt6 que vive sólo en incoming-kde, toolchain wasi inexistente. Un muro no se paga escribiendo una receta: se paga cambiando una decisión.

La tabla

app	faltan	muros	veredicto
~~wf-recorder~~	—	—	✅ SELLADA 2026-09-03 (b3:25caa359), con audio. Se destrabó al promover pipewire al corpus. Sólo en `escritorio-sway`: captura por `wlr-screencopy` y KWin/mutter no lo implementan.
~~imv~~	7	GL de escritorio	❌ BLOQUEADA 2026-09-03 — el muro no lo veía este método; ver abajo. Reemplazada por `swayimg`, sellada el mismo día.
~~swayimg~~	—	—	✅ SELLADA 2026-09-03 (b3:9bcd39c1, 5.5), en las CUATRO imágenes. Visor sin GL: rasteriza a `wl_shm`. Trae backend DRM de yapa.
~~luajit~~	—	—	✅ SELLADA 2026-09-03 (b3:115d4c1c). Escrita para destrabar swayimg 5.x; mpv también la prefiere.
~~zathura~~	—	—	✅ SELLADA 2026-09-03 (b3:9c5eac92) + `zathura-pdf-poppler`. Es GTK4, no GTK3: upstream vació girara. En gnome/cosmic/sway; NO en KDE, por colisión de poppler.
mupdf	9	X11	el X11 es del visor `mupdf-x11`; el motor y `mupdf-gl` no. Requiere mirar.
inkscape	14	—	sin muros, pero `gtkmm3` en la lista hay que verificarlo (¿GTK3 encubierto?).
mpv	16	X11	YA SELLADA — es el control del método, no una candidata.
gimp	18	GTK3, X11	GIMP 2.10 es GTK2/3. Fuera de alcance mientras GTK3 esté aparcado.
obs-studio	20	Qt6, X11	ver abajo.
firefox	26	GTK3, X11, wasi	ver abajo.
chromium	38	GTK3, Qt6, X11	peor que Firefox por todos lados.
libreoffice	59	GTK3, Qt6, X11	59 recetas y tres muros. No es un ticket, es un año.

⚠ El defecto del método, encontrado al usarlo (y lo que destapó)

La columna «recetas que faltan» pregunta ¿existe esta receta en el disco? y esa es la pregunta equivocada. La correcta es ¿la alcanza el consumidor? — porque una receta resuelve sus deps sibling-first (su propia cola) y después el catálogo PADRE, nunca una cola hermana.

Se descubrió al ir a escribir wf-recorder, que la tabla daba en 0/0: su makedepends pide pipewire-dev y pulseaudio-dev, los dos existen… en las tres colas de escritorio y en ninguna en el corpus. Una app del corpus no los ve. wf-recorder construye igual (-Dpulse=disabled -Dpipewire=disabled, have_audio=false) pero graba sin sonido, y no tiene backend ALSA con el que caerse.

Lo que eso destapa, que es más grande que wf-recorder

El corpus no tiene ningún cliente de audio salvo ALSA. libpipewire-0.3 y libpulse viven sólo en incoming-{kde,gnome,cosmic}. Toda app multimedia que llegue al corpus va a chocar acá.

Ya chocó dos veces en un día: mpv terminó con --ao=alsa en vez de su salida nativa de PipeWire (y por eso hubo que dar vuelta -Dpipewire-alsa en las tres pipewire, que fue el arreglo correcto pero fue un rodeo), y ahora wf-recorder se queda mudo.

DECIDIDA Y HECHA el 2026-09-03 — opción 1, con una salvedad medida. Lo que sigue queda como registro de por qué. La decisión era: promover UNA pipewire al corpus. Construye —el corpus tiene su propia glib, dbus y pcre2— pero el problema no es construirla: es que una imagen que hidrate corpus/pipewire y la de su cola pondría dos libpipewire-0.3.so distintas en la misma ruta, que es la enfermedad de las dos glib. Las salidas posibles, para pensarlas despierto:

Una sola pipewire, en el corpus, y las tres colas jubilan la suya. Es lo más limpio y es lo que ya se hizo con otras 13 copias que sellaban igual — pero éstas NO sellan igual (difieren en glib/dbus/pcre2), así que hay que decidir cuál gana y volver a sellar wireplumber y los portales de las tres colas.
Aceptar ALSA como la única ABI de audio del corpus, que es lo que hoy quedó funcionando de hecho: -Dpipewire-alsa=enabled hace que un cliente ALSA desemboque en PipeWire. Barato y ya está hecho; el precio es que las apps del corpus nunca usan la API nativa (sin control por-stream, sin metadata de sesión) y que las que sólo hablan pulse/pipewire —wf-recorder— quedan afuera.
Que las apps multimedia vivan en las colas, una copia por escritorio. Es lo que la estructura empuja hoy y es exactamente lo que no queremos para una app que sirve a las cuatro imágenes.

Cómo se resolvió

Ganó la opción 1, y salió barata porque la variante de COSMIC ya resolvía su cierre entero contra el catálogo padre: recipes/pipewire.toml sella el MISMO hash que tenía en la cola. Con ella subieron libsndfile y dbus-shared (duplicados exactos). 9 copias de cola jubiladas, 5 rebuilds.

Lo que hizo segura la promoción fue una medición, no un argumento: ningún pipewire enlaza glib —sus NEEDED son libdbus-1.so.3, libpulse.so.0, libsndfile.so.1— así que libpipewire-0.3.so se comparte entre las cuatro imágenes sin repetir el episodio de las dos glib.

Y la salvedad, que es la parte que valía la pena medir: pulseaudio NO se promovió. 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. Esa dentro del proceso de gnome-shell —que ya carga la glib sombra dinámica— es el cuadro de colord. Las tres pulseaudio se quedan: son variantes deliberadas. Sin esa salvedad los rebuilds habrían sido 8, incluido gnome-shell.

La regla general que sale de acá, y sirve para la próxima promoción:

Enlazar contra una variante y correr contra otra es legítimo cuando lo que cruza es un SONAME (misma ABI). Lo que no se puede es hidratar dos artefactos distintos en la misma ruta. Por eso pipewire se puede compartir y pulseaudio no.

Consecuencias inmediatas: mpv pasó a -Dpipewire=enabled (con ALSA detrás, para imágenes sin demonio) y wf-recorder se escribió y selló el mismo día.

⚠ EL TERCER DEFECTO DEL MÉTODO: la receta existe, es alcanzable, y aun así no sirve

El defecto anterior era «¿existe la receta?» ≠ «¿la alcanza el consumidor?». Al ir a escribir imv apareció un tercer eje, y es el peor de los tres porque las dos preguntas anteriores dan que sí:

La receta existe, el consumidor la alcanza, y la VARIANTE que se construyó no publica la ABI que hace falta.

imv pide OpenGL. mesa existe, está en el corpus, y cualquier receta lo alcanza. Pero:

imv/src/canvas.c hace #include <GL/gl.h> y dibuja con glBegin / glOrtho / GL_TRIANGLE_FAN / GL_TEXTURE_RECTANGLE, o sea OpenGL de función fija, perfil de compatibilidad. No existe equivalente en GLES: no es una perilla, es otra API.
Su meson.build hace gl_dep = dependency('gl', required: false) y, si no la encuentra, dependency('opengl') sin required: false ⇒ el configure muere.
Y esta distro no tiene ningún proveedor de OpenGL de escritorio. Medido en los artefactos sellados, no supuesto: las tres variantes de mesa (mesa, mesa-swrast, mesa-llvmpipe) llevan -Dglx=disabled -Dglvnd=false, y sus artefactos publican libEGL.so.1, libGLESv2.so.2, libgbm y egl.pc/glesv2.pc/gbm.pc — ni un libGL.so*, ni gl.pc, ni opengl.pc. No hay receta libglvnd en ninguna cola.

La trampa fina, y es la parte que hay que recordar: mesa SÍ instala /usr/include/GL/gl.h (el header viene con -Dopengl=true). O sea que una app así compila entera y muere recién al LIGAR. Un triaje que mire headers da verde.

Qué costaría darlo vuelta (para que la decisión se tome con el número)

El camino que el propio meson.build de imv nombra —«libglvnd fallback for pure-wayland systems»— es autorar libglvnd (que provee libOpenGL.so/opengl.pc) y reconstruir mesa con -Dglvnd=true. Eso es radio 139 dependientes directos sobre mesa, y además convierte a libglvnd en pieza obligatoria de las cuatro imágenes: sin ella no hay EGL. Es una decisión de distro, no un ticket de visor de imágenes.

La salida, que resultó mejor que el original

swayimg cubre el mismo caso de uso sin tocar GL: rasteriza a un buffer y lo entrega por wl_shm. Sus deps requeridas (xkbcommon, fontconfig, freetype2, wayland, wayland-protocols) ya estaban todas en el corpus ⇒ cero recetas nuevas. Y trae un backend DRM que muestra imágenes en una TTY pelada, sin compositor, que es exactamente lo que le falta al instalador.

Entró primero como 4.7 —la última sin Lua— porque desde la 5.0 dependency('luajit') es obligatoria y no había receta (la lua5.2 del OSC de mpv es otra ABI). Se escribió luajit el mismo día y subió a 5.5. La cadena quedó verificada de punta a punta: swayimg -e reporta Lua 5.1 · jit=true · LuaJIT 2.1.1787165859, que es exactamente el relver de nuestra receta. luajit queda además disponible para mpv, que la prefiere sobre 5.2.

Regla que sale de acá, para el próximo triaje de apps: la pregunta no es «¿existe la receta?» ni sólo «¿la alcanza?», sino «¿la variante sellada publica el .pc y el .so que el consumidor pide?». Se contesta mirando el artefacto, no el catálogo.

Y como acá cada punto ciego se convierte en un guardián, esa pregunta ya tiene instrumento: scripts/provee.py, que indexa los .pc y las librerías de TODOS los artefactos sellados y contesta quién publica cada nombre y desde qué colas se alcanza. Los tres defectos del método caen con un solo comando:

scripts/provee.py --desde corpus gl opengl     # ✗ nadie lo publica  → exit 1  (el caso imv)
scripts/provee.py exiv2 librsvg                # ✓ existen, alcanzables SÓLO desde su cola

Es el hermano de build de vigia-sonames.py, que cubre la mitad de runtime. El triaje de la próxima app empieza por acá, no por contar makedepends contra recipes/*.toml.

Los dos veredictos que corrigen al ADR

Firefox NO es montón A

Su APKBUILD pide gtk+3.0-dev — Firefox no tiene backend GTK4 ni lo va a tener a corto plazo, y GTK3 es una de las tres deudas que el frente GNOME aparcó por diseño. Además pide libxt, libxcomposite (X11) y un toolchain wasi (wasi-sdk, wasi-compiler-rt) que no existe en el corpus, más nodejs, icu, nss/nspr, clang/llvm/lld versionados y cbindgen.

La memoria del repo decía que a Firefox «le falta subir el techo MSRV». Eso es cierto y es lo menor: el bloqueo real es GTK3.

Consecuencia estratégica, que es la decisión que hay que tomar despierto: todos los navegadores del mundo Linux son o GTK3 (Firefox y derivados) o Chromium (que además arrastra Qt6 y GTK3 en Alpine). Entonces «tener navegador» no es un ticket del montón A: es elegir entre

autorar el stack GTK3 —revierte una decisión de diseño y reabre GIMP/Inkscape de paso—, o
darle el navegador a qorpa, o sea tratarlo como montón B: el navegador corre en la imagen ajena, hablando Wayland por socket.

La opción 2 es coherente con todo lo demás que ya se decidió, y tiene una ventaja que conviene nombrar: el navegador es justamente el proceso al que menos ganas dan de darle el sistema entero.

OBS no puede ser una app del corpus

Pide qt6-qtbase-dev, qt6-qtbase-private-dev y qt6-qtsvg-dev, y Qt6 vive sólo en incoming-kde/. Una receta resuelve sibling-first y después el catálogo padre: desde el corpus no se alcanza una cola. O sea que OBS hoy sólo puede existir dentro de la cola de KDE, y entonces no es una app de las cuatro imágenes sino una app de KDE. Súmese X11 (libx11, libxcb, libxcomposite, libxinerama) y 20 recetas nuevas (libdatachannel, librist, libsrt, mbedtls, rnnoise, x264, luajit, swig, vlc…).

Si lo que se quiere es grabar la pantalla —que es el 80% de para qué se instala OBS— eso ya está al alcance de la mano: wf-recorder sale con CERO recetas faltantes y cero muros, porque su cierre (wayland, ffmpeg, libdrm) quedó completo cuando entró mpv.

Orden propuesto, en reemplazo del del ADR

✅ mpv — hecho (2026-09-03).
decisión de audio del corpus (el ⚠ de arriba). Destraba wf-recorder y le da a mpv su salida nativa. Es una decisión, no una campaña.
wf-recorder — inmediato una vez tomada esa decisión; cubre el caso de uso principal de OBS.
✅ visor de imágenes — hecho (2026-09-03), pero con swayimg 4.7 y no imv: imv está bloqueada por el muro de GL de escritorio (sección de arriba). En las cuatro imágenes. 4b. ✅ luajit — hecha (2026-09-03). Destrabó swayimg 5.5 y queda disponible para mpv.
✅ zathura + backend PDF — hecho (2026-09-03). La sospecha de GTK3 era falsa: upstream VACIÓ girara (en 2026.07.18 son siete .c de utilidades, cero GTK) y toda la UI se mudó a zathura, que pide GTK4 >= 4.12 — que está en el corpus. Costó 5 recetas nuevas (girara, xxhash, poppler-glib, zathura, zathura-pdf-poppler) + 4 promociones gratis al corpus (json-glib, lcms2, glib-shared, pcre2-shared, bzip2-shared). No va en escritorio-kde: 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.
Decisión de navegador — no es trabajo de recetas, es la elección de arriba. No debería entrar a una cola de build hasta que esté tomada.

OBS, Firefox, Chromium, GIMP y LibreOffice salen del montón A hasta que se decida GTK3 o qorpa. Que se llame montón A y no se pueda construir es peor que no tenerlo en la lista: es deuda fantasma, la misma figura que la terna de GNOME que había que sacar de targets.toml para que el grafo dejara de mentir.

Reproducir la medición

⚠ Ya no se reproduce así. Lo que sigue describe el método ORIGINAL, que es el que falló las tres veces documentadas arriba; se deja escrito para que se entienda de dónde salieron los números de la tabla. El triaje de una app nueva se hace hoy cruzando sus makedepends contra scripts/provee.py --desde corpus, que pregunta por el artefacto y no por el catálogo.

/tmp/.../triaje-apps.py fue un script de una sola vez; si hace falta repetirlo, lo que hace es: bajar el APKBUILD de cada candidata, extraer makedepends/depends, quitarles el sufijo -dev, y cruzar contra recipes/*.toml + recipes/incoming-*/*.toml, separando una lista fija de nombres que son muros de diseño (gtk+3.0, qt6-, lib X11, wasi-). No se guarda en scripts/ porque la lista de candidatas es del momento, no un invariante que valga la pena vigilar.

16 KiB Raw Blame History