takana

2,309 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
SergioandClaude Opus 5	3379a1f170	licencias: las 26 que faltaban, y el guardián que las contaba mal CAMPAÑA CERRADA: 1166/1166 recetas declaran `license`. Ninguna adivinada — cada una sale del fichero de licencia de su fuente PINEADA (tarball del sha256 de la receta, o el commit exacto en la forja), y la cita queda como comentario en la propia receta. ⚠ Y EL GUARDIÁN ESTABA MAL, que es el hallazgo que vale más que las 26. `licencias-rootfs.sh` resolvía la receta por NOMBRE DE FICHERO (`ls recipes/$pkg.toml`), y el paquete se llama por su campo `name`, que en 34 recetas NO coincide: nu.toml→`nushell`, dust.toml→`du-dust`, incoming-kde/qtbase.toml→`qt6-qtbase`… Medido: 14 paquetes que SÍ declaran licencia salían como «licencia desconocida» y el guardián vetaba una imagen perfectamente publicable. El falso veto se nota; el hermano silencioso NO: si existe un `<pkg>.toml` que pertenece a OTRO paquete, la versión vieja reportaba la licencia EQUIVOCADA sin decir nada. Hoy no pasa —medido, 0 casos, y de los 34 nombres duplicados CERO declaran licencias distintas—, pero ahora es imposible en vez de improbable. El arreglo tuvo que ser por LOS DOS lados, y el primer intento rompió el otro: el grafo de estado nombra sus nodos por el fichero (`dust`) y el artefacto del store por `name` (`du-dust`), así que resolver sólo por `name` dejaba a `dust` sin licencia. Ahora busca por `name` y cae al fichero. Medido en los dos sentidos: corpus entero 1128/1128, perfil base+cli 81/81, cero sin licencia. Y probado CON ROTURA A PROPÓSITO además del control, que es lo único que distingue a un guardián que sirve de uno que nunca salta: paquete inexistente en la lista → exit 1 y «ESTA IMAGEN NO SE PUEDE PUBLICAR» control (zlib nushell qt6-qtbase lsof tzdata) → exit 0, y escribe los textos (⚠ ojo al medir: `script \| tail` devuelve el exit de `tail`. La primera corrida dijo exit=0 sobre la rotura y no era el guardián, era el pipe.) SE LEVANTA EL VETO QUE SDD 20 DEJÓ ESCRITO. Decía que `base` y `cli` iban con 2 paquetes cada una con binarios y licencia desconocida: `lsof` y `tzdata`, «que necesitan la vía LicenseRef- y siguen vetando a propósito». Hechos los dos, con su texto real en licenses/: lsof → LicenseRef-lsof (licencia propia de Purdue, sin identificador SPDX) tzdata → LicenseRef-tz-public-domain (su LICENSE: «all files in the tz code and data … are in the public domain»; los tres ficheros BSD-3-Clause que menciona NO se instalan — la receta sólo compila zic y deja /usr/share/zoneinfo) ⚠ DOS QUE NO SE PUEDEN REDISTRIBUIR, y ahora el veto los ve: duplicacy NO ES LIBRE. Su LICENSE.md: «Free for personal use or commercial trial; non-trial commercial use requires per-computer CLI licenses … $50 per year» waybackurls NO DECLARA LICENCIA: en el commit pineado la raíz es .gitignore, README.mkd, go.mod, main.go y script/ — sin LICENSE ni COPYING, y el README no la menciona. Sin concesión expresa, el defecto es «todos los derechos reservados» Los dos con LicenseRef y un texto en licenses/ que explica qué hay, en vez de dejar el campo vacío, que se lee como «todavía no lo poblamos». Ninguno está hoy en un perfil de imagen; si alguien los mete, el guardián corta. De paso queda escrito el texto de `LicenseRef-qorpa-ajena-no-enumerable`, que ya se usaba en steam-runtime-sniper y no tenía fichero; y `licencias-textos.sh` bajó los canónicos nuevos (BSL-1.0 para boost, GCC-exception-3.1 que ya hacía falta). Hueco conocido y anotado en la receta: `XFree86-1.0` (rama del OR de hwdata) se queda sin texto — SPDX no publica ese identificador, sólo XFree86-1.1, que es otra licencia, y el tarball lo nombra sin incluirlo. El guardián avisa y no veta, que es correcto: la otra rama del OR es la GPL y su texto sí está. NADA SE RE-HASHEA: `license` está fuera de `hash_inputs`. Verificado, no supuesto — `hammer hash` sobre pigz, lsof y boost después de editarlas devuelve el hash cuyo artefacto YA está en el store. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV	2026-09-09 17:47:16 +00:00
sergioandClaude Opus 5	417ba2a502	gnome: 🏔 LA SESIÓN ARRANCA Y SE QUEDA VIVA — cae el último muro de la capa JS == gnome-qemu :: compositor OK (wayland-0) — el shell ES el display server == gnome-qemu :: STATUS +15s … +315s: gnome-shell=2 Sin una sola `JS ERROR`. gnome-shell corre 5 minutos seguidos sobre DRM real. Dos cierres, los dos por auditar en vez de adivinar: 1. GL-1.0 y libxml2-2.0 sumados a gi-foreign-typelibs. La primera auditoría de `<include>` la hice sólo sobre los girs de /usr/share/gir-1.0 y me faltaron los que entran por los girs PRIVADOS de mutter (Clutter-16, Cogl-16 → GL-1.0, o sea que sin él no carga `Meta`: el compositor entero) y por los de eds (Camel, EBook, EDataServer → libxml2-2.0). Un ciclo de imagen+arranque perdido por auditar de menos. La forma correcta —y ahora escrita en la receta— es cruzar los `<include>` de TODOS los .gir del rootfs hidratado contra los typelibs presentes. Queda un solo huérfano, `xlib-2.0`, que sólo incluye `xft-2.0`, a quien no incluye nadie: no es una falta. 2. libgdm vuelve a construir su `data/`. La había borrado entera por parecer «cosas del greeter», y ahí vive el gschema org.gnome.login-screen, que gnome-shell lee al arrancar: sin él muere con `Gio.IOErrorEnum: GSettings schema ... not found`. Un esquema de GSettings no es un fichero de datos del demonio — es una interfaz publicada que consume otro programa. Se borra sólo `subdir('dconf')`, la única pieza que necesita el binario `dconf`. Lo que queda son avisos, no muros: falta un tema de cursor, colord no arranca por el setuid del helper, y `org.gnome.settings-daemon.peripherals.touchscreen` no existe porque g-s-d está aparcada (rompe quick-settings, no la sesión). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 15:16:03 -04:00
sergioandClaude Opus 5	fd9f9dff6d	gnome: libgdm (b3:46fac484) + cairo-1.0.typelib — la capa JS avanza dos muros más Dos rondas del mismo patrón, las dos destapadas ARRANCANDO: 1. `Requiring Gdk 4.0: Typelib 'cairo' 1.0 not found` ⇒ cairo-1.0 sumado a gi-foreign-typelibs. Necesita el mismo sed que gi-foreign-girs (viene como .gir.in con dos placeholders), para compilar EXACTAMENTE el XML que está instalado: si divergieran, el typelib describiría otra librería. NO segfaultea g-ir-compiler — el crash que motivó -Dbuild_introspection_data=false era del g-i de antes de la isla dinámica. La lista de cinco no se adivinó: sale de leer los <include> de TODOS los .gir del cierre y cruzarlos contra los typelibs existentes. 2. `Requiring Gdm 1.0` ⇒ receta `libgdm`, SÓLO la librería cliente. gnome-shell la importa sin condicional (js/misc/dependencies.js:12), o sea que la librería cliente de GDM es dep de runtime del SHELL, no del greeter — y eso no se ve en ningún meson.build. `gdm.toml` (el demonio entero) sigue aparcada por linux-pam, pero PAM es del DEMONIO: libgdm/ no lo toca. La receta corta por ahí; cuando exista linux-pam las dos conviven. Para que libgdm compilara hicieron falta tres símbolos más en libelogind (tawasuyu 9bf977a52, re-pineado a 98db584fd, re-sellado b3:c1fc4bd8): sd_seat_get_sessions, sd_session_get_service y sd_booted, éste en una cabecera nueva systemd/sd-daemon.h. sd_booted NO es un stub que devuelve 0: comprueba lo mismo que systemd —que exista /run/systemd/system/— y bajo arje no está, así que responde 0 porque ES 0. gnome-shell re-sellado b3:b2d5919b por la cascada. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:50:14 -04:00

