From f24b52df18dd018e0625b7a1ebda894dc73439bf Mon Sep 17 00:00:00 2001 From: sergio Date: Fri, 7 Aug 2026 12:23:28 -0400 Subject: [PATCH] =?UTF-8?q?wlr-randr:=20SELLADA=20=E2=80=94=20eran=20dos?= =?UTF-8?q?=20deps=20ausentes,=20no=20el=20rootfs=20del=20worker?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- recipes/wlr-randr.toml | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/recipes/wlr-randr.toml b/recipes/wlr-randr.toml index d3b281ee..b59b5448 100644 --- a/recipes/wlr-randr.toml +++ b/recipes/wlr-randr.toml @@ -47,5 +47,20 @@ compile = "ninja -C output" install = "DESTDIR=/out ninja -C output install" [deps] -build = ["meson", "samurai", "pkgconf", "wayland"] +# `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"]