Primera de las 12 recetas del corpus en deuda, cerrada. Y de paso desmiente el diagnóstico
heredado («las 12 fallan por el rootfs del worker: python OSError en meson, find_package en
cmake»). Medido hoy contra el worker, las causas son CUATRO distintas y ninguna es el
rootfs:
· gtk4 construye ahí SIN TOCAR NADA. Nunca había fallado: el bucle del worker sólo recorre
las colas `incoming-*` y NO incluye el corpus, así que las 12 jamás se intentaron. La
deuda no era técnica, era de encolado.
· wlr-randr (ésta): dos deps que faltaban en la receta.
· dwarves: FindDWARF no halla las libs ELF/DWARF pese a declarar elfutils. Pendiente.
· mirada-compositor, mirada-greeter, llimphi-counter: `repo = gitea@git.tawasuyu.net:...`
por SSH. El worker es SIN SECRETOS por diseño ⇒ son HUB-ONLY estructuralmente, no un
fallo. Y llimphi-counter ni siquiera es un fallo de build: su commit es literalmente
ceros, con un comentario «fijar al commit real» — es una receta sin terminar, y es de
tawasuyu.
LAS DOS DEPS DE ESTA RECETA, que son dos lecciones distintas:
1. `python3` — porque **meson es un script de Python, no un binario**. Faltando el
intérprete la fase muere con exit 127, que se lee como «meson no está» cuando meson SÍ
está y se hidrata bien. gtk4/libadwaita/gtksourceview construyen en el worker
precisamente porque sí lo declaran. Auditadas las 1141 recetas: wlr-randr era **la
única** con meson y sin python3. Regla: meson en deps ⇒ python3 al lado.
2. `libffi` — que wlr-randr no usa. Lo exige `wayland-client.pc` en su línea `Requires`, y
pkgconf resuelve el grafo de .pc completo antes de emitir un cflag. Patrón ya
documentado `.pc Requires` → `[deps].build`; el síntoma («Package 'libffi', required by
'wayland-client', not found») culpa a wayland, que es inocente.
En ambos casos el arreglo es hidratar la dep, NO instalar nada en el rootfs del worker:
engordarlo haría que el build dependa de qué hay en una máquina concreta, que es justo lo
que rompe la reproducibilidad.
Re-hashear sale gratis: la receta estaba en deuda, nunca se había sellado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La paridad cosmic no se demuestra con un cliente nuestro (eso probaria que nos
entendemos con nosotros mismos), se demuestra con la herramienta que usa el
resto del mundo. wlr-randr habla wlr-output-management-unstable-v1, que mirada
sirve. Entra a base-system-1 con ese rol acotado.
C sobre meson, 28 KB, trae el XML del protocolo adentro: solo wayland-client.
Tarball de release y no el -/archive/ autogenerado de GitLab, que no es estable
byte a byte y rompe el sha256 pinneado con el tiempo.
Queda anotado en la receta lo que hoy NO puede hacer, para no acusar al paquete:
en mirada apply/test de zwlr_output_configuration_v1 contestan failed, asi que
wlr-randr lista bien y no cambia nada. Cuando mirada implemente el apply, esta
misma receta pasa a probar tambien el apply.
Por lo mismo no entran kanshi ni way-displays: no son herramientas sino una
funcion —perfiles de salida por hotplug— y su lugar es adentro de mirada, que ya
tiene el estado. Instalarlos hoy seria ademas inutil.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5