main
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Sergio
|
e852f48491 |
takana etapa 5a: los comentarios de las 741 recetas
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no hasheaban de antes). El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de TOML y no entra ahí. Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales dentro de fases), hammerd, hammer-recover y toda ruta que empiece por / |
||
|
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
|
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. |
||
|
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. |
||
|
Sergio
|
032aa02582 |
lua5.2 5.2.4: mpv gana el OSC — la barra, las estadísticas y la consola
El OSC de mpv es `player/lua/osc.lua`: sin Lua el reproductor anda y responde al teclado pero NO DIBUJA NADA de interfaz. La `lua` del corpus no sirve — `meson.build:701` acepta 5.1, 5.2 o LuaJIT y el `lua.pc` genérico va acotado a `>=5.1.0, <5.3.0`; la nuestra es 5.4.8 y entró para wireplumber. CÓMO CONVIVEN LAS DOS SIN PISARSE, que es lo que hace legítimo tener dos Lua: esta receta instala **sólo la librería**. Sin `/usr/bin/lua`, sin `luac` y sin `lua.pc` genérico — que son exactamente los tres ficheros que colisionarían si una imagen hidratara las dos. Las `.so` no colisionan porque el SONAME lleva la versión, y los headers van a `/usr/include/lua5.2/` porque los de 5.2 y 5.4 se llaman igual y dicen cosas distintas. La diferencia con 5.4 que muerde: en 5.2.4 `luaconf.h:43-49` hace que `LUA_USE_LINUX` implique `LUA_USE_READLINE` (en 5.4 eso vive en el target `linux-readline` del Makefile). Se esquiva construyendo el target `a` —sólo `liblua.a`— en vez de `all`: `LUA_USE_READLINE` lo consume nada más que `lua.c`, el binario del REPL, que acá no se compila. Sale gratis y de paso es lo que hace que no haya `/usr/bin/lua` que colisione. `-Dlua=lua5.2` y no `auto`: auto recorre ocho nombres de `.pc` y se lleva el primero que encuentre en el sandbox ⇒ el artefacto dependería de qué otra cosa quedó montada en el lab. EVIDENCIA, del mpv re-sellado (b3:d9072a10): List of enabled features: … libass libplacebo **lua5.2** … wayland [cplayer] Set property: user-data/osc/visibility="auto" -> 1 [cplayer] Done loading scripts. o sea que el script del OSC no sólo compiló: se carga y corre. alsa-lib: se corrige el comentario, que decía que las pipewire iban con `-Dpipewire-alsa=disabled`. Ya no. Y queda escrito el gotcha que costó encontrarlo: el `alsa.conf` que instala carga `/var/lib/alsa/conf.d`, `/usr/etc/alsa/conf.d` y `/etc/alsa/conf.d`, NO `/usr/share/alsa/alsa.conf.d`, que es donde meson deja la config del plugin. |
||
|
Sergio
|
16e2be84d4 |
mpv 0.41.0: la primera app gráfica de usuario final del corpus
Cuatro escritorios que cierran y ninguna forma de abrir un video. El ADR 0015 ordenó los montones
y puso a mpv primero del A —lo que no tiene muro estructural, sólo falta escribirlo—. Éste es.
Sellada b3:8e6ab4e7. Evidencia de que ANDA, no sólo de que sella:
· `mpv --version` corre con el loader musl → v0.41.0, libplacebo v7.360.1, FFmpeg 7.1
· decodifica un h264 640x480 + AAC de prueba, 75 frames, `Exiting... (End of file)`
· `--vo=help` → `gpu-next` (libplacebo) y `gpu`; `--ao=help` → `alsa`
· `--gpu-context=help` → SÓLO `wayland` (Wayland/EGL). Ni un contexto X11 en el binario.
· NEEDED: libav*, libplacebo, libasound, libEGL, libc. Cero glibc, cero X11.
En el corpus y no en una cola: un reproductor lo quieren las cuatro imágenes, y una receta resuelve
sibling-first + catálogo padre, nunca una cola hermana.
`-Dbuild-date=false` no es cosmético: su default estampa la fecha de compilación DENTRO del binario
⇒ dos builds del mismo commit darían bytes distintos y el artefacto dejaría de reproducir.
`-Dprefer_static=true` (como foot) porque sin él meson resuelve los `.pc` sin `Libs.private` y el
link muere con símbolos `XML_*` sin definir «en libfontconfig.a» — culpando a fontconfig cuando lo
que falta es propagar expat.
Las ~90 opciones van EXPLÍCITAS: casi todas nacen `auto`, o sea que miran el sandbox y se prenden
con lo que encuentren. Misma trampa que ffmpeg cierra con `--disable-autodetect`.
TRES HUECOS CONOCIDOS, escritos en la receta para que no se descubran en la mano del usuario:
1. audio ALSA, y las tres pipewire llevan `-Dpipewire-alsa=disabled` ⇒ hoy no suena en un
escritorio con PipeWire vivo. Radio de darlo vuelta: 4/3/2. Es el próximo paso.
2. sin Lua ⇒ sin OSC. mpv 0.41 sólo acepta 5.1/5.2/LuaJIT y la del corpus es 5.4.8 (wireplumber).
3. sin vaapi ⇒ sin decodificación por hardware (libva está sólo en incoming-kde), y el ffmpeg
heredado va `--disable-x86asm` ⇒ tampoco SIMD.
|