Author

SHA1

Message

Date

SergioandClaude Opus 5

3379a1f170

licencias: las 26 que faltaban, y el guardián que las contaba mal

CAMPAÑA CERRADA: 1166/1166 recetas declaran `license`. Ninguna adivinada — cada una sale del
fichero de licencia de su fuente PINEADA (tarball del sha256 de la receta, o el commit exacto en
la forja), y la cita queda como comentario en la propia receta.

⚠ Y EL GUARDIÁN ESTABA MAL, que es el hallazgo que vale más que las 26. `licencias-rootfs.sh`
resolvía la receta por NOMBRE DE FICHERO (`ls recipes/$pkg.toml`), y el paquete se llama por su
campo `name`, que en 34 recetas NO coincide: nu.toml→`nushell`, dust.toml→`du-dust`,
incoming-kde/qtbase.toml→`qt6-qtbase`… Medido: **14 paquetes que SÍ declaran licencia salían como
«licencia desconocida»** y el guardián vetaba una imagen perfectamente publicable.
El falso veto se nota; el hermano silencioso NO: si existe un `<pkg>.toml` que pertenece a OTRO
paquete, la versión vieja reportaba la licencia EQUIVOCADA sin decir nada. Hoy no pasa —medido,
0 casos, y de los 34 nombres duplicados CERO declaran licencias distintas—, pero ahora es
imposible en vez de improbable.

