sergioandClaude Opus 5
fe474dab63
Tercera tanda curada, agrupada por la URL DE FUENTE de cada receta (que es la evidencia que el nombre no da): los once módulos Qt sin prefijo, freedesktop (dbus, libinput, libevdev, libdisplay-info, poppler, pulseaudio, upower, NetworkManager, ModemManager, polkit), kernel.org (los tres kernels, linux-headers, git, iproute2, libuuid) y PyPI. Los kernels llevan `GPL-2.0-only WITH Linux-syscall-note` explícita. No es adorno: sin esa excepción, todo binario de espacio de usuario que hace un syscall sería obra derivada del kernel. Es exactamente el tipo de dato que un campo de licencia existe para no perder. Quedan 147 sin declarar: 69 de GitHub donde la propia API dice NOASSERTION (hay que abrir el fuente), 20 de tawasuyu —que son nuestras o del otro agente, así que la licencia la decide el usuario, no yo— y el resto repartido en GNOME, gitlab.freedesktop y sueltos. Más 71 con SPDX ambiguo pendientes de desambiguar (`licencias.sh --revisar`). Hashes verificados otra vez sobre 20 recetas tocadas: 20 idénticos, 0 cambiados. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
68 lines
3.7 KiB
TOML
68 lines
3.7 KiB
TOML
# wlr-randr 0.5.0 — el `xrandr` de wlroots: lista y configura salidas hablando
|
|
# `wlr-output-management-unstable-v1`.
|
|
#
|
|
# Entra a hammer con un rol acotado y explícito: es el **testigo ajeno** de que
|
|
# mirada sirve ese protocolo de verdad. La paridad cosmic no se demuestra con un
|
|
# cliente nuestro —eso probaría que nos entendemos con nosotros mismos—, se
|
|
# demuestra con la herramienta que el resto del mundo usa. Por eso se instala
|
|
# aunque el camino soberano (`mirada-ctl output` y el panel de pata) sea el que
|
|
# el usuario va a usar todos los días.
|
|
#
|
|
# Lo que hoy NO puede hacer, y conviene saberlo antes de acusar al paquete: en
|
|
# mirada `apply`/`test` de `zwlr_output_configuration_v1` contestan `failed`
|
|
# (`mirada-compositor/src/output_management.rs`), así que wlr-randr **lista**
|
|
# correctamente y **no cambia nada**. Cuando mirada implemente el apply, esta
|
|
# misma receta pasa a ser también la prueba de que el apply anda.
|
|
#
|
|
# Por lo mismo NO entran `kanshi` ni `way-displays`: no son herramientas sino una
|
|
# función —perfiles de salida por hotplug— y su lugar es adentro de mirada, que
|
|
# ya tiene el estado. Instalarlos hoy además sería inútil: rechazaría cada
|
|
# perfil que intentaran aplicar.
|
|
#
|
|
# C puro sobre meson. Trae el XML del protocolo adentro (`protocol/`), así que no
|
|
# necesita wayland-protocols — sólo `wayland-client` y `wayland-scanner`, que
|
|
# vienen de la receta `wayland`. `scdoc` es opcional (la man page); se omite.
|
|
|
|
name = "wlr-randr"
|
|
version = "0.5.0"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
# Tarball de RELEASE, no el `-/archive/` autogenerado de GitLab: los archivos
|
|
# generados no son estables byte a byte en el tiempo y un sha256 pinneado sobre
|
|
# ellos se rompe solo. Mismo criterio que `recipes/wayland-protocols.toml`.
|
|
tarball = "https://gitlab.freedesktop.org/emersion/wlr-randr/-/releases/v0.5.0/downloads/wlr-randr-0.5.0.tar.gz"
|
|
sha256 = "a64b6eb296d1c75af098fa2d229f9aaf3ceae45eeff24056930bd4bc613c6a5e"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
[build.phases]
|
|
# `-Dwerror=false`: el proyecto compila con `werror=true` por defecto y una
|
|
# versión de compilador distinta de la que usan sus CI convierte cualquier aviso
|
|
# nuevo en un fallo de build. La receta no está para pelearse con eso.
|
|
configure = "meson setup output --prefix=/usr --buildtype=release -Dwerror=false"
|
|
compile = "ninja -C output"
|
|
install = "DESTDIR=/out ninja -C output install"
|
|
|
|
[deps]
|
|
# `python3` es OBLIGATORIO aunque no lo parezca: **meson es un script de Python**, no un binario.
|
|
# Sin él la fase configure muere con `exec: line 2: python3: not found` y **exit 127** — que se lee
|
|
# como «meson no está» cuando meson SÍ está (su artefacto se hidrata bien; lo que falta es el
|
|
# intérprete). Diagnosticado en el worker el 2026-08-07: gtk4, libadwaita y gtksourceview construyen
|
|
# ahí sin problema **precisamente porque sí declaran python3**, y ésta no lo hacía.
|
|
# ⇒ Regla: toda receta con meson en `[deps].build` necesita python3 al lado.
|
|
# El arreglo es hidratar la dep, NO instalar python3 en el rootfs del worker: engordar el rootfs
|
|
# haría que el build dependa de qué hay en una máquina concreta, que es justo lo que rompe la
|
|
# reproducibilidad (ver la nota `rootfs-laptop-worker-divergen`).
|
|
#
|
|
# `libffi` NO lo usa wlr-randr: lo exige `wayland-client.pc` en su línea `Requires`, y pkgconf
|
|
# resuelve el grafo de .pc COMPLETO antes de dar un cflag. O sea que falta la dep de la dep. Es el
|
|
# patrón ya documentado `.pc Requires` → `[deps].build` (nota `etapa-g-gui-chain-boundary`): el
|
|
# síntoma es «Package 'libffi', required by 'wayland-client', not found», que se lee como un problema
|
|
# de wayland y no lo es.
|
|
build = ["meson", "samurai", "python3", "pkgconf", "wayland", "libffi"]
|
|
run = ["wayland"]
|