From 7b2489a03c6a23604cc954fe5bb1ca05f638869e Mon Sep 17 00:00:00 2001 From: sergio Date: Fri, 7 Aug 2026 12:27:03 -0400 Subject: [PATCH] =?UTF-8?q?deuda=20del=20corpus:=20las=2012=20no=20eran=20?= =?UTF-8?q?un=20problema,=20eran=20cuatro=20=E2=80=94=20medido=20en=20el?= =?UTF-8?q?=20worker?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fui a destrabar «las 12 recetas en deuda» con el diagnóstico heredado (fallan por el rootfs del worker: python OSError en meson, find_package en cmake). Lo probé construyéndolas de verdad y **el diagnóstico es falso**: cmake y meson corren perfectamente ahí. Son cuatro situaciones distintas y ninguna es el rootfs. (a) SEIS ESTÁN SUPERADAS, NO EN DEUDA. `gtk4` del corpus es link=static y enlaza libfontconfig.a, que tiene 1122 reubicaciones no-PIC ⇒ 13.032 errores `R_X86_64_64 cannot be used against local symbol`. No es una receta rota: es imposible. Y mientras tanto recipes/incoming-gnome/gtk4.toml (link=dynamic, deps -shared) YA ESTÁ SELLADA, con libadwaita y fontconfig-shared. O sea que la cadena estática del corpus —gtk4, libadwaita, gtksourceview y los tres hello/edit que cuelgan— es un DUPLICADO superado de la cadena dinámica de GNOME. Cerrarla no es construirla: es decidir si se promueven las sombras -shared al corpus, porque la resolución de deps es hermano→padre. Es una decisión de arquitectura, y hay aviso registrado de que promover a ciegas hace que variantes homónimas pisen recetas canónicas. NO la tomo yo. (b) wlr-randr: cerrada en el commit anterior. (c) dwarves: frente propio con muro identificado, no deuda. Nuestro elfutils entrega SÓLO libelf a propósito (libdw arrastra argp/obstack/fts, lo difícil en musl). No se arregla ampliando elfutils: de él cuelga el kernel que ya reproduce bit a bit. El camino es una receta aparte `elfutils-libdw`, con el patrón de las sombras -shared. Sin urgencia: ningún perfil pide dwarves y el kernel desactiva DEBUG_INFO_BTF justamente por su ausencia. Queda escrito en la cabecera de la receta, que es donde se va a leer. (d) mirada-compositor, mirada-greeter, llimphi-counter: source por SSH a git.tawasuyu.net y el worker es SIN SECRETOS por diseño ⇒ HUB-ONLY estructural, no fallo. llimphi-counter ni siquiera llega a construir: su commit son ceros con el comentario «fijar al commit real». Receta sin terminar, y es de tawasuyu. EL HALLAZGO DE FONDO: el bucle del worker sólo recorre las colas incoming-*; el corpus (recipes/) NO está en QUEUES. Las 12 nunca se habían intentado allí. Buena parte de «la deuda» era de ENCOLADO, no técnica — y por eso el diagnóstico heredado nunca se verificó. Co-Authored-By: Claude Opus 5 (1M context) --- docs/20-catalogo-publicable-y-completa.md | 45 ++++++++++++++++++++--- recipes/dwarves.toml | 21 +++++++++++ 2 files changed, 60 insertions(+), 6 deletions(-) diff --git a/docs/20-catalogo-publicable-y-completa.md b/docs/20-catalogo-publicable-y-completa.md index 548cf272..cfdc21f1 100644 --- a/docs/20-catalogo-publicable-y-completa.md +++ b/docs/20-catalogo-publicable-y-completa.md @@ -48,14 +48,47 @@ gtk4 libadwaita gtksourceview gtk4-hello adwaita-hello sourceview-hello hammer-edit mirada-compositor mirada-greeter dwarves llimphi-counter wlr-randr ``` -Es **la cadena GUI de la cascada de mesa**, y tiene una causa conocida y un bloqueo conocido: +> ### ⚠️ CORREGIDO EL MISMO DÍA, MIDIENDO CONTRA EL WORKER +> La primera versión de esta sección decía que las 12 «fallan en el worker por su rootfs: `python +> OSError` en meson, `find_package` en cmake» y que el arreglo era declarar las herramientas en +> `[deps]`. **Se probó y es falso.** cmake y meson corren perfectamente en el worker. Las causas son +> **cuatro, distintas**, y ninguna es el rootfs. Se descubrió al construirlas de verdad en vez de +> heredar el diagnóstico. -> No se pueden construir en el laptop por el **zig-skew** (rompe cairo), y **fallan en el worker por -> su rootfs**: `python OSError` en meson y `find_package` en cmake, porque el worker no trae python3 -> ni cmake. El arreglo correcto **no es engordar el rootfs del worker** sino declarar las -> herramientas en `[deps]` de cada receta. Ver la nota `rootfs-laptop-worker-divergen`. +**(a) Seis están bloqueadas por el muro del PIC — y el frente GNOME ya lo venció por otro camino.** +`gtk4` del corpus es `link = "static"` y enlaza `libfontconfig.a`, que tiene **1122 reubicaciones +no-PIC**: el enlace produce **13 032 errores** `relocation R_X86_64_64 cannot be used against local +symbol`. No es una receta rota, es una imposibilidad estructural. Mientras tanto +`recipes/incoming-gnome/gtk4.toml` —`link = "dynamic"` con las deps `-shared`— **está sellada**, y +con ella `libadwaita` y `fontconfig-shared`. +⇒ La cadena del corpus (`gtk4`, `libadwaita`, `gtksourceview`, `gtk4-hello`, `adwaita-hello`, +`sourceview-hello`, `hammer-edit`) es un **duplicado superado** de la cadena dinámica de GNOME. +Cerrarla no es «construirla»: es decidir si se **promueven las sombras `-shared` al corpus**, porque +la resolución de deps es hermano→padre y una receta del corpus no ve a las de `incoming-gnome`. +**Es una decisión de arquitectura, no una tarea** — y hay un aviso registrado de que promover a +ciegas hace que variantes homónimas pisen recetas canónicas. -**Esto es el primer trabajo técnico a hacer, y desbloquea las 12 de una vez.** +**(b) `wlr-randr` — ✅ CERRADA HOY.** Le faltaban dos deps: `python3` (porque **meson es un script de +Python**; sin intérprete la fase muere con exit 127, que se lee como «meson no está») y `libffi` +(que la receta no usa: lo exige `wayland-client.pc` en su `Requires`). Auditadas las 1141 recetas, +era **la única** con meson y sin python3. + +**(c) `dwarves` — frente propio, no deuda.** Falla porque nuestro `elfutils` entrega **sólo libelf**, +deliberadamente: libdw arrastra argp/obstack/fts, «lo verdaderamente difícil en musl». Y no se +arregla ampliando `elfutils`, porque de él cuelga **el kernel que ya reproduce bit a bit**; el camino +correcto es una receta aparte `elfutils-libdw`. Sin urgencia: ningún perfil lo pide y el kernel +desactiva `DEBUG_INFO_BTF` explícitamente por su ausencia. Se desbloquea cuando se quiera sched-ext. + +**(d) `mirada-compositor`, `mirada-greeter`, `llimphi-counter` — HUB-ONLY estructural.** Su `source` +es `gitea@git.tawasuyu.net:...` por SSH y **el worker es sin secretos por diseño**. No es un fallo. +`llimphi-counter` ni siquiera llega a construir: su `commit` es literalmente ceros, con el comentario +«fijar al commit real» — es una receta sin terminar, y es de tawasuyu. + +### Y el hallazgo de fondo: nadie las estaba intentando +El bucle del worker recorre `QUEUES="recipes/incoming recipes/incoming-go recipes/incoming-clib +recipes/incoming-gnome-onda1 recipes/incoming-gnome-onda2 recipes/incoming-gnome recipes/incoming-kde"` +— **el corpus (`recipes/`) no está en la lista**. Las 12 nunca se habían intentado en el worker. Buena +parte de «la deuda» era de encolado, no técnica. ## I.2 🚨 Lo legal — bloqueante diff --git a/recipes/dwarves.toml b/recipes/dwarves.toml index 9b0215ae..04e2feb8 100644 --- a/recipes/dwarves.toml +++ b/recipes/dwarves.toml @@ -11,6 +11,27 @@ # libbpf EMBEBIDO (-DLIBBPF_EMBEDDED=ON, el default del tarball que vendorea libbpf): evita # una receta libbpf aparte hoy; si libbpf entra al catálogo por otro frente, se despega. # +# ── 🧱 EL MURO REAL, MEDIDO EN EL WORKER 2026-08-07 (antes se creía que era el rootfs) ────────── +# Falla en `configure` con: +# CMake Error at cmake/modules/FindDWARF.cmake:93 (message): +# Could NOT find some ELF and DWARF libraries, please install the missing packages +# NO es que falte cmake ni que el rootfs del worker esté flaco: cmake corre perfectamente. Lo que +# falta es **libdw**. Nuestro artefacto de `elfutils` entrega SÓLO libelf (`libelf.a/.so`, `libelf.h`, +# `gelf.h`) — sin `libdw`, sin `dwarf.h` — y eso es DELIBERADO: su cabecera dice que libdw/libdwfl +# arrastran argp/obstack/fts, «lo verdaderamente difícil en musl». Aquella receta existe para el +# `objtool` del kernel, que sólo necesita libelf. +# +# ⚠ Y NO se arregla ampliando `elfutils`: de él cuelgan `linux`, `linux-generic`, `linux-metal` y +# `linux-metal-dual`, o sea **el kernel que ya reproduce bit a bit**. Tocarlo re-hashea ese baseline +# validado a cambio de una herramienta que hoy nadie pide. El camino correcto es una receta APARTE +# —`elfutils-libdw`— igual que el patrón de las sombras `-shared`: deja intacto lo sellado y paga el +# coste de musl una sola vez, donde se necesita. +# +# ⇒ CLASIFICACIÓN HONESTA: esto NO es «una receta en deuda» sino un frente propio, con muro conocido +# (portar libdw a musl) y sin urgencia: ningún perfil de `targets.toml` pide dwarves, y el kernel +# desactiva `DEBUG_INFO_BTF` explícitamente «para evitar pahole, ausente del toolchain». Se +# desbloquea cuando se quiera sched-ext, no antes. +# # BLOQUEADA (intento real en worker 2026-07-17): el cmake no halla libdw/dwarf.h porque el # artefacto sellado de elfutils sólo empaqueta LIBELF (headers + .a/.so — lo que kbuild # necesita), no libdw. Y elfutils.toml es INTOCABLE: es build-dep de los kernels sellados