El arreglo tuvo que ser por LOS DOS lados, y el primer intento rompió el otro: el grafo de estado
nombra sus nodos por el fichero (`dust`) y el artefacto del store por `name` (`du-dust`), así que
resolver sólo por `name` dejaba a `dust` sin licencia. Ahora busca por `name` y cae al fichero.
Medido en los dos sentidos: corpus entero 1128/1128, perfil base+cli 81/81, cero sin licencia.

Y probado CON ROTURA A PROPÓSITO además del control, que es lo único que distingue a un guardián
que sirve de uno que nunca salta:
  paquete inexistente en la lista               → exit 1 y «ESTA IMAGEN NO SE PUEDE PUBLICAR»
  control (zlib nushell qt6-qtbase lsof tzdata) → exit 0, y escribe los textos
(⚠ ojo al medir: `script | tail` devuelve el exit de `tail`. La primera corrida dijo exit=0 sobre
la rotura y no era el guardián, era el pipe.)

SE LEVANTA EL VETO QUE SDD 20 DEJÓ ESCRITO. Decía que `base` y `cli` iban con 2 paquetes cada una
con binarios y licencia desconocida: `lsof` y `tzdata`, «que necesitan la vía LicenseRef- y siguen
vetando a propósito». Hechos los dos, con su texto real en licenses/:
  lsof    → LicenseRef-lsof (licencia propia de Purdue, sin identificador SPDX)
  tzdata  → LicenseRef-tz-public-domain (su LICENSE: «all files in the tz code and data … are in
            the public domain»; los tres ficheros BSD-3-Clause que menciona NO se instalan — la
            receta sólo compila zic y deja /usr/share/zoneinfo)

⚠ DOS QUE NO SE PUEDEN REDISTRIBUIR, y ahora el veto los ve:
  duplicacy    NO ES LIBRE. Su LICENSE.md: «Free for personal use or commercial trial; non-trial
               commercial use requires per-computer CLI licenses … $50 per year»
  waybackurls  NO DECLARA LICENCIA: en el commit pineado la raíz es .gitignore, README.mkd,
               go.mod, main.go y script/ — sin LICENSE ni COPYING, y el README no la menciona. Sin
               concesión expresa, el defecto es «todos los derechos reservados»
Los dos con LicenseRef y un texto en licenses/ que explica qué hay, en vez de dejar el campo vacío,
que se lee como «todavía no lo poblamos». Ninguno está hoy en un perfil de imagen; si alguien los
mete, el guardián corta.

De paso queda escrito el texto de `LicenseRef-qorpa-ajena-no-enumerable`, que ya se usaba en
steam-runtime-sniper y no tenía fichero; y `licencias-textos.sh` bajó los canónicos nuevos
(BSL-1.0 para boost, GCC-exception-3.1 que ya hacía falta).

Hueco conocido y anotado en la receta: `XFree86-1.0` (rama del OR de hwdata) se queda sin texto —
SPDX no publica ese identificador, sólo XFree86-1.1, que es otra licencia, y el tarball lo nombra
sin incluirlo. El guardián avisa y no veta, que es correcto: la otra rama del OR es la GPL y su
texto sí está.

