66db5484e98fc67ce06b8b096c3411e61215c26c
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Sergio
|
097579546f |
dwarves: el linker de zig se caía con --dependency-file — una línea, y sin escapar a gcc
`dwarves` estaba SELLADA y llevaba tiempo sin construir. Se destapó al arreglar los symlinks de
`bzip2`: su hash se movió, dwarves cayó a deuda, y al reconstruirla el link murió con
`Error running link command: Segmentation fault` — crash del linker, no error de símbolos.
**No lo rompió el cambio de bzip2, y se puede probar**: el `libbz2.a` y el `bzlib.h` nuevos son
byte-idénticos a los viejos (`cmp -s`); lo único que cambió fueron cuatro destinos de symlink. El
artefacto sellado tapaba una rotura que ya existía — el lab rueda desde Alpine edge y zig subió. El
rehash no causó la rotura: la DESTAPÓ.
## La causa, bisecada sobre la línea de enlace real
CMake deja la línea literal en `build/CMakeFiles/<target>.dir/link.txt`, y el árbol de post-mortem la
conserva. Rehecha a mano FUERA de takana y del sandbox, sustituyendo el wrapper por el `zig` del lab
y las rutas `/usr/lib/*` por las del store:
tal cual → exit 139 (SIGSEGV)
quitando `-static` → exit 139 ⇒ no es el enlace estático
quitando `--dependency-file` → **exit 0** ⇒ ES ESO
`-Xlinker --dependency-file=…` lo emite CMake ≥3.27 para que el LINKER calcule las dependencias de
enlace, y el `lld` de zig 0.16.0 segfaultea procesándolo. `-DCMAKE_LINK_DEPENDS_USE_LINKER=OFF` es la
palanca de upstream (cmake del corpus: 3.31.6).
**Es mejor que `compiler = "gcc"`**, que es como esquivé ayer el MISMO crash en los tres
`protoc-gen-upb*` de protobuf sin conocer la causa: deja la receta en el toolchain por defecto del
proyecto en vez de escapar de él.
⚠ **Y el alcance no son dos recetas: 153 del corpus usan CMake con zig.** Todas selladas, así que hoy
nadie lo ve — pero el crash depende de los inputs (dentro de protobuf caían 3 de ~10 ejecutables), o
sea que no se sabe cuáles fallan hasta que su hash se mueva. Deuda latente pura.
No se arregla poniendo la perilla en el lab: la mayoría de esas 153 traen su `cmake …` EXPLÍCITO en
la receta, así que tocar la fase por defecto no las tocaría **y** re-hashearía a las que sí usan la
heurística. Incompleto y disruptivo a la vez.
Verificado: los 10 ejecutables estáticos con 0 NEEDED —incluidos `codiff` y `dtagnames`, los dos que
segfaulteaban—, `pahole --version` → v1.30, y REPRODUCE bit a bit.
|
||
|
Sergio
|
ba1fb2d3a8 |
licencias: 95% (1114/1164) — la evidencia sale del tarball pineado, offline
`licencias.sh --sembrar` escribe desde una tabla curada a mano y `licencias-desambiguar.sh` resuelve
`-only` vs `-or-later` preguntándole a la búsqueda de código de GitHub. Los dos dejan fuera lo mismo:
lo que nadie curó y lo que no vive en GitHub.
Pero `work/tarballs/` indexa cada tarball por su sha256, así que el árbol EXACTO que la receta pinea
ya está en disco: la declaración del propio autor, en el commit que construimos, sin red. De las 76
sin licencia, 55 tenían su tarball cacheado y 25 salieron con evidencia citable.
`scripts/licencias-tarball.py` la busca en tres niveles: la declaración del autor (`Cargo.toml`,
`meson.build`), un único fichero en `LICENSES/` (REUSE, que usa KDE), y el texto del COPYING más la
CONCESIÓN buscada en las cabeceras de los fuentes — excluyendo COPYING/LICENSE, porque el apéndice
de la GPL trae literalmente «or (at your option) any later version» y buscarla ahí da siempre
positivo siendo plantilla. Es la regla que ya fijó `licencias-desambiguar.sh`, aplicada al árbol
pineado en vez de a GitHub.
La primera versión resolvía 40, y CUATRO estaban mal. Las dejo escritas porque son la forma del
error, no accidentes:
· `socat` salía BSD-2 por su `COPYING.OpenSSL`, que es la excepción, no la licencia. Un `COPYING`
a secas gana ahora a cualquier sufijado.
· `pigz` salía Apache-2.0 por `zopfli/COPYING`: la licencia de una pieza VENDORIZADA leída como la
del contenedor. Sólo se mira la raíz.
· `openssh` salía MIT porque su `LICENCE` es un compendio de cuatro y me quedaba con la primera
que pegara. Si el texto trae varias, no hay veredicto: lo compone un humano.
· `nano` salía GPL-3.0-**or-later** citando el «either version 2» de su `aclocal.m4` — plantilla de
autotools, no del proyecto, y encima de otra versión. Ahora la cita tiene que venir de un fichero
del autor Y hablar de la misma versión mayor que el COPYING.
Y dos bugs míos que producían el mismo daño en silencio: la marca de BSD-3 era «Neither the name of»,
que libpcap y libzip no usan («The names of the authors may not be used to endorse») ⇒ se declaraban
BSD-2; y el mayor de versión lo sacaba de `"GPL-3.0".rsplit("-",1)[0][-1]`, que da «L», así que la
comprobación de coherencia rechazaba TODA cita válida.
La validación final no es una regex: un identificador vale si tenemos su texto en `licenses/`. La
obligación legal es acompañar el binario del TEXTO, así que un SPDX que no podemos entregar no
adelanta nada y sí crea una afirmación que no se sostiene. Eso es lo que atrapa el «GPL2+» que meson
deja escribir en `gsd-schemas` y `libgdm`, que no es un SPDX sino taquigrafía.
Nada se sembró a ojo: cada línea de `docs/licencias-evidencia.tsv` lleva la cita que la decidió, y
las 50 que quedan salen listadas con lo que SÍ se encontró en vez de rellenarse.
Comprobado que no se invalida nada: los 26 ArtifactHash afectados son idénticos antes y después
(`license` no está en `hash_inputs`) — medido, no supuesto.
|
||
|
SergioandClaude Opus 5
|
7c1492e26d |
dwarves: los DIEZ ejecutables eran dinamicos — y el -static si estaba
La receta decia `link = "static"` y el audit marcaba `pahole`. Mirando el artefacto entero no era uno: eran los DIEZ ejecutables, contra cinco librerias. El `-static` NUNCA faltaba. `build/CMakeFiles/pahole.dir/link.txt` —donde cmake deja la linea de enlace literal— lo tenia puesto en la posicion 9, y mas adelante en la misma linea habia un `.so` de ruta absoluta; el wrapper de cc del lab (`sandbox.rs:597`) quita el `-static` ante cualquier `.so` en la linea, asi que lo ponia cmake y lo sacaba el wrapper. Ese fichero es el sitio donde mirar la proxima vez que `link = "static"` no pegue en un proyecto cmake. Eran TRES `find_*` metiendo `.so`, no uno, y cayeron de a uno: · FindDWARF.cmake → libelf.so ⇒ -DDWARF_LIBRARY/-DELF_LIBRARY a los .a · find_package(ZLIB) (CMakeLists:52) → /usr/lib/libz.so ⇒ -DZLIB_LIBRARY Sin `-static`, ademas, `-llzma`/`-lbz2` resolvian a las .so DEL ROOTFS de Alpine y no a los artefactos de xz/bzip2 (que solo traen .a): entradas no declaradas, de las que rompen el cono de affected.py. `-DCMAKE_FIND_LIBRARY_SUFFIXES=.a` NO sirve y se probo: Platform/Linux.cmake lo asigna como variable NORMAL en `project()` y esa tapa a la del cache. Control, ademas de NEEDED=0 en los diez y la lista de ficheros intacta: el pahole nuevo ARRANCA en el host (el viejo moria con `Error relocating /lib/libelf.so.1: rawmemchr: symbol not found`), dice v1.30 y emite una seccion .BTF real con `-J`, que es lo que hace CONFIG_DEBUG_INFO_BTF. Con eso el punto 3 de la deuda de SDD 25 H7 queda pagado y la herramienta probada de punta a punta. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01ACUcwo9mZsE5ocYVE9npih |
||
|
Sergio
|
e7c2b0022c |
dwarves: CONSTRUYE — frontera libdw/musl cerrada
Cadena completa, cuatro recetas nuevas y una modificada:
musl-obstack -> libobstack (find_package(obstack REQUIRED))
argp-standalone -> libargp (find_package(argp REQUIRED))
musl-fts -> fts(3), que usa libdwfl/linux-kernel-modules.c
elfutils-libdw -> libdw + libdwfl (VARIANTE: la canónica sólo hace libelf
porque de ella cuelgan los cuatro kernels)
Lo que costó, en orden de aparición:
· libdw a secas NO necesita argp/obstack/fts — la nota de la canónica es cierta
de libdwfl y src/, no de libdw. El `obstack` de libdw estaba en un COMENTARIO.
· Pero dwarves SÍ usa libdwfl (15 dwfl_* en dwarf_loader.c) ⇒ vuelven argp y fts.
· libdwfl no compila suelto: hay que seguir el orden de SUBDIRS del raíz
(lib → libelf → libcpu → backends → libebl → libdwelf → libdw → libdwfl →
libdwfl_stacktrace).
· El compat/argp.h de la canónica TAPA el argp real y no declara argp_failure.
· libdw.a GORDA: FindDWARF.cmake pone DWARF_LIBRARIES = libdw + libelf y nada
más, pero libdw necesita libdwfl/libebl/libdwelf/backends/libeu, que son libs
internas. Se fusionan en un archive (patrón de la libgtk-4.a) junto con un
`error()` real, que musl no trae y el shim de la receta sólo daba inline.
· Y al final, lzma/bz2: libdw descomprime .debug_* comprimidas.
Verificado de verdad, no por exit code: pahole v1.30 arranca (con el loader
musl del lab) y DECODIFICA DWARF — sobre un binario de prueba imprime los
offsets, los tamaños y hasta el agujero de 3 bytes de padding.
|
||
 sergioandClaude Opus 5
|
7b2489a03c |
deuda del corpus: las 12 no eran un problema, eran cuatro — medido en el worker
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) <noreply@anthropic.com>
|
||
|
sergioandClaude Fable 5
|
7fa12ed7ce |
piloto harkaq-trace MEDIDO en builds reales: ceguera-overlay confirmada (0 eventos de store, 206 de binds) y salida validada — marcar /proc/<pid-bwrap>/root cae en el SB del overlay y los paths salen en el idioma de la política; zlib-ng SELLADA b3:93d1da8a al 1er intento; dwarves BLOQUEADA (elfutils sellado sin libdw ⇒ pide variante elfutils-libdw)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
sergioandClaude Fable 5
|
d48f9be636 |
zlib-ng 2.2.4 + dwarves 1.30 al catálogo (tanda planes-freebsd-2, sha256 verificados)
zlib-ng: el veredicto T5 hecho receta — dispatch SIMD en runtime en vez de variantes v3; modo ZLIB_COMPAT, zlib.toml intocada (dep del frente rust). dwarves: pahole para destrabar sched-ext; el kernel NO lo declara aún (el análisis de repro BTF/pahole-skew va primero). Ambas al worker. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |