26 Commits
Author SHA1 Message Date
sergioandClaude Opus 5 fe474dab63 licencias: 994 de 1141 (87%) — cerradas las familias Qt, freedesktop, kernel.org y PyPI
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>
2026-08-07 13:29:31 -04:00
sergioandClaude Opus 5 a6a9d59e4f licencias: 936 de 1141 (82%) — detección por evidencia, con sus dos imprecisiones declaradas
Esta mañana eran 0. Tras la tabla curada (228) y este paso, 936. Ninguna receta se
re-hasheó: verificado en 30 de las 708 tocadas, 30 hashes idénticos, 0 cambiados.

DE DÓNDE SALE EL DATO, Y POR QUÉ NO ES ADIVINAR. `scripts/licencias-detectar.sh` consulta
la API /repos/{o}/{r}/license de GitHub para las 673 recetas cuya fuente vive allí. Eso
devuelve el resultado de DETECTAR el fichero LICENSE que el repo tiene de verdad
(licensee), no una etiqueta escrita a mano en una web: es la misma evidencia que veríamos
abriendo el tarball, obtenida sin bajar 673 tarballs por un enlace de 8 Mbps. 610 con SPDX
definido; las 63 que GitHub marca NOASSERTION/other se DESCARTAN — un «no sé» de la fuente
se propaga como hueco, no se redondea a una licencia plausible.

Las familias no-GitHub van curadas por la URL DE FUENTE, que es la evidencia que el nombre
no da. Y ahí cometí el error simétrico al que este mismo fichero advertía: había puesto
`knighttime` entre las «herramientas Go» POR SU NOMBRE, y su tarball sale de
download.kde.org — es un Framework de KDE, LGPL. Descartar por nombre falla igual que
aceptar por nombre. Corregido en la cabecera.

LAS DOS IMPRECISIONES, contables con `licencias.sh --revisar` en vez de escondidas:

 1. SPDX OBSOLETOS Y AMBIGUOS (71 recetas). GitHub devuelve `GPL-3.0`, `LGPL-2.1`,
    `AGPL-3.0`… identificadores que SPDX declaró obsoletos PRECISAMENTE porque no
    distinguen `-only` de `-or-later`, y esa diferencia decide con qué se puede combinar el
    paquete. NO se normalizan a ciegas: mapear GPL-3.0 → GPL-3.0-or-later sería inventar el
    dato que falta. Quedan marcadas para resolver mirando el fuente.

 2. LICENCIAS DOBLES COLAPSADAS. La API devuelve UNA sola licencia y muchos proyectos Rust
    son «MIT OR Apache-2.0» (p.ej. `fd` quedó como Apache-2.0). No es falso —cumplir una de
    las opciones concedidas basta— pero es incompleto. Lo resuelve el cierre estructural:
    leer el campo `license` del Cargo.toml en la fase de fetch.

Y un fallo que habría escrito basura en silencio: `licencias-detectadas.tsv` tiene TRES
columnas (añade el owner/repo consultado, para poder auditar) y el sembrador leía dos, así
que la licencia se habría llevado pegado el slug — `license = "MIT<TAB>owner/repo"`, sin
que nada lo validara. Arreglado antes de sembrar.

Quedan 205 sin licencia y 71 por desambiguar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 13:26:22 -04:00
sergioandClaude Opus 5 346cd59706 licencias: campo license en la receta — de 0 a 228 de 1141, sin re-hashear nada
La deuda legal bloqueante del SDD 19 §2.1. Medido hoy: **0 de 1141 recetas** declaraban
licencia, no «5 de 771» como decía el informe anterior. Los dos números estaban mal: los
«5» eran falsos positivos de `grep license` (el paquete `addlicense`, el paquete
`cargo-bundle-licenses`, una línea `install .../share/licenses/` y un comentario), y las
recetas son 1141. Contar con `grep -l <palabra>` sobre TOML cuenta comentarios y nombres,
no campos; `scripts/licencias.sh` cuenta el campo de verdad (clave en la raíz, antes del
primer `[table]`).

