Files
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 /
2026-09-09 19:23:26 +00:00

57 lines
3.2 KiB
TOML

# libva 2.22.0 — Video Acceleration API (libva.so + libva-drm.so + libva-wayland.so). Entró por la
# campaña KDE (ADR 0011): **kpipewire** los exige REQUIRED (`pkg_check_modules(LIBVA ... libva
# REQUIRED)` + libva-drm) para codificar por hardware los streams que graba KPipeWireRecord.
#
# Es sólo la capa de despacho: los drivers reales (intel-media-driver / mesa gallium VA) son RUNTIME y
# se cargan por dlopen — no hacen falta para compilar.
#
# ══ SUBIÓ AL CORPUS, Y LA COPIA DE LA COLA SE JUBILÓ (2026-09-04) ══════════════════════════════
# Vivía en `incoming-kde/` y por eso mpv —que está en el corpus— no la alcanzaba: una receta resuelve
# SIBLING-FIRST y después el catálogo padre, nunca una cola hermana. Ése era el último hueco de mpv:
# sin decodificación por hardware.
#
# La mudanza fue GRATIS y se midió antes de hacerla, no después: las CINCO deps de esta receta
# (meson, samurai, python3, pkgconf, libdrm) viven sólo en el corpus, o sea que `incoming-kde` ya las
# resolvía por caída al padre ⇒ el cierre no cambia. `takana hash` dio el MISMO ArtifactHash
# (b3:405c6211…) en las dos rutas. Se MUEVE, no se copia: dos ficheros para un artefacto es el cuadro
# de las dos glib esperando a que uno de los dos derive. Las recetas KDE la siguen alcanzando por
# caída al padre.
#
# ══ WAYLAND ENCENDIDO — NO ES OPCIONAL PARA mpv ════════════════════════════════════════════════
# Antes iba `-Dwith_wayland=no` («sólo backend DRM, el que usa kpipewire»). Para mpv eso NO alcanza, y
# la razón está en su `meson.build:1464`: el feature `vaapi` se REQUIERE contra
# `vaapi-drm or vaapi-wayland or vaapi-x11 or vaapi-win32` — o sea que **`-Dvaapi=enabled` a secas no
# habilita nada; hace falta un backend**. De los cuatro: x11 y win32 están fuera (la distro es
# Wayland-only), y `vaapi-drm` exige además `features['drm']` de mpv, que está apagado porque `vo=drm`
# pide `libdisplay-info`, que no tenemos. Queda `vaapi-wayland`, que pide `libva-wayland` ⇒ esta
# perilla. `wayland` entra a `[deps]` por el `libva-wayland.pc` que genera.
#
# Esto SÍ cambia el ArtifactHash (a diferencia de la mudanza) ⇒ radio medido: 2 dependientes,
# incoming-kde/kpipewire e incoming-kde/spectacle. Los dos reconstruyen.
name = "libva"
version = "2.22.0"
license = "MIT"
[source]
tarball = "https://github.com/intel/libva/archive/refs/tags/2.22.0.tar.gz"
sha256 = "467c418c2640a178c6baad5be2e00d569842123763b80507721ab87eb7af8735"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
flags = []
[build.phases]
configure = '''
PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release \
-Ddefault_library=shared \
-Dwith_x11=no -Dwith_glx=no -Dwith_wayland=yes -Dwith_win32=no -Ddisable_drm=false \
-Denable_docs=false
'''
compile = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install -C output --no-rebuild"
[deps]
build = ["meson", "samurai", "python3", "pkgconf", "libdrm", "wayland"]