Commit Graph
6 Commits
Author SHA1 Message Date
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 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 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