LO QUE HACE LA DEUDA PAGABLE: `Recipe::hash_inputs` es una LISTA BLANCA — sólo entran
source, compiler, target, link, patches, flags, phases y deps. `license` no entra, igual
que `evidence` y `slots`. Por eso se puede poblar en las recetas YA SELLADAS sin mover un
solo ArtifactHash. Verificado, no supuesto: en 40 recetas modificadas se comparó el hash
con y sin la línea — 40 idénticos, 0 cambiados. Si el campo entrara al hash, declarar la
licencia costaría reconstruir el corpus entero y no se haría nunca. Clavado con el test
`licencia_round_trip_y_no_afecta_el_hash`.

TRAMPA DE TOML: una clave suelta después de un `[table]` pertenece a esa tabla. Puesta al
final del fichero, `license` acaba dentro de `[deps]` y se pierde EN SILENCIO, porque serde
ignora los campos que no conoce — no hay error, simplemente no está. Va arriba, junto a
`name` y `version`; el sembrador la inserta tras `version`.

NO SE ADIVINA. Declarar mal una licencia es peor que dejarla vacía: convierte un hueco
visible en una afirmación falsa. Sólo se puebla desde una tabla curada entrada por entrada
(`docs/licencias-conocidas.tsv`); lo que no tiene evidencia queda vacío y se CUENTA.
Concretamente se descartó el atajo «k* = KDE ⇒ LGPL»: en este catálogo `kail`, `kind`,
`ko`, `kopia`, `krew`, `kustomize`, `kyverno`, `katana`, `kibi`, `kmon` y toda la familia
`kube*` son herramientas Go sin relación con KDE. El nombre no es evidencia.

Quedan 913, casi todas CLIs Go/Rust importados en masa — y ésas sí son automatizables con
evidencia real: Cargo.toml trae el campo `license` y los módulos Go traen su LICENSE en el
árbol. El cierre estructural es capturarlo en la fase de fetch, que ya descarga y extrae
cada tarball, y inyectar el texto en `hammer pack` (aguas abajo del ArtifactHash) en vez de
en la fase install (que sí re-hashearía).

