sergio/takana

1# wlr-randr 0.5.0 — el `xrandr` de wlroots: lista y configura salidas hablando
2# `wlr-output-management-unstable-v1`.
3#
4# Entra a hammer con un rol acotado y explícito: es el **testigo ajeno** de que
5# mirada sirve ese protocolo de verdad. La paridad cosmic no se demuestra con un
6# cliente nuestro —eso probaría que nos entendemos con nosotros mismos—, se
7# demuestra con la herramienta que el resto del mundo usa. Por eso se instala
8# aunque el camino soberano (`mirada-ctl output` y el panel de pata) sea el que
9# el usuario va a usar todos los días.
10#
11# Lo que hoy NO puede hacer, y conviene saberlo antes de acusar al paquete: en
12# mirada `apply`/`test` de `zwlr_output_configuration_v1` contestan `failed`
13# (`mirada-compositor/src/output_management.rs`), así que wlr-randr **lista**
14# correctamente y **no cambia nada**. Cuando mirada implemente el apply, esta
15# misma receta pasa a ser también la prueba de que el apply anda.
16#
17# Por lo mismo NO entran `kanshi` ni `way-displays`: no son herramientas sino una
18# función —perfiles de salida por hotplug— y su lugar es adentro de mirada, que
19# ya tiene el estado. Instalarlos hoy además sería inútil: rechazaría cada
20# perfil que intentaran aplicar.
21#
22# C puro sobre meson. Trae el XML del protocolo adentro (`protocol/`), así que no
23# necesita wayland-protocols — sólo `wayland-client` y `wayland-scanner`, que
24# vienen de la receta `wayland`. `scdoc` es opcional (la man page); se omite.
25
26name    = "wlr-randr"
27version = "0.5.0"
28license = "MIT"
29
30[source]
31# Tarball de RELEASE, no el `-/archive/` autogenerado de GitLab: los archivos
32# generados no son estables byte a byte en el tiempo y un sha256 pinneado sobre
33# ellos se rompe solo. Mismo criterio que `recipes/wayland-protocols.toml`.
34tarball = "https://gitlab.freedesktop.org/emersion/wlr-randr/-/releases/v0.5.0/downloads/wlr-randr-0.5.0.tar.gz"
35sha256  = "a64b6eb296d1c75af098fa2d229f9aaf3ceae45eeff24056930bd4bc613c6a5e"
36
37[build]
38compiler = "zig-cc"
39target   = "x86_64-linux-musl"
40link     = "static"
41
42[build.phases]
43# `-Dwerror=false`: el proyecto compila con `werror=true` por defecto y una
44# versión de compilador distinta de la que usan sus CI convierte cualquier aviso
45# nuevo en un fallo de build. La receta no está para pelearse con eso.
46configure = "meson setup output --prefix=/usr --buildtype=release -Dwerror=false"
47compile   = "ninja -C output"
48install   = "DESTDIR=/out ninja -C output install"
49
50[deps]
51# `python3` es OBLIGATORIO aunque no lo parezca: **meson es un script de Python**, no un binario.
52# Sin él la fase configure muere con `exec: line 2: python3: not found` y **exit 127** — que se lee
53# como «meson no está» cuando meson SÍ está (su artefacto se hidrata bien; lo que falta es el
54# intérprete). Diagnosticado en el worker el 2026-08-07: gtk4, libadwaita y gtksourceview construyen
55# ahí sin problema **precisamente porque sí declaran python3**, y ésta no lo hacía.
56# ⇒ Regla: toda receta con meson en `[deps].build` necesita python3 al lado.
57# El arreglo es hidratar la dep, NO instalar python3 en el rootfs del worker: engordar el rootfs
58# haría que el build dependa de qué hay en una máquina concreta, que es justo lo que rompe la
59# reproducibilidad (ver la nota `rootfs-laptop-worker-divergen`).
60#
61# `libffi` NO lo usa wlr-randr: lo exige `wayland-client.pc` en su línea `Requires`, y pkgconf
62# resuelve el grafo de .pc COMPLETO antes de dar un cflag. O sea que falta la dep de la dep. Es el
63# patrón ya documentado `.pc Requires` → `[deps].build` (nota `etapa-g-gui-chain-boundary`): el
64# síntoma es «Package 'libffi', required by 'wayland-client', not found», que se lee como un problema
65# de wayland y no lo es.
66build = ["meson", "samurai", "python3", "pkgconf", "wayland", "libffi"]
67run   = ["wayland"]