NADA SE RE-HASHEA: `license` está fuera de `hash_inputs`. Verificado, no supuesto — `hammer hash`
sobre pigz, lsof y boost después de editarlas devuelve el hash cuyo artefacto YA está en el store.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV

2026-09-09 17:47:16 +00:00

sergioandClaude Opus 5

417ba2a502

gnome: 🏔 LA SESIÓN ARRANCA Y SE QUEDA VIVA — cae el último muro de la capa JS

== gnome-qemu :: compositor OK (wayland-0) — el shell ES el display server
  == gnome-qemu :: STATUS +15s … +315s: gnome-shell=2

Sin una sola `JS ERROR`. gnome-shell corre 5 minutos seguidos sobre DRM real.

Dos cierres, los dos por auditar en vez de adivinar:

1. GL-1.0 y libxml2-2.0 sumados a gi-foreign-typelibs. La primera auditoría de
   `<include>` la hice sólo sobre los girs de /usr/share/gir-1.0 y me faltaron los que
   entran por los girs PRIVADOS de mutter (Clutter-16, Cogl-16 → GL-1.0, o sea que sin
   él no carga `Meta`: el compositor entero) y por los de eds (Camel, EBook,
   EDataServer → libxml2-2.0). Un ciclo de imagen+arranque perdido por auditar de menos.
   La forma correcta —y ahora escrita en la receta— es cruzar los `<include>` de TODOS
   los .gir del rootfs hidratado contra los typelibs presentes. Queda un solo huérfano,
   `xlib-2.0`, que sólo incluye `xft-2.0`, a quien no incluye nadie: no es una falta.

2. libgdm vuelve a construir su `data/`. La había borrado entera por parecer «cosas del
   greeter», y ahí vive el gschema **org.gnome.login-screen**, que gnome-shell lee al
   arrancar: sin él muere con `Gio.IOErrorEnum: GSettings schema ... not found`. Un
   esquema de GSettings no es un fichero de datos del demonio — es una interfaz publicada
   que consume otro programa. Se borra sólo `subdir('dconf')`, la única pieza que necesita
   el binario `dconf`.

Lo que queda son avisos, no muros: falta un tema de cursor, colord no arranca por el
setuid del helper, y `org.gnome.settings-daemon.peripherals.touchscreen` no existe
porque g-s-d está aparcada (rompe quick-settings, no la sesión).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-07-29 15:16:03 -04:00

sergioandClaude Opus 5

fd9f9dff6d

gnome: libgdm (b3:46fac484) + cairo-1.0.typelib — la capa JS avanza dos muros más

Dos rondas del mismo patrón, las dos destapadas ARRANCANDO:

1. `Requiring Gdk 4.0: Typelib 'cairo' 1.0 not found` ⇒ cairo-1.0 sumado a
   gi-foreign-typelibs. Necesita el mismo sed que gi-foreign-girs (viene como .gir.in
   con dos placeholders), para compilar EXACTAMENTE el XML que está instalado: si
   divergieran, el typelib describiría otra librería. NO segfaultea g-ir-compiler — el
   crash que motivó -Dbuild_introspection_data=false era del g-i de antes de la isla
   dinámica. La lista de cinco no se adivinó: sale de leer los <include> de TODOS los
   .gir del cierre y cruzarlos contra los typelibs existentes.

2. `Requiring Gdm 1.0` ⇒ receta `libgdm`, SÓLO la librería cliente. gnome-shell la
   importa sin condicional (js/misc/dependencies.js:12), o sea que **la librería
   cliente de GDM es dep de runtime del SHELL, no del greeter** — y eso no se ve en
   ningún meson.build. `gdm.toml` (el demonio entero) sigue aparcada por linux-pam,
   pero PAM es del DEMONIO: libgdm/ no lo toca. La receta corta por ahí; cuando exista
   linux-pam las dos conviven.

Para que libgdm compilara hicieron falta tres símbolos más en libelogind
(tawasuyu 9bf977a52, re-pineado a 98db584fd, re-sellado b3:c1fc4bd8):
sd_seat_get_sessions, sd_session_get_service y **sd_booted**, éste en una cabecera
nueva systemd/sd-daemon.h. sd_booted NO es un stub que devuelve 0: comprueba lo mismo
que systemd —que exista /run/systemd/system/— y bajo arje no está, así que responde 0
porque ES 0.

gnome-shell re-sellado b3:b2d5919b por la cascada.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-07-29 12:50:14 -04:00