De paso, respaldo-storagebox.sh reordenado por valor irreemplazable y con zstd: medido en
la oficina, el uplink da 8 Mbps iguales por cable y por wifi ⇒ 128 G no caben en una
sentada, así que sube primero el cerebro (estado + repo) y `--partial-dir` hace que cortar
a mitad de un artefacto no tire lo ya subido.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 10:24:11 -04:00
sergioandClaude Opus 4.8 855ff932c4 gnome onda 2: libtiff-shared --undefined-version (version-script Windows-only)
libtiff.so falló 'version script assignment LIBTIFF_4.5 to TIFFOpenWExt failed':
el map lista símbolos Windows-only no compilados en musl; lld lo trata como error.
-Wl,--undefined-version lo hace laxo (estándar en cross).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 17:06:49 -04:00
sergioandClaude Opus 4.8 9696c4873b gnome onda 2: libtiff-shared + libjpeg-turbo-shared para gtk4
gtk4 EXIGE libtiff-4 (meson.build:450, sin required:false) ⇒ removerlo no sirve
(quiere bajar un wrap). Autoro libtiff-shared (dynamic, NEEDED libz.so/libjpeg.so)
+ copio libjpeg-turbo-shared de KDE. gtk4 los declara ⇒ sus loaders linkean las
.so y la cadena zlib resuelve por NEEDED.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 17:03:38 -04:00
sergioandClaude Opus 4.8 6b3b6e1489 gnome onda 2: gtk4 sin libtiff/libjpeg (loaders no-esenciales, romapían el link)
gtk4 compiló pero el link murió 'undefined inflate' de libtiff.a (necesita zlib,
no resuelto sin --prefer-static). Los loaders tiff/jpeg propios de gtk4 no los
usa gnome-shell (png/gdk-pixbuf alcanzan). Removidos ⇒ gtk4 los saltea.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:59:14 -04:00
sergioandClaude Opus 4.8 80465d1689 gnome onda 2: gtk4 al cierre C dinámico (-shared) + gi-foreign-girs
pango SELLÓ (5/6 onda2). gtk4 = el último y más grande: mismo patrón -shared
(cairo/fontconfig/freetype/libpng/zlib) + gi-foreign-girs (cairo-1.0.gir).
pango/gdk-pixbuf/graphene/harfbuzz resuelven a las islas. wayland/mesa/libdrm/
libepoxy/libjpeg/libtiff quedan corpus (worker revela si necesitan -shared por PIC).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:55:10 -04:00
sergioandClaude Opus 4.8 a537f9857a gnome onda 2: gi-foreign-girs genera cairo-1.0.gir del .in
cairo-1.0.gir NO está en gir/ como .gir sino como cairo-1.0.gir.in (g-i lo genera
con configure_file). Reproduzco la sustitución @CAIRO_GIR_PACKAGE@=cairo-gobject
y @CAIRO_SHARED_LIBRARY@=libcairo-gobject.so.2 con sed. Desbloquea pango (PangoCairo
referencia cairo-1.0). Es el gir foráneo que hizo SIGSEGV al keystone original.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:49:51 -04:00
sergioandClaude Opus 4.8 f07665d553 gnome onda 2: gi-foreign-girs instala los .gir foráneos (freetype2/cairo/…)
harfbuzz falló 'Couldn't find freetype2-2.0.gir'; nuestro g-i minimal
(build_introspection_data=false) NO instala ningún .gir, ni los foráneos
hand-written. Nuevo recipe gi-foreign-girs copia gir/*.gir del source de g-i a
/usr/share/gir-1.0 (sólo XML, sin compilar ⇒ SIN cascada de re-hash de g-i).
harfbuzz→freetype2-2.0, pango→cairo-1.0 lo declaran. (pango tuvo tmb la carrera
ADR 0012 'Directory not empty', reintenta sola.)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:14:03 -04:00
sergioandClaude Opus 4.8 8d0dae6390 gnome onda 2: harfbuzz isla con introspección (HarfBuzz-0.0.gir p/ pango)
gdk-pixbuf SELLÓ. pango compiló sus .so pero su g-ir-scanner pide HarfBuzz-0.0.gir
(Pango-1.0 referencia tipos hb): el harfbuzz corpus tiene introspection/gobject
disabled. Autoro harfbuzz isla (shadow, dynamic, default_library=both,
gobject+introspection enabled) ⇒ produce HarfBuzz-0.0.gir + libharfbuzz.so.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:09:16 -04:00
sergioandClaude Opus 4.8 62cad30978 gnome onda 2: pango/gdk-pixbuf usan el cierre C dinámico (-shared)
gjs SELLÓ (898b424f) con el cierre -shared; aplico el mismo a pango/gdk-pixbuf:
- pango: cairo-shared/freetype-shared/fontconfig-shared/libpng-shared/zlib-shared
  ⇒ el test cairo-ft deja de fallar 'FontConfig support' (era el cierre estático
  no resuelto, no fontconfig faltante).
- gdk-pixbuf: libpng-shared/zlib-shared ⇒ no 'undefined inflate'.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 16:04:02 -04:00
sergioandClaude Opus 4.8 09e2bd6129 gnome onda 2: gjs -Dreadline=disabled (libreadline.a no es PIC)
Último muro del link: libgjs.so (dinámica, exige PIC) arrastra libreadline.a, que
es --enable-static sin --with-pic ⇒ R_X86_64_PC32 contra rl_prompt. (libffi.a pasó:
es PIC, la glib-isla lo probó.) readline = sólo la consola JS interactiva, que
gnome-shell no usa. Desactivado. Vuelve con una variante readline-shared/PIC.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:20:07 -04:00
sergioandClaude Opus 4.8 5ecefdb4b4 gnome onda 2: gjs sed-ea el subproyecto de tests (pide cairo-1.0.gir)
gjs compiló libgjs y GjsPrivate typelib, pero muere en el subproyecto INCONDICIONAL
gobject-introspection-tests (Regress/WarnLib, cairo=true): su g-ir-scanner pide
cairo-1.0.gir, que nuestro g-i (cairo=disabled) no instala. Son fixtures de test;
los removemos (subproject + subdirs installed-tests/test). gi_tests no se usa fuera.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:16:12 -04:00
sergioandClaude Opus 4.8 33c3fcdc75 gnome onda 2: cairo-shared usa el release estable + sed boilerplate
El archive de GitLab es NO-determinista (cada fetch = otro sha256, imposible de
pinnear). Cambio al release de cairographics.org (hash fijo 445ed820); strippea
boilerplate/ (sólo tests) ⇒ configure sed-ea subdir('boilerplate'). Fuente estable.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:09:50 -04:00
sergioandClaude Opus 4.8 259f9ef901 gnome onda 2: cairo-shared sha256 al valor actual de GitLab (archive no determinista)
El archive de GitLab recomprime al vuelo ⇒ el sha256 6d9281 (que el canónico
registró) ya no coincide; sirve d221d540. El canónico no lo nota (sellado, no
re-fetchea). Deuda: pinnear a un mirror estable. Por ahora, desbloquea.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:06:18 -04:00
sergioandClaude Opus 4.8 5fe6e7e3c9 gnome onda 2: cairo-shared usa la fuente GitLab + cairo-ctime-r.patch
cairo-shared murió 'Nonexistent build file boilerplate/meson.build': el release
de cairographics.org strippea boilerplate/; el canónico usa el archive de GitLab
(git tree completo) + el patch HAVE_CTIME_R. Alineo la fuente al canónico.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 14:03:16 -04:00
sergioandClaude Opus 4.8 5a025fe1e7 gnome onda 2: cierre C dinámico (cairo-shared) desbloquea gjs
El link de gjs moría en cairo estático (undefined XML_GetCurrentLineNumber): el
cairo canónico --prefer-static arrastra fontconfig/freetype/pixman/expat como
cadena estática que un consumidor dinámico no resuelve. Fix = cairo DINÁMICO:
- cairo-shared (nuevo): libcairo.so.2 default_library=both, deps al cierre -shared.
- copio zlib/libpng/freetype/fontconfig -shared de incoming-kde (sufijo NO sombrea
  el corpus ⇒ NO re-hashea la glib-isla). pixman canónico ya es dinámico.
- gjs usa el cierre -shared: linkea libcairo.so, la cadena resuelve por NEEDED.

Mismo cierre desbloqueará pango/gtk4 (próximo). Confirma la revelación del
comentario de pixman.toml: el muro 'cairo-ft FontConfig' era el cierre estático
no resuelto, no fontconfig faltante.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:59:09 -04:00
sergioandClaude Opus 4.8 5e4dd7ab9d gnome onda 2: gjs inyecta el cierre estático de cairo via cpp_link_args
cairo es dep obligatoria (sin -Dcairo). El link de gjs sólo pone -lcairo, no la
cadena transitiva estática (fontconfig->expat, freetype->png/z, pixman) =>
undefined XML_GetCurrentLineNumber. Inyecto -lfontconfig,-lfreetype,-lpixman-1,
-lpng16,-lexpat,-lz (todas no-GObject: sin doble-estado, a diferencia de
--prefer-static con glib). Se limpia cuando cairo sea isla dinamica (#7).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:51:53 -04:00
sergioandClaude Opus 4.8 a425a55ab9 gnome onda 2: gjs -Dcairo=disabled para sellar el hito (cairo vuelve con el cierre C)
Muro de link 'undefined symbol: XML_GetCurrentLineNumber' (expat): gjs dinámico
linkea cairo.a→fontconfig.a→expat pero meson no arrastra la cadena estática
transitiva. Es la deuda del cierre C (#7). Desactivo cairo para sellar YA el
hito (motor JS + typelib GjsPrivate bajo musl); los bindings cairo vuelven cuando
cairo sea isla dinámica.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:47:47 -04:00
sergioandClaude Opus 4.8 4c4a8d570a gnome onda 2: gjs declara py3-setuptools (distutils de g-ir-scanner)
gjs pasó meson setup + compile y murió generando GjsPrivate typelib con
'No module named distutils' — el mismo muro que graphene. py3-setuptools da el
shim. Olvidado en gjs (lo puse en las 4 islas GUI pero no acá).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:44:12 -04:00
sergioandClaude Opus 4.8 9f73ea09cf gnome onda 2: gjs declara ncurses (backend curses de readline)
gjs llegó lejos (glib/gobject/gio/cairo/mozjs-128 todos YES) y murió en el link
de readline: ncursesw/ncurses/termcap NO encontrados. ncurses ya sellado (widec).
Lo declaro ⇒ libncursesw.a hidratada, mantiene la consola JS interactiva.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:41:27 -04:00
sergioandClaude Opus 4.8 625b704331 gnome onda 2: gjs declara nspr (mozjs-128.pc lo requiere)
Avanzó tras el cierre .pc de glib; nuevo muro: mozjs-128.pc Requires nspr, no
declarado. nspr ya sellado en el volumen. Patrón .pc→deps.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:37:42 -04:00
sergioandClaude Opus 4.8 26bb33c31b gnome onda 2: gjs declara el cierre .pc de glib+cairo (pcre2/zlib/freetype/...)
meson setup abortaba 'libpcre2-8 required by glib-2.0 not found': glib-2.0.pc y
cairo.pc traen Requires.private que hammer no hidrata transitivamente. Agrego
pcre2/zlib (glib) + freetype/fontconfig/pixman/libpng/expat (cairo). Patrón .pc→deps.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:34:56 -04:00
sergioandClaude Opus 4.8 293e996ebf gnome onda 2: gjs -Dbsymbolic_functions=false (zig/lld no soporta -Bsymbolic-functions)
gjs pasó spidermonkey (sembrado, cache-hit) y murió en meson.build:89:
'-Bsymbolic-functions not supported'. El linker zig/lld no lo soporta.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 13:31:30 -04:00
sergioandClaude Opus 4.8 c2ea7cd884 gnome onda 2: py3-setuptools en las 4 islas GUI (fix distutils de g-ir-scanner)
Primer ciclo del worker: los 5 targets fallaron, 3 muros distintos:
- graphene: compiló+linkeó .so/.a, murió SÓLO en g-ir-scanner con
  'ModuleNotFoundError: distutils' (Python 3.12 lo removió). Faltaba declarar
  py3-setuptools (el shim de setuptools), como ya hacían los keystones. FIX aquí.
- pango/gtk4: fallan en meson setup 'cairo-ft does not have required FontConfig
  support' — la DEUDA DE ALCANCE cobrándose: sin --prefer-static, pkg-config no
  resuelve las deps estáticas transitivas de cairo. --prefer-static NO sirve
  (embebería glib en pango.so → doble GType → SIGSEGV del keystone). Fix real =
  escalar el cierre C (cairo/fontconfig/freetype/harfbuzz) a islas dinámicas.
  PENDIENTE (pase grande). py3-setuptools agregado igual (lo necesitarán luego).
- spidermonkey: 'No module named _ctypes' (python3 del rootfs worker sin _ctypes,
  skew). No se reconstruye: se SIEMBRA la sellada del laptop (1.3G) ⇒ gjs cache-hit.

Este ciclo esperado: graphene sella + gjs sella (spidermonkey sembrado).
pango/gdk-pixbuf/gtk4 esperan el cierre C dinámico.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 12:29:37 -04:00
sergioandClaude Opus 4.8 328c7219aa gnome onda 2: cola driver aislada incoming-gnome-onda2
Cola de build para el worker (patrón onda1): SÓLO los 5 targets listos
(gjs/graphene/pango/gdk-pixbuf/gtk4) + su cierre de deps que vive en
incoming-gnome/ (islas glib/glib-introspected/g-i/py3-setuptools + la cadena
spidermonkey/nspr/nasm/cbindgen). Todas las deps ya selladas ⇒ cache-hit; el
worker sólo mide los 5. Excluye mutter/gnome-shell/gdm (deps no listas) para
no quemar compute en builds condenados. Byte-idénticas al corpus/incoming-gnome
⇒ hashes idénticos (resolver sibling→parent auto-consistente).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-27 11:04:05 -04:00