3379a1f1709f6dab9d012cbbb46d7e6ace20db45
57
Commits
| 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
|
||
|
SergioandClaude Opus 5
|
ca2c164512 |
sombras: CERO — promover las 6 compartidas al corpus y barrer sus 16 copias
Las 6 que quedaban (fuse3, hwdata, icu4c, libdisplay-info, libelogind, lua) no tenían copia en el corpus, así que borrar una habría roto su cola: la resolución es sibling-first y después el catálogo PADRE, nunca una cola hermana. Se promueve una y se barren las 16. Las 16 eran byte a byte IDÉNTICAS entre sí, con el mismo ArtifactHash — medido con 'hammer hash', no deducido del nombre. Cada una la comparten entre 2 y 4 imágenes, que es exactamente el criterio que dejó escrito xkeyboard-config al promoverse: lo que comparten varias imágenes tiene que vivir en el corpus o no lo alcanzan. A diferencia de aquella, acá las copias SÍ se barren en el mismo movimiento: sin copia en el corpus no había dónde caer, y dejarlas sería mantener hasta 4 ficheros que son el mismo hash. Verificado con la huella de las 1167 recetas antes y después: ficheros de receta 1167 → 1157 (16 borradas, 6 promovidas) hashes supervivientes ninguno se movió ⇒ CERO rebuilds los cinco grafos deuda 0, huérfanas [], sellados == recetas static-audit MIENTEN 0 de 690 duplicados SOMBRAS REDUNDANTES: 0 ← de 14 ⚠ Y una lectura que casi publico mal: mi primera comparación de hashes dijo 'CAMBIÓ ✗' en las seis. Era el grep de la comparación, que no casaba y dejaba el valor 'antes' vacío — los hashes nuevos eran idénticos a los medidos minutos antes. Un instrumento roto que grita es tan malo como uno mudo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2 |
||
|
SergioandClaude Opus 5
|
a4a462b751 |
sombras: barrer 14 recetas redundantes que ya tenían copia en el corpus
Las 14 sombras marcadas 'redundante' dan el MISMO ArtifactHash en todas sus colas — no son variantes, son el mismo artefacto declarado dos, tres, cuatro y hasta cinco veces. Medido con 'hammer hash' receta por receta, no deducido del nombre. Se barren sólo las que YA tenían copia en el corpus, porque la resolución es sibling-first: una dep desde incoming-kde busca incoming-kde/x y, si no está, CAE al corpus/x. Son 8 nombres, 14 ficheros: bzip2-shared, glib-shared, lcms2, mpc, pcre2-shared, sqlite-shared, xkeyboard-config y xz-shared. 13 de los 14 eran byte a byte idénticos al del corpus. El decimocuarto, xkeyboard-config, difiere en 14 líneas de COMENTARIO (mismo hash), y ese comentario es el permiso explícito para esto: quien la promovió el 2026-09-05 escribió que dejaba las copias a propósito y que 'barrerlas es otra unidad de trabajo, no un efecto colateral de ésta'. Ésta es esa unidad. Verificado con la huella de las 1181 recetas antes y después: NINGÚN hash superviviente se movió ⇒ cero rebuilds. Y tras regenerar los cinco grafos: deuda 0, huérfanas [], y todas las clausuras de perfil siguen completas. ⚠ Nota sobre una lectura que casi me confunde: los conteos de 'recipes' NO bajan (kde sigue en 1034) y eso es lo correcto — cuentan nodos alcanzables, no ficheros. Antes incoming-kde/x tapaba a corpus/x; ahora el del corpus ocupa su lugar. Un nodo por otro. Quedan 6 nombres (fuse3, hwdata, icu4c, libdisplay-info, libelogind, lua) sin copia en el corpus: ésos exigen promover una primero, y van aparte. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QPJteswQvP1L7zSBrQQe2 |
||
|
Sergio
|
ab7cdf25e3 |
licencias: hammerd y portal-probe son MIT — su repo es el propio hammer
Las dos recetas apuntan a `ssh://gitea@git.gioser.net:2345/sergio/hammer.git`, o sea a este mismo árbol, que declara MIT en `Cargo.toml` y trae su `LICENSE`. No hace falta clonar nada para saberlo: la evidencia estaba en el directorio de trabajo. Los dos ArtifactHash, idénticos. |
||
|
Sergio
|
96855001c6 |
licencias: 96% (1124/1164) — --fetch para los tarballs que no estaban en caché
Ocho paquetes más (giflib, pcre2, nghttp2, libogg, libvorbis, speexdsp, libuv, tea) con la misma
regla de evidencia. Su tarball no estaba en `work/tarballs/`, así que el modo `--fetch` lo baja a un
temporal, lo verifica contra el sha256 QUE LA RECETA PINEA —o es el árbol exacto o no se mira— y lo
borra. No se escribe en la caché de hammer a propósito: es suya, y un fichero puesto ahí por otro
camino es una vía de envenenamiento que nadie audita.
Dos correcciones al criterio, las dos porque produjo una afirmación falsa:
· `gmp` salía GPL-3.0-or-later. Su `COPYING` es la GPLv3, pero al lado trae `COPYING.LESSERv3` y
`COPYINGv2` porque la biblioteca es LGPL. La regla anterior —«el `COPYING` a secas gana al
sufijado»— arregla socat, cuyo `COPYING.OpenSSL` es una excepción, y rompe gmp, donde el extra
nombra otra VERSIÓN y no una dep. Esa diferencia es demasiado fina para codificarla sin
equivocarse, así que ahora se identifican TODOS los ficheros de la raíz y sólo hay veredicto si
dicen lo mismo. gmp, ffmpeg y los tres `gi-*` quedan pendientes, que es lo correcto: en ffmpeg
la respuesta ni siquiera está en el árbol, la deciden los flags de la receta.
· Pero «varios ficheros» no es «ambigüedad»: el `COPYING` de pcre2 son dos líneas apuntando a
`LICENCE.md`, y los dos dicen BSD-3. Por eso se unen las identificaciones en vez de contar
ficheros — ambiguo es que digan cosas DISTINTAS.
Y el TSV pasa a ser ACUMULATIVO. Una receta ya sembrada sale del conjunto de entrada porque ya tiene
`license`, así que regenerar el fichero entero borraba su cita — y la cita es el rastro de
auditoría, lo único que deja revisar un veredicto sin repetir el trabajo. Un fichero de evidencia
que se olvida de lo que ya probó no es evidencia.
Los 10 ArtifactHash afectados, idénticos antes y después.
|
||
|
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.
|
||
|
Sergio
|
027d3a25ef |
plataforma Gecko: clang18 sube al corpus — bindgen necesita libclang
El build de Firefox corre bindgen sobre los headers de C++ y bindgen carga libclang.so en RUNTIME. La receta ya existía —nació en incoming-cosmic por un crate *-sys del portal, y su commit de origen dice «sólo libclang.so»— pero desde el corpus no se alcanza una cola hermana. Sin esto no hay Firefox, ni Waterfox, ni Zen. Mudanza medida ANTES, no después: sus cinco deps (cmake, samurai, python3, pkgconf, llvm18) viven sólo en el corpus, así que incoming-cosmic ya las resolvía por caída al padre y el cierre no cambia. hammer hash dio el MISMO ArtifactHash (b3:25d95279) en las dos rutas. Verificado que xdg-desktop-portal-cosmic —su único dependiente— sigue SELLADO y que la cola cosmic queda en 36/36 sin deuda: cero rebuilds. Se MUEVE y no se copia: dos ficheros para un artefacto es el cuadro de las dos glib esperando a que uno de los dos derive. |
||
|
SergioandClaude Opus 5
|
d69c437051 |
escritorios: KDE y GNOME corrían SIN tema de iconos — el panel vacío no era el panel
Medido sobre los artefactos del cierre de cada imagen, contando qué `usr/share/icons/*/`
trae un `index.theme` (que es lo que convierte un directorio en un tema):
escritorio-kde sólo Breeze_Light y breeze_cursors — que son CURSORES
escritorio-gnome CERO, ni siquiera hicolor
escritorio-cosmic Cosmic + hicolor <- el único que estaba bien
escritorio-sway CERO
Las dos capturas de QEMU de hoy ya lo mostraban y se leyeron como «arranca»:
- `plasma6-qemu-2026-09-03-kactivitymanagerd.png`: panel con el reloj y nada más. Los `.so`
de los applets estaban TODOS instalados; lo que faltaba era qué pintar. `kickoff`,
`systemtray`, `showdesktop` y `trash` SON un icono, así que sin tema quedan de ancho cero
— el reloj se ve porque dibuja TEXTO. El log lo decía en una línea:
`kf.iconthemes: Icon theme "breeze" not found.`
- `gnome-shell-qemu-2026-09-03-libs-compartidas.png`: barra superior con la fecha y el pill
de espacios, y la DERECHA vacía — red, volumen y batería son iconos.
`breeze` (ya declarado) es el tema de WIDGETS y CURSORES; los ~14.000 iconos viven en
`breeze-icons`, receta aparte, sellada desde siempre y declarada por NADIE. Igual
`adwaita-icon-theme` en GNOME, que además trae los XCursor (su cabecera dice por qué:
sin tema de cursor no hay puntero visible con el cursor por software de virtio-gpu).
Es la figura de las fuentes y de `foot` otra vez: data de RUNTIME, ninguna arista de BUILD
la alcanza, y la métrica de clausura no la echa de menos porque mide lo declarado.
`hicolor-icon-theme` —el fallback obligatorio de freedesktop— se promueve al corpus para que
lo alcancen las cuatro imágenes: hash IDÉNTICO desde la cola y desde el corpus
(b3:98ad44a5), y sus 4 consumidores (adwaita-icon-theme, cosmic-icons, cosmic-app-library,
cosmic-launcher) miden el mismo hash antes y después ⇒ un solo artefacto, CERO rebuilds.
Cierre tras declararlos, todo sellado y sin deuda:
kde 263/263 (+2) · gnome 158/158 (+2) · sway 173/173 (+1) · cosmic 133/133 (igual)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YGXe6mShYYw6V8ea1dQ13u
|
||
|
SergioandClaude Opus 5
|
cab9439644 |
fuentes: dejavu al corpus (arregla un wanted que dejé), KDE con fuente, y la nerd de monospace
TRES COSAS, y la primera es un bug mío de hace un rato.
1. dejavu-fonts PROMOVIDA AL CORPUS — arregla un nodo `wanted` que introduje.
Al añadirla de raíz a escritorio-gnome quedó como `wanted`: la receta existía en
incoming-{kde,wlr,cosmic} y NO en incoming-gnome ni en el corpus, y una receta no
alcanza una cola hermana. O sea que la raíz no resolvía a nada y GNOME seguía sin
fuentes. `wanted` NO es `debt`, así que drenaje.json seguía diciendo deuda=0 y el
hueco no salía por ninguna métrica — se vio mirando el nodo en build-state-gnome.json.
Promoción gratis: las tres copias sellaban el mismo hash (b3:5b3a5df3) y sus deps
están vacías. Las tres se jubilan. Ahora los cuatro perfiles resuelven a corpus y los
cinco grafos quedan con CERO nodos `wanted`.
2. dejavu-fonts en escritorio-kde, como se pidió. Tenía UNA fuente y de rebote, dentro
de qtbase — apoyarse en un detalle de empaquetado de Qt deja sin nada a todo lo que
no es Qt.
3. dejavu-fonts-nerd 3.5.1 en los CUATRO perfiles: DejaVu Sans Mono parcheada con Nerd
Fonts. Lo que se midió antes de escribirla, porque cambia la forma de hacerla:
- SE AÑADE, NO REEMPLAZA, y no es prudencia: la licencia de Bitstream Vera exige que
una fuente modificada se RENOMBRE. Por eso upstream la llama «DejaVuSansM Nerd Font
Mono» — leído del name de la TTF, no supuesto. Una fuente nerdeada NO puede
responder al nombre de la original; sustituirla rompería a todo lo que pide «DejaVu
Sans Mono», empezando por foot, que ya murió una vez así.
- SÓLO LA MONOESPACIADA: upstream no publica DejaVu Sans ni Serif parcheadas, y en una
fuente de interfaz proporcional esos glifos no los pide nadie. «Todas nerdeadas» no
se puede cumplir al pie de la letra.
- SÓLO UNA DE LAS TRES VARIANTES: NerdFont / NerdFontMono / NerdFontPropo son los
mismos glifos con distinto avance. Las doce pesan 32 MB; las cuatro de Mono, 11 MB.
Se quedan las Mono, que son las correctas para una rejilla de terminal. Referencia:
la familia DejaVu ENTERA son 9,8 MB.
⚠ EL NÚMERO DEL .conf ESTÁ MEDIDO, NO ELEGIDO. fontconfig carga conf.d en orden
alfabético y el <prefer> que llega antes gana. Con 60-nerd-monospace.conf —que ordena
después de 60-latin.conf, que ya prefiere Noto/DejaVu/Inconsolata— `fc-match
monospace` seguía dando DejaVu Sans Mono: la conf estaba INSTALADA Y ERA INERTE, el
mismo modo de fallar que el plugin ALSA de PipeWire. A 59- gana. 45-latin.conf también
menciona monospace pero usa <default>, no <prefer>, así que no compite.
⚠ Y strip_components = 0, que tampoco es cosmético: el tarball de nerd-fonts es PLANO
y con el default de 1 el árbol de fuentes queda VACÍO — el build no se detiene ahí,
sigue y falla más tarde en el cp, con un mensaje que no menciona la extracción.
⚠ LA LICENCIA NECESITA UNA PASADA HUMANA antes de `hammer pack`: el LICENSE.txt del
tarball cubre sólo DejaVu/Bitstream Vera y no menciona los ~10 conjuntos de iconos
importados, que tienen licencias propias (Font Awesome CC-BY-4.0, Octicons MIT,
Material OFL, Powerline MIT…). El campo dice lo DOCUMENTADO, no el conjunto real; no
se inventa una cadena SPDX. Anotado en la receta.
EVIDENCIA, contra el conf.d REAL del artefacto de fontconfig:
monospace -> DejaVuSansM Nerd Font Mono (los iconos llegan)
"DejaVu Sans Mono" -> DejaVu Sans Mono (intacta)
sans-serif -> DejaVu Sans (sin tocar)
serif -> DejaVu Serif (sin tocar)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo
|
||
|
SergioandClaude Opus 5
|
058e3e9206 |
recetas: girara, xxhash y json-glib al corpus — la cadena de zathura, medida
⚠ CORRIGE UNA CREENCIA DEL REPO: zathura NO está bloqueada por GTK3. Upstream VACIÓ girara — en 2026.07.18 su árbol son siete .c (datastructures, input-history, log, template, utils) y su meson.build no menciona GTK ni una vez. Toda la UI se mudó adentro de zathura, que hoy pide GTK4 >= 4.12, y gtk4 4.18.6 está en el corpus. El plan de apps daba a zathura por «verificar si su cadena es GTK4 y no GTK3»: lo es. Las tres piezas que faltaban, medidas con scripts/provee.py --desde corpus: - girara: sella al primer intento; sus tres deps (glib/gobject/gio) salen del mismo artefacto glib. -Ddocs=disabled porque ese target es doxygen y produce HTML de API. - xxhash 0.8.3 (zathura lo usa para la caché de páginas). DISPATCH=0 no es preferencia, el build se cae sin eso: Makefile:58-62 hace `$(CC) -dumpmachine | grep x86_64` y enciende DISPATCH solo por detección de arquitectura — una perilla auto que hace depender el artefacto de dónde se construyó. Con ella, xxh_x86dispatch.c muere porque pide AVX-512 con -mavx512f a secas y el clang de zig ya exige además -mevex512 («AVX vector argument of type __m512i without evex512 enabled changes the ABI»). No se arregla subiendo flags: esa variante sólo la usa el despacho en runtime, que es justo lo que no queremos. Apaga las dos cosas de una. - json-glib PROMOVIDA al corpus, y salió GRATIS por la misma razón que pipewire: la variante de COSMIC resuelve sus deps enteras contra el catálogo padre ⇒ mismo ArtifactHash desde las dos partes (b3:62011e81, medido antes de mover nada). La de GNOME no podía: arrastra gobject-introspection, glib-introspected, gi-foreign-girs y py3-setuptools. La copia de incoming-cosmic se jubila, verificado como manda el repo: su único consumidor (xdg-desktop-portal) hashea b3:749fbffe ANTES y DESPUÉS ⇒ cero rebuilds. La de incoming-gnome SE QUEDA: variante deliberada, artefacto distinto. Falta todavía el backend de PDF, que es el hueco real: incoming-kde/poppler va con -DENABLE_GLIB=OFF ⇒ publica libpoppler.so pero NO poppler-glib, y encima sólo se alcanza desde su cola. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XB2iEmxeLZgzqNfhWChrLo |
||
|
Sergio
|
f04364fc06 |
pipewire al corpus: falta el parche, que quedó fuera del commit ajeno y dejó la receta rota
⚠ INCIDENTE, y queda escrito porque es la regla 2 del CLAUDE.md en vivo: los cuatro `git mv` de esta promoción (pipewire, pulseaudio, libsndfile, dbus-shared) estaban STAGED y sin commitear cuando `89da9c8` («qorpa: el mapeo por rango») se los llevó puestos. El commit ajeno barrió el índice de otro agente — exactamente lo que la regla prohíbe— y encima lo hizo A MEDIAS: se llevó los cuatro `.toml` pero no el `.patch`, porque el `git mv` del parche se cortó cuando el disco se llenó al 100%. Resultado: HEAD quedó con `recipes/pipewire.toml` declarando `patches = ["pipewire-sound- initialized.patch"]` y ese fichero **inexistente en `recipes/`**. Cualquiera que clonara veía `Error: receta inválida: no pude leer patch`. Esto lo repara. El hash confirma que la promoción es gratis: `recipes/pipewire.toml` sella b3:e240653adae656318d5c3445b36ffb37aa491589b5c34c8688515bc3806944ab, EXACTAMENTE el mismo que tenía `incoming-cosmic/pipewire`. Era la variante que ya resolvía todo su cierre contra el catálogo padre. |
||
|
SergioandClaude Opus 5
|
89da9c822f |
qorpa: el mapeo por rango — subuid + --userns FD, y el impuesto se paga
Resuelve §NO-resuelve 2 del ADR 0015, que era el ticket que más desbloqueaba. Tres síntomas que parecían distintos —apt sin poder bajar a `_apt`, pacman sin poder chownear a `alpm`, pressure-vessel sin poder escribir su uid_map— eran la misma causa: bwrap crea el userns con UN SOLO id. La cura resultó tener TRES partes, y ninguna sobra: 1. `setcap cap_setuid+ep newuidmap` (+ cap_setgid en newgidmap). shadow.toml los instala pero no los provisiona; sin la capability no escriben el mapa. 2. Crear el userns nosotros, mapear el rango de /etc/subuid con newuidmap y pasárselo a bwrap con `--userns FD`. bwrap crea el suyo con un solo id A PROPÓSITO y nunca llama a newuidmap: el trabajo es de quien lo invoca. El fd lo abre la shell (`exec 3<…`), porque un fd sólo cruza el exec si no es CLOEXEC y no valía la pena una dep de C para un fcntl. 3. Devolver las capabilities DENTRO del namespace. Ésta no estaba en el plan y es la que costó: bwrap las tira todas, y en Linux ser root es tener CAP_SETUID, no tener uid 0. Sin ella apt seguía sin poder seteuid(42) — un síntoma que parecía de subuid y no lo era. Son seguras por construcción: dentro de un userns sólo alcanzan lo que ese namespace posee, o sea nuestros propios subuid. CAP_SYS_ADMIN queda fuera y sigue colgando de `nesting`. MEDIDO después: uid_map de 65537 ids, setgroups: allow, apt instala SIN el APT::Sandbox::User=root, pacman sincroniza con DownloadUser=alpm INTACTO, y el userns anidado monta con root=true ⇒ el conflicto 2 de D9 se disuelve solo. Dos cosas más que salieron por medir, no por pensar: - El guardián MENTÍA. qorpa-preflight envolvía al hijo en `timeout`, que forkea, así que newuidmap apuntaba al PID equivocado y el kernel respondía "Operation not permitted" — un falso negativo idéntico a un fallo real. Decía que subuid no andaba cuando a mano andaba. Ahora sale exit 0. - Quitar el impuesto MUEVE el problema: el upper pasa a contener ficheros de los subuid (apt deja los suyos con uid 165577) que nuestro uid no puede borrar ⇒ recreate entra a un userns mapeado para limpiar. Y cuando no hay rango, se degrada diciendo la causa exacta en vez de quedar en misterio. Y un detalle que no es cosmético: `--perms 1777` antes del `--tmpfs /tmp`, o el _apt al que apt baja no puede escribir su fichero temporal. Un /tmp que no es 1777 no es /tmp. 2 tests nuevos (el rango se lee por usuario; CAP_SYS_ADMIN NO está en las caps de root, o `nesting` dejaría de ser una decisión). 45/45. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01U5cQtQrYNjWJVXVE6aEpQ2 |
||
|
Sergio
|
f19b8b3e4a |
jubilar 13 copias de cola que sellan IDÉNTICO al corpus — y de paso el grafo deja de mentir
Continúa lo que ya se hizo el 2026-09-02 con las 8 copias de gnome. Medido receta por receta con `hammer hash`: de los 30 nombres que viven en el corpus Y en alguna cola, 13 dan el MISMO ArtifactHash que su gemela del corpus y 22 son variantes deliberadas (glib/gtk4/pango de gnome, dbus/openssl/libxml2 de kde…) que NO se tocan. Se van las 13 redundantes: alsa-lib ×3, nasm ×2, zlib-shared ×2, y de incoming-kde ffmpeg, fontconfig-shared, freetype-shared, libjpeg-turbo-shared, libpng-shared y vulkan-headers. Cada consumidor las resuelve ahora en el catálogo PADRE, con el mismo hash. VERIFICADO ANTES Y DESPUÉS, no argumentado: se snapshotearon los 47 consumidores directos, se borraron las 13, y se re-hashearon. **0 consumidores vivos con hash distinto** (las 4 diferencias son las propias recetas borradas, que se consumían entre sí). Cero rebuild. EL EFECTO QUE NO SE BUSCABA Y ES EL MÁS VALIOSO: `build-state.json` guarda sus nodos POR NOMBRE, y cuando un nombre vive en dos colas la membresía se consulta por el par `(cola, nombre)` de UNA sola de ellas. Resultado: `ffmpeg`, `alsa-lib`, `vulkan-headers` y `zlib-shared` reportaban `perfiles: []` —o sea "no está en ninguna imagen"— **mientras estaban en las cuatro**. Ahora dicen la verdad, y `escritorio-kde` pasa de 183 a 185 porque aparecen dos nodos que el grafo no contaba. La lección para el próximo análisis, que ya quedó en `scripts/vigia-sonames.py`: sobre el grafo se pregunta con `yupana.membresia()`, que llavea por `(cola,nombre)`; el campo `perfiles` del JSON es fiable sólo mientras el nombre viva en una sola cola. Sin cambios en la deuda: cosmic sigue 105/106 por el OOM de xdg-desktop-portal-cosmic. |
||
|
Sergio
|
5e6b3631e2 |
pipewire ×3: ALSA pasa a ser la ABI de audio de la distro — el flag no alcanzaba
Las tres recetas pasan a `-Dpipewire-alsa=enabled`. Sirve a TODA app ALSA del corpus, no sólo a mpv:
un cliente que abre "default" desemboca en PipeWire por `libasound_module_pcm_pipewire.so` en vez de
pelearle la tarjeta al servidor. Es protocolo en vez de ABI compartida — la misma figura con la que
el ADR 0015 cruza el borde de la jaula.
EL FLAG SOLO NO HACE NADA, y ésta es la parte que no se ve venir: meson deja los plugins en
`/usr/lib/alsa-lib` (bien, ahí los busca alsa-lib) pero la CONFIGURACIÓN en
`/usr/share/alsa/alsa.conf.d`, **un directorio que alsa-lib no lee**. Sus `@hooks` cargan
`/var/lib/alsa/conf.d`, `/usr/etc/alsa/conf.d` y `/etc/alsa/conf.d` — leído del `alsa.conf` del
artefacto sellado, no supuesto. Sin el enlace que agrega la fase install, el plugin queda instalado
y no lo usa nadie: sellado e inerte, que es la familia de fallo del artefacto vacío. Se enlazan los
DOS ficheros: `50-pipewire.conf` hace que el destino EXISTA, `99-pipewire-default.conf` hace que sea
el destino POR DEFECTO — sin el segundo, mpv abriendo "default" no llega igual.
EVIDENCIA (test discriminante, porque "no falla" no prueba nada acá):
mpv --audio-device=alsa/pipewire → abre el device, falla al conectar (no hay demonio) ⇒ el PCM
ESTÁ DEFINIDO
mpv --audio-device=alsa/noexiste → "ALSA lib: Unknown PCM noexiste" ⇒ el control
El camino de verdad —que suene— sólo se puede ejercer con un PipeWire vivo, o sea en la sesión; eso
no se probó y no se afirma.
⚠ PRECIO, escrito para que no se diagnostique mal: con `99-pipewire-default.conf` puesto,
`pcm.!default` ES PipeWire. En una máquina donde PipeWire no esté corriendo, un cliente ALSA ya no
cae a la tarjeta: no suena. Es el trato que hace toda distro con pipewire-alsa.
Radio medido antes de tocar (`yupana radio pipewire`): 4 cosmic / 3 gnome / 2 kde. Reconstruidos 10
de 11 dependientes.
⚠ DEUDA DECLARADA, 1: `incoming-cosmic/xdg-desktop-portal-cosmic` murió DOS VECES por OOM (7 G de
RAM, sin cgroups, y otro agente compilando Rust a la vez — `dmesg` confirma «Out of memory: Killed
process (cargo)»). No es un fallo de la receta ni del cambio: es la máquina. Queda visible en el
grafo (escritorio-cosmic 105/106) en vez de escondido, y lo levanta el worker o un reintento con la
máquina libre.
Los otros tres perfiles cierran: KDE 183/183, GNOME 132/132, sway 140/140.
|
||
|
SergioandClaude Opus 5
|
42db2dfb35 |
gmp: las dos recetas son variantes DELIBERADAS, no un duplicado — queda escrito
Yo mismo las reporte como "la misma clase de colision que onda1" y me pase: no
lo son. onda1 tenia una copia RANCIA del mismo build; esto son dos builds
distintos, cada uno correcto para su frente:
KDE link=dynamic --enable-shared --enable-cxx => libgmp.so + libgmpxx.so
COSMIC link=static --disable-shared => libgmp.a, sin C++
Las dos citan libqalculate y llegan a conclusiones opuestas sobre gmpxx.h, y las
dos tienen razon para su cola. Unificarlas romperia una de las dos.
Lo que compartir nombre SI cuesta es que hace ambigua la clasificacion de
store-gc: un artefacto rancio de una puede caer como SUPERADO porque la otra
tiene sellado vigente. La condicion es precisa y esta medida — solo hay riesgo si
el hash vigente de una NO esta sellado, y hoy las dos lo estan => exposicion
CERO. Antes de podar con nombres compartidos hay que comprobar ESO, no el nombre.
La salida, si algun dia molesta, es renombrar la dinamica a gmp-shared (la
convencion que el corpus ya usa: zlib-shared, cairo-shared...). No se hizo
porque cuesta: da 7 sellados de KDE que caen a deuda. es
el mismo par por la misma razon.
Los comentarios NO entran en hash_inputs (medido: mismo hash antes y despues),
asi que esto no re-hashea nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LykB7vw38b4Ck1Zij15RQ4
|
||
 sergioandClaude Opus 5
|
0ac421b516 |
libsndfile: su configure sólo busca python2.x — tumbaba CUATRO recetas y parecía fallo de cada una
COSMIC cerró 25 de 30 raíces. De los 5 fallos, CUATRO daban el mismo mensaje — «error: no suitable Python interpreter found»— en wireplumber, xdg-desktop-portal, xdg-desktop-portal-cosmic y cosmic-settings-daemon. NO ERA DE ELLAS, Y NI SIQUIERA ERA DE MESON. El error viene de un `configure` de AUTOTOOLS que prueba `python2.2`, `python2.1`, `python2.0` —literalmente— y aborta al no hallarlos. Se identificó por las flags del comando en el log (`--disable-mpeg --disable-full-suite`), que son inconfundibles de **libsndfile**: una dep común a las cuatro. Y declarar `python3` en `[deps]` NO ayuda —dos de las cuatro ya lo tenían—: el problema no es que falte el intérprete, es que el script no reconoce ese NOMBRE. Autoconf respeta la variable de entorno `PYTHON`, así que se le pasa `PYTHON=python3` y sella. LA LECCIÓN, que hoy ya se repitió con `dbus-shared`: cuando varias recetas fallan con el MISMO mensaje raro, el fallo está en una dep común — y **la forma de identificarla es mirar QUÉ configure/meson.build lo emite**, no la receta que se estaba construyendo. Las flags del comando y el número de línea del meson.build son la firma del paquete que realmente muere. Aplicado a las tres copias (incoming-gnome, -cosmic, -kde), que dan el mismo hash. Y de paso `cosmic-settings-daemon` sí necesitaba `python3` en deps, que no lo declaraba: dos causas distintas bajo un mensaje idéntico. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
0f1f2e9ef6 |
dbus-shared: la misma flag ausente tumbaba GNOME y COSMIC enteros
`mutter`, `gnome-shell` y `xdg-desktop-portal-gnome` fallaban las tres con «ERROR: Unhandled
python exception». Las tres YA tenían `--wrap-mode=nodownload` en su propia receta, así que no
era eso — hasta que el log mostró la línea culpable:
meson.build:372:11: ERROR: Unhandled python exception
<urlopen error unknown url type: https>
WARNING: failed to download with error: name 'ssl' is not defined
La misma línea 372 que el fallo de `dbus` de hace unas horas. No fallaban ellas: fallaba una
DEP que arrastran, `dbus-shared`, cuya sombra en incoming-gnome e incoming-cosmic no tenía la
flag. La canónica del corpus y la sombra de KDE sí la tenían; estas dos no.
⇒ UNA flag ausente en una sombra tumbaba TRES raíces de perfil en GNOME y bloqueaba COSMIC de
paso. Y el mensaje nunca nombra la red: «Unhandled python exception» se lee como un bug de
meson y es que el sandbox es hermético a propósito.
Lección de método: cuando tres recetas fallan con el MISMO error y las tres ya tienen el
arreglo obvio, el fallo está en una dep común, no en ellas. La línea de meson.build en el
mensaje es lo que lo identifica — es la firma del paquete que realmente muere.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
2c2ee951d6 |
licencias: resolver -only vs -or-later CON LA CITA — y tres «pruebas» que no probaban nada
Los identificadores obsoletos (`GPL-2.0`, `LGPL-2.1`, `AGPL-3.0`) no dicen si el proyecto
concede «sólo esta versión» o «ésta o cualquier posterior», y eso decide con qué se puede
combinar el paquete y bajo qué términos puede redistribuirlo quien lo reciba.
NO SE PUEDE MIRAR EL COPYING, que es la trampa evidente: el texto de la GPL es IDÉNTICO en
los dos casos —es la licencia, no la concesión— y encima su apéndice «cómo aplicar la
licencia» contiene literalmente «or (at your option) any later version», así que buscarla
ahí da SIEMPRE positivo y parece evidencia siendo plantilla. Misma trampa que la regla del
`.a` no-PIC, donde grep contaba reubicaciones de `.debug_*`. La concesión vive en las
cabeceras de los fuentes y en el README; ahí se busca, excluyendo los ficheros de licencia.
SE GUARDA LA CITA, no sólo el veredicto: fichero + frase exacta que decidió. Una licencia es
una afirmación legal y quien la revise tiene que poder ver POR QUÉ dice lo que dice sin
repetir el trabajo.
Y eso pagó de inmediato: de las 12 primeras resoluciones, TRES eran evidencia inválida y
sólo se vieron porque estaba la cita. Cada una de una clase distinta:
· caligula — la frase salía de `checks/headless/expected.iso`, un FIXTURE DE TEST;
· libnl — de `include/linux-private/linux/seg6.h`, una cabecera del KERNEL vendorizada.
La licencia del kernel no es la de libnl;
· lm-sensors — declarado GPL-2.0 y la cita decía «version 2.1 of the License», que es la
LGPL. La frase era real pero no sostenía lo que se le atribuía.
Las tres clases quedan filtradas en el script: ficheros de licencia, rutas de test/fixture, y
código vendorizado; más una comprobación nueva de que **la cita hable de la misma versión que
la licencia declarada**.
Sembradas las 9 auditadas (13 ficheros; algunas viven en varias colas). Ambiguas: 55 → 41.
Las 40 sin evidencia quedan listadas y siguen contadas — la mayoría son Go y la familia
cosmic, donde la frase no aparece fuera del COPYING.
Hashes verificados: 0 movidos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
487e155f74 |
licencias: leer el LICENSE de verdad cuando GitHub dice «no sé» — 1053 de 1141 (92%)
Último recurso mecánico, `scripts/licencias-texto.sh`: para las 60 recetas donde la API de GitHub devuelve NOASSERTION (el repo TIENE un LICENSE pero licensee no lo reconoce: texto retocado, encabezado propio, dos licencias en un fichero), baja el texto y lo clasifica acá. 34 identificadas — 16 MIT, 10 Apache-2.0, 7 BSD-2-Clause, 1 BSD-3-Clause. SÓLO PERMISIVAS, Y NO ES PEREZA. MIT, Apache-2.0, BSD, ISC, MPL-2.0 y Unlicense se reconocen por frases inconfundibles y NO tienen variantes -only/-or-later ⇒ reconocer el texto da el SPDX completo. La familia GPL se deja al humano A PROPÓSITO, y la razón es sutil: el COPYING de la GPL es IDÉNTICO tanto si el proyecto es «sólo v3» como «v3 o posterior» — lo que las distingue vive en las cabeceras de los fuentes. Y encima el propio COPYING incluye, en su apéndice «cómo aplicar la licencia», la frase «or (at your option) any later version», así que buscarla da SIEMPRE positivo y parecería evidencia siendo texto de plantilla. Es exactamente la trampa de la regla del `.a` no-PIC, donde grep contaba reubicaciones de .debug_* y mentía. Comprobado a mano un caso que daba mala espina: el LICENSE de `conftest` empieza «Conftest — Write tests against your config files / Copyright (C) 2019 …», que es el formato típico de una cabecera GPL. Leído entero, dice «Licensed under the Apache License, Version 2.0». La clasificación era correcta; la sospecha, barata. Hashes verificados sobre las 36 tocadas: idénticos. Quedan 88, ya sin vía mecánica: los repos donde ni la API ni el texto deciden, la familia GPL sin desambiguar, y tarballs de sitios propios (gmplib, xiph, sr.ht, codeberg…). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
0225aa4e08 |
licencias: el código propio (tawasuyu) queda en MIT — 1017 de 1141 (89%)
Decisión del usuario: «tawasuyu está en MIT». Es la misma licencia que hammer (LICENSE en la raíz + Cargo.toml), así que todo lo nuestro queda coherente bajo un solo término. Las 20 recetas con fuente en git.tawasuyu.net: arje-* (el init y sus compat), mirada-* (el compositor, el greeter y mirada-ctl), netup, agora-cli, cosmos-cli, dominium-cli, tinkuy-sim, llimphi-counter y libelogind. ⚠ ANOTADO EN LA TABLA porque es una trampa que casi pisé: `libelogind` NO es el elogind de upstream (que sería LGPL-2.1+). Por el nombre lo parece; su cabecera dice que es una reimplementación PROPIA de la C-ABI sd-login dentro de arje-compat. Declararla LGPL «porque se llama así» habría sido exactamente el error que este fichero prohíbe — el tercero del mismo tipo hoy, después de `knighttime` (parecía Go y es KDE) y de la familia `kube*` (parecen KDE y son Go). El nombre nunca es evidencia; la fuente sí. Hashes verificados sobre las 20: idénticos. Quedan 124 sin declarar, ya todas de terceros. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
c8d1357f06 |
licencias: la declaración del autor manda — y arreglo 5 recetas que ROMPÍ y commiteé
Dos cosas: una mejora de calidad y un fallo mío que hay que contar entero.
═══ EL FALLO: escribí un error JSON dentro de 5 recetas y las commiteé rotas ═══
En `a6a9d59`, cinco recetas quedaron con
license = "{"message":"Not Found","documentation_url":"...","status":"404"}"
Causa: cuando el repo da 404 (renombrado, borrado, privado), `gh api` escribe el CUERPO DEL
ERROR en stdout y el filtro `--jq` falla, así que la variable queda valiendo el JSON. Mi
`case` sólo descartaba ""/null/NOASSERTION/other ⇒ el JSON pasó como si fuera una licencia.
Las comillas ROMPEN el TOML, y esas 5 recetas dejaron de parsear y de tener ArtifactHash.
No lo vio nadie leyendo: lo cazó la comparación de hashes, al detectar que `cargo-sort`
había cambiado. Afectadas: cargo-sort, cargo-audit, cargo-binstall, waybackurls, usbutils.
La lección no es «se me pasó un caso», es que **validé los «no sé» conocidos en vez de la
FORMA del dato**. Ahora se acepta sólo lo que tiene forma de expresión SPDX, y la barrera
está en los DOS sitios que escriben (detectar y sembrar), más un GUARDIÁN en el informe que
sale ≠0 si alguna licencia tiene forma imposible. Un fallo aguas arriba disfrazado de dato
hay que verlo sin buscarlo.
Y de paso normalizadas 11 licencias con la barra antigua de Cargo (`MIT/Apache-2.0`), que
no es SPDX válido. Traducir la barra a OR no es inferir: Cargo documentó esa equivalencia.
═══ LA MEJORA: `scripts/licencias-cargo.sh` ═══
Lee la licencia que el AUTOR declara en su Cargo.toml, pidiéndola AL TAG QUE LA RECETA
PINEA (`?ref=v<version>`, con HEAD como último recurso y anotando cuál se usó). 176
obtenidas, 167 al tag exacto. Es la fuente más autoritativa de las que usamos y corrige los
dos defectos de la detección por API de una vez:
· las licencias DOBLES dejan de colapsar: `fd` pasa de `Apache-2.0` a `MIT OR Apache-2.0`,
`ripgrep` a `Unlicense OR MIT`, `bat` a `MIT OR Apache-2.0`;
· los SPDX AMBIGUOS caen de 71 a 55, porque el autor sí escribe -only/-or-later.
66 corregidas, 7 nuevas. Y aparecieron cosas que la detección había perdido: `eza` es
EUPL-1.2, una copyleft europea que se habría empaquetado creyendo otra cosa.
Jerarquía de evidencia, escrita en la cabecera del script: nombre (prohibido) < familia/URL
de fuente < API de licencias de GitHub < Cargo.toml del autor.
997 de 1141 (87%). Verificación COMPLETA sobre las 77 recetas tocadas —no una muestra—:
0 hashes cambiados, y 5 que ahora parsean y en HEAD no.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
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> |
||
|
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>
|
||
|
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> |
||
|
sergioandClaude Opus 5
|
adbda20e30 |
🏁 ScreenCast CERRADO en metal — la cadena entera devuelve un stream real
Sube el pin de portal-probe a
|
||
|
sergioandClaude Opus 5
|
8d10bccf34 |
🔇 wireplumber: construido, corriendo… y NO era el bloqueo
b3:b8f3baf0, selló a la primera. Arranca desde cosmic-start ("wireplumber OK (pid
192) — hay gestor de sesión"), se conecta al grafo (dos clientes en wpctl status) y
wpctl pasa a mostrar una sección Video que antes no existía.
Y el Start de ScreenCast SIGUE sin Response a los 60s. Mismo resultado exacto.
LA HIPÓTESIS QUEDA MATADA POR MEDICIÓN. "Falta el gestor de sesión que mueva el nodo
de Paused a Streaming" era mía y era razonable; no era cierta. Queda escrita junto a
su refutación porque una hipótesis descartada CON EVIDENCIA vale más que una lista de
sospechosos: acota el próximo paso a lo que queda, que es el backend mismo.
El dato nuevo, que es por dónde seguir: con wireplumber corriendo, `wpctl status`
lista `Video → Streams` VACÍO durante el handshake. O sea que el nodo
`cosmic-screencast` que SÍ existe en `pw-cli ls Node` no llega a wireplumber como
stream gestionado. Próximo movimiento: RUST_LOG=trace sobre screencast_thread, no
otra dep.
── por qué receta propia y no la de GNOME ──────────────────────────────────────
La de incoming-gnome funciona pero NEEDea libglib/libgobject/libpipewire de la ISLA
DINÁMICA de GNOME: traerla metería una segunda glib y una segunda pipewire en la
imagen. De 19 deps, 14 dan hash idéntico; las que divergen divergen a propósito —
sobre todo `pipewire`, que acá apunta a la de COSMIC (338d1d8c), la que el escritorio
realmente ARRANCA. Un gestor de sesión contra otra pipewire que la que corre no
gestiona nada.
El cambio de fondo es glib → glib-shared. COSMIC usa la glib ESTÁTICA del corpus, que
le alcanza al portal porque es un ejecutable. Acá no: wireplumber produce un .so y 17
módulos, y libglib-2.0.a tiene 44.275 reubicaciones R_X86_64_32/32S ⇒ no es PIC. La
regla del frente GNOME (readelf -r ANTES de gastar el build) ahorró uno.
Y la salida no fue una campaña nueva sino una MEDICIÓN: incoming-kde/glib-shared
copiada a esta cola resuelve al MISMO hash (0584ce1f) y ya estaba sellada ⇒ cero
rebuild. Idem pcre2-shared, lua y libelogind. Las dos glib coexisten sin pisarse (.a
y .so son ficheros distintos) y el portal conserva sus 3 NEEDED.
escritorio-cosmic: 84 → 89 recetas, 0 faltantes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
ee037912a9 |
🎥 ScreenCast: el stream SE CREA — nodo cosmic-screencast vivo en pipewire
La receta de la sonda (b3:af49d32d) y lo que midió. Es la única receta de la campaña
cuyo producto no es una pieza del escritorio sino un instrumento para medirlo: entra
a la imagen porque un handshake de portal sólo se puede ejercer DESDE la sesión, con
bus y compositor vivos, y sale ESTÁTICA (0 NEEDED) porque un instrumento no debe
depender de aquello que mide.
[1/4] CreateSession → Response 0, session_handle ✓
[2/4] SelectSources → Response 0 ✓
[3/4] Start → el backend ABRE "Share your screen", con
miniatura EN VIVO del framebuffer y el output
Virtual-1; se elige, se pulsa Share…
y NO llega Response en 60s ✗
El log del backend da la línea exacta:
screencast_thread: state-changed 'Connecting' -> 'Paused'
Y `pw-cli ls Node` durante la espera da el veredicto INDEPENDIENTE:
node.name = "cosmic-screencast" media.class = "Video/Source"
EL NODO DE VIDEO EXISTE EN EL GRAFO DE PIPEWIRE. La cadena entera —cliente →
frontend → backend → compositor → demonio— funciona hasta crear y negociar el stream.
Lo único que no ocurre es el Response de vuelta tras quedar en `Paused`. Eso es un
lugar muy distinto del de esta mañana ("no hay demonio con quien negociar").
Sospecha para el próximo paso, y es HIPÓTESIS no medición: falta `wireplumber`. Sin
gestor de sesión nadie mueve el nodo de Paused a Streaming y el backend parece
esperarlo. Construirlo la confirma o la mata.
Gotchas que costaron corridas y quedan escritos:
· matar el backend se lleva puesto al frontend (ambos pierden dueño del bus);
· el lanzador busca por NOMBRE VISIBLE: `cosmic-term` no matchea, `Terminal` sí —
escribir el nombre del binario abre otra app;
· `| head -N` bufferiza y deja la terminal en blanco: parece colgada y está esperando;
· pkg-config OMITE los -L de dirs "estándar" y zig cc cross NO los busca ⇒
`-ldbus-1` pelado da "unable to find static system library", que suena a librería
faltante cuando lo que falta es la ruta.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
1e786aaf42 |
🚪 cosmic: el BACKEND del portal sella (b3:7ad0f124) — cadena completa en la imagen
69 min. NEEDED: libgbm, libpipewire, libxkbcommon, libc. Instala el binario en /usr/libexec, el .service de D-Bus con @libexecdir@ sustituido, el cosmic.portal que declara las cinco interfaces (Access/FileChooser/Screenshot/Settings/ScreenCast) y sus iconos. clang18 se construyó en la granja y se cosechó al laptop (b3:62c6bfb5), pero el backend NO se pudo construir allá: el worker no tiene la cola COSMIC horneada —el snapshot golden es del 2026-07-15 y toda esta cola es posterior— así que intentó reconstruir pipewire y murió buscando glib. Es la regla de «rootfs laptop ≠ worker» pero con el STORE: lo que en el laptop es cache-hit, en el worker es un build entero con sus propias deps. Y destapó que la receta de pipewire NO lleva --wrap-mode=nodownload: ante una dep faltante intenta bajarse un subproyecto de internet y, sin red, el error que sale no es «te falta glib» sino «Unhandled python exception / This is a Meson bug». Queda anotado como deuda. --offline SIN --locked, y no es descuido: el sed del parche corre en la fase compile, o sea DESPUÉS del cargo vendor, así que cargo ve el Cargo.toml cambiado y con --locked se niega. Quitar una feature sólo puede ENCOGER el conjunto de crates, así que lo que haga falta ya está vendorizado; la hermeticidad la da --offline + el árbol vendorizado, no el --locked. Dos raíces en el perfil y en la hidratación, porque son DOS procesos que se encuentran por D-Bus en runtime y ningún [deps] los relaciona. Imagen en 83 recetas (eran 74). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
e914dd63e9 |
🚪 cosmic: el BACKEND del portal + clang18 — recetas listas para la granja
clang18 b3:62c6bfb5 (sólo libclang.so)
xdg-desktop-portal-cosmic b3:97dfddd8
EL PARCHE DE UNA LÍNEA resultó ser el que se esperaba: xdp-cosmic declara
cosmic-files con features = ["gvfs", "wayland"] FIJADAS a mano —mismo patrón
que deja fuera a cosmic-files-applet— así que apagarla desde afuera no
alcanza. El sed la saca y queda la misma combinación que ya compilaron
cosmic-term y cosmic-edit. Se pierden los montajes remotos DENTRO del
selector del portal, no el selector.
PERO APARECIÓ UN ESLABÓN QUE NO ESTABA EN EL PLAN: libclang.
xdp-cosmic declara pipewire y libspa-sys como deps DURAS (screencast)
→ libspa-sys/build.rs corre bindgen::builder() INCONDICIONAL
→ bindgen carga libclang.so en tiempo de build
Verificado que no hay atajo: ese build.rs no tiene rama alternativa, a
diferencia de aws-lc-sys —que sí cae a bindings pregenerados
(cargo:rustc-cfg=universal) y por eso cruzó a musl sin cmake ni perl—. Y
libclang no está ni en el corpus ni en los 182 binarios del rootfs del
constructor: llvm18 se selló con -DLLVM_ENABLE_PROJECTS="".
Lo barato es que NO se recompila LLVM: el artefacto llvm18 ya publica
usr/include/llvm, usr/include/llvm-c y usr/lib/cmake/llvm, así que clang18
es un build de clang CONTRA un LLVM sellado. Se instala sólo libclang.so y
clang-c/: el binario `clang` no es el objetivo — el compilador de esta
distro sigue siendo zig-cc, y sumar otro sería lo contrario de la deuda que
la campaña «matar gcc» viene pagando.
Patrón gcc-de-gueto (igual que llvm18 y cmake): g++ con -static-libstdc++
-static-libgcc para que la .so quede con NEEDED sólo libc.musl y no contagie
el runtime C++ de Alpine a cada build que la declare.
Vale decir de dónde sale este costo: no de COSMIC, sino de que pipewire-rs
genera sus bindings en cada build.
Ambas van a la granja (decisión del usuario): mismo peso que llvm18, que ya
se selló en el worker gordo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
d664267eff |
🚪 cosmic: EL FRONTEND DEL PORTAL sella — org.freedesktop.portal.Desktop existe
Tres recetas nuevas y el eslabón que faltaba de verdad:
fuse3 3.18.2 b3:3a84af86
json-glib 1.10.8 b3:dc8c8e78 (variante SIN introspección)
xdg-desktop-portal b3:f4adb8c9 1.18.4
El artefacto trae /usr/share/dbus-1/services/org.freedesktop.portal.Desktop.service
—el nombre exacto que cosmic-screenshot no encontraba— más
xdg-document-portal y xdg-permission-store. NEEDED del frontend: libz,
libpipewire y libc.
CUATRO COSAS MEDIDAS QUE VALEN MÁS QUE LAS RECETAS:
1. PIN A 1.18.4 POR GSTREAMER. Desde 1.20 meson pide
dependency('gstreamer-pbutils-1.0') sin required: —para validar sonidos
de notificación— y eso arrastra gstreamer + gst-plugins-base. La 1.18.4
no lo pide: sus deps duras son glib/gio/gio-unix, json-glib, fuse3,
gdk-pixbuf y pipewire, y de ésas la única que faltaba era fuse3. Es un
pin deliberado: el día que se quiera 1.22 el precio es gstreamer.
2. fuse3: NO poner -Ddisable-libc-symbol-version=true aunque suene a lo
correcto para musl. Lo probé razonando eso y falla el enlace: la opción
sólo hace que compat.c no emita los alias versionados, pero
lib/meson.build:54 pasa --version-script INCONDICIONALMENTE, o sea que
el script queda pidiendo símbolos que ya nadie define. Es una combinación
incoherente de upstream, no una limitación de musl. La auto-detección de
upstream tampoco conoce musl: sólo apaga versionado para __UCLIBC__ y
__APPLE__. Se deja el defecto, que es con lo que Alpine construye.
3. json-glib NO se puede reusar de incoming-gnome: aquella está en la ISLA
DINÁMICA (introspection=enabled, default_library=both) porque su .gir es
entrada del .gir de evolution-data-server. Traerla metería toda la
maquinaria de introspección de GNOME en la clausura de COSMIC para no
usar un solo .typelib.
4. EL CHOQUE DE gvdb, y por qué se resolvió renombrando símbolos. El portal
vendoriza gvdb y glib TAMBIÉN lo lleva adentro (GSettings): con glib
estática el .a expone los símbolos y el enlazador ve dos definiciones.
Los otros dos caminos se descartaron POR MEDICIÓN:
· --allow-multiple-definition / -z muldefs: zig-cc NO lo acepta
(«unsupported linker arg»), y meson lo reporta como «Compiler
hammer-zig-cc cannot compile programs», que manda a buscar el
problema donde no está.
· glib-shared: no es cambiar una dep sino abrir una cadena (json-glib y
gdk-pixbuf también enlazan glib) y meter la segunda glib en la imagen.
El renombrado con -D es total —afecta definición y usos, todos pasan por
gvdb-reader.h— así que el binario queda con lector+constructor de la
misma copia. Importa: glib empaqueta sólo el LECTOR, el CONSTRUCTOR
existe únicamente en el portal.
Bonus de meson: las opciones de tipo lista se parten por COMAS, así que
-Dc_args/-Dc_link_args no sirven para banderas con comas; van por CFLAGS y
LDFLAGS. Y quitar un subdir() no es gratis: subdir comparte ámbito de
variables, y sacar subdir('tests') rompía el summary() que lee
enable_pytest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
520271ea2f |
📷 cosmic: cosmic-screenshot sellada y ROTA A PROPÓSITO — y la glib compartida YA existe
b3:8b57ec9b, 9 minutos, NEEDED = libc.so y nada más. Un solo NEEDED, y el único `[deps] build = []` de la campaña: 130 líneas de Rust que no dibujan ni hablan wayland. Se incluye en la imagen sabiendo que falla, para que el hueco sea MEDIBLE en vez de supuesto. Error exacto capturado corriéndola desde cosmic-term dentro de la VM: panicked at src/main.rs:76:10: failed to send screenshot request: Portal(ZBus(MethodError(ServiceUnknown, "The name org.freedesktop.portal.Desktop was not provided by any .service files"))) Misma forma que la deuda de org.freedesktop.locale1: un nombre de D-Bus que nadie sirve. LA CADENA DEL PORTAL SON TRES ESLABONES, NO DOS. Medido en el fuente: xdg-desktop-portal-cosmic declara DBUS_NAME = "org.freedesktop.impl.portal.desktop.cosmic" (src/main.rs:27) — es BACKEND, no toma el nombre que los clientes buscan. Falta también el frontend xdg-desktop-portal, y ninguno de los dos está en ninguna cola. ⚠ CORRECCIÓN AL PROPIO RUNBOOK: decía que `gvfs` exigía «una campaña propia». Es falso desde que KDE selló las piezas. Verificado con `hammer hash` desde las dos colas —el método correcto para saber si una receta se comparte—: glib-shared 2.88.1 (b3:0584ce1f) y pcre2-shared (b3:f254abaa) resuelven IDÉNTICO desde incoming-cosmic ⇒ cero rebuild, los artefactos sirven tal cual. zlib-shared ya estaba en la cola. libffi entra estático dentro de la .so (su Requires.private lo ignora pkg-config fuera del modo estático). Lo que queda de `gvfs` NO es técnico sino una decisión: mete una segunda glib en la imagen —lo que GNOME midió y evitó— y re-hashea cosmic-files, que arrastra a cosmic-term y cosmic-edit porque lo usan como crate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
b51f90ffea |
🛍 cosmic: cosmic-store — sella (b3:a06437f7), y BoringSSL cruza a musl sin cmake
La quinta aplicación, y la primera de la suite que choca con que hammer es
OTRA distro: una tienda es la cara de un gestor de paquetes y el de abajo no
es el suyo. De los cuatro backends de `src/backend/`:
flatpak pide libflatpak (GObject) ⇒ la cadena glib COMPARTIDA más
ostree/libsoup/gpgme: la torre de C que esta campaña no tiene
packagekit Rust puro (packagekit-zbus) pero necesita el DEMONIO en el bus
rpm-ostree irrelevante
pkgar el único que arranca: ni demonio ni enlace, lee el AppStream
del sistema — o sea los .metainfo.xml que instalan las recetas
ALCANCE HONESTO: con pkgar NAVEGA, no INSTALA. Ninguna operación está
cableada al .swm de hammer (Etapa F). El camino para arreglarlo quedó
identificado y no cuesta un solo .so de C: servir
`org.freedesktop.PackageKit` sobre .swm, mismo patrón que
arje-logind-compat.
HALLAZGO REUTILIZABLE: `aws-lc-sys` (BoringSSL, C + ensamblador) compiló
bajo zig-cc/musl SIN cmake y SIN perl — ninguno de los dos está en los 182
binarios de work/builder-rootfs/usr/bin. Tomó el camino de bindings
pregenerados (`cargo:rustc-cfg=universal`) y compiló los 21 MB de
libaws_lc_crypto.a con el crate `cc`. El `Compiling cmake v0.1.58` del log
es el crate ayudante, que se compila aunque el binario no se invoque. Esto
destraba cualquier receta futura que entre con rustls por defecto, que hoy
es casi todo lo que use reqwest.
NEEDED: libxkbcommon.so.0 y libc.so, igual que cosmic-edit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
d5f798a6b1 |
✎ cosmic: cosmic-edit — la 4ª aplicación, y el Cargo.lock miente por exceso
El editor de texto sella en b3:2323a325, igual que el dry-run. Es la más barata de las cuatro: depende de `cosmic-files` como CRATE con `default-features = false`, así que su árbol ya estaba compilado (68 min de enlace, no de compilación desde cero). Lo que aprendió esta receta, y que corrige un borde de la regla anterior: **el `Cargo.lock` lista lo POSIBLE, no lo ENCENDIDO**. Aparecen `gio-sys`, `glib-sys` y `gobject-sys` —que en cualquier otro paquete mandarían a declarar glib y de ahí a la cadena compartida— y sin embargo entran sólo por la feature `gvfs`, que se apaga. El lock dice el universo; las features dicen el recorte. Features: `--no-default-features --features dbus-config,wayland`. Fuera `gvfs` (pide las glib compartidas, el corpus las tiene estáticas) y `wgpu` (el que desbordó el filesystem dos veces en cosmic-files). La doble barra `pop-os//` que mordió en applets y settings acá está comentada en el Cargo.toml; verificado con grep ANTES del build. Evidencia: el binario enlaza sólo `libxkbcommon.so.0` y `libc.so` — dos NEEDED, el mínimo de la suite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
232f23c5a8 |
⚙ cosmic: cosmic-settings — el panel de control, y NO arrastra medio sistema
Sellada b3:716dac53. Cola 33/33, escritorio-cosmic 71/71. Abre desde el lanzador con la barra lateral entera (Red, Bluetooth, Accesibilidad, Escritorio, Pantallas, Sonido, Energía, Entrada, Aplicaciones, Fecha y hora, Sistema y cuentas). Tarda ~20s con render por software; no está colgado. La sorpresa buena: nada de NetworkManager, libpulse, udisks ni accountsservice — habla con los daemons por zbus, que es Rust puro. Se verificó ANTES de escribir la receta listando los crates -sys del Cargo.lock, que es donde vive la verdad sobre qué C hace falta: sólo drm-sys, input-sys, libudev-sys, dav1d-sys, wayland-sys (dlopen) y gettext-sys. Regla barata: grep '^name = ".*-sys"' Cargo.lock antes de adivinar deps por lo que el programa hace. Volvió a morder la doble barra de cosmic-protocols// (404 de GitHub, muere en el fetch con tres reintentos). Segunda víctima ⇒ es patrón de la suite, no rareza de un repo. Instala 32 .desktop, uno por página. Y default_schema va con find, no cp plano: es el árbol <Componente>/v1/<clave> de cosmic-config, donde cada clave es un fichero con su nombre. Deuda que deja su propio log: org.freedesktop.locale1 no lo sirve nadie ⇒ la página de idioma no podrá cambiar nada. Mismo tipo que login1, mismo arreglo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
23c0e82527 |
📁 cosmic: cosmic-files — la 2ª aplicación, y «ya está compilado» era falso por una línea
Sellada b3:48d2b072. Cola 32/32, escritorio-cosmic 70/70. Abre desde la biblioteca y lista el sistema de ficheros real de hammer (bin 72 ítems, dev, ente, etc, lib, lost+found). Entró creyendo que era casi gratis porque cosmic-term ya la compila como crate. No lo era: cosmic-term la declara con default-features = false. Lo que un paquete cuesta depende de con qué features lo pide quien lo usa, así que «ya se compiló» puede ser falso. Dos features apagadas, las dos por medición: · gvfs trae gio/glib y el enlace final pide las glib COMPARTIDAS; el corpus sólo las tiene estáticas. Se pierden montajes remotos, no la navegación local. Por eso tampoco se construye cosmic-files-applet: su Cargo.toml fija gvfs a mano. · wgpu desbordó el filesystem dos veces (No space left on device en /src/target) con wgpu+naga+ash+glow+spirv a codegen-units=1. Sin él el árbol queda en ~2 GB, y no se pierde nada: el resto de la suite pinta con tiny-skia y la imagen no tiene GPU. Y la regla que dejó el intento con glib declarado: el error fue «Package libpcre2-8, required by glib-2.0, not found» — el que falla no es la dep sino lo que su .pc declara en Requires. Declarar una dep trae su artefacto, no su clausura de pkg-config; se lee con grep ^Requires sobre los .pc ANTES de gastar el build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
e39610588d |
🖥 cosmic: cosmic-term — la primera APLICACIÓN, y la biblioteca deja de estar vacía
Sellada a la primera (b3:d0ea1c1e). Cola 31/31, escritorio-cosmic 69/69. Dentro de la ventana: bash-5.3#, uname -srm devuelve Linux 6.16.12 x86_64 —el kernel propio de hammer— y qalc -t '6*7' devuelve 42, o sea la calculadora que empaquetamos una hora antes. Se abre con click en su icono en la biblioteca, que hasta hoy salía vacía con razón: los 20 .desktop de la imagen eran NoDisplay=true. Éste no lo es. Lo que arrastra y no se adivina: su Cargo.toml depende de cosmic-files, o sea que el gestor de ficheros entra como LIBRERÍA (selector y drag-and-drop) y compilar la terminal compila medio gestor de ficheros. En esta suite las aplicaciones se usan unas a otras como crates, y el grafo de Cargo no se parece al mapa de componentes. De paso, empaquetar cosmic-files como aplicación queda casi gratis. wgpu viene en default, al revés que el resto de los clientes: se deja, porque wgpu y naga ya se habían compilado enteros para cosmic-workspaces y apartarse de las features por defecto es apartarse de la única combinación que upstream prueba. Cierra con dos NEEDED. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
9665cc29d4 |
cosmic: la calculadora del lanzador ANDA — el stdin de qalc era el stdout
=123*456 → 56088 en el lanzador. libqalculate re-sellado b3:edb8d14d. La causa del «no lee nada de la tubería» no era readline, ni el toolchain, ni la versión: el binario salía DINÁMICO pese a link="static", porque libtool se come el -static que inyecta el harness. Y en un musl dinámico stdin, stdout y stderr se resolvieron por copy relocation a UNA SOLA ranura de BSS compartida —las tres en la misma dirección—, así que fileno(stdin) daba 1: el stdin del programa era el stdout. Eso explica la asimetría que parecía absurda, que qalc -f /dev/stdin funcionara (abre el fd por RUTA, sin tocar el FILE* roto) y qalc leyendo stdin no. Fix: make LDFLAGS="-all-static -no-pie", el mismo par que ya usa libxml2. Con él los tres símbolos vuelven a tener direcciones distintas en .rodata. Regla para el runbook: link="static" en la receta NO garantiza un binario estático — readelf -d y nm -S | grep ' std' lo contestan en dos segundos. Segundo muro: qalc pregunta si activar autocalc antes de leer nada, el plugin le manda la expresión y cierra, la expresión se consume como respuesta y qalc nunca llega a guardar config ⇒ vuelve a preguntar siempre. Se siembra qalc.cfg desde cosmic-start, política de imagen como el color de fondo. Y hay que repetir el -L de los alias de curses en el make: el LDFLAGS del make pisa al del configure. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
03ec0e6827 |
cosmic: libqalculate + gmp + mpfr — qalc anda, y el plugin del lanzador igual no lo puede usar
Las tres selladas a la primera (gmp b3:d99a0a5d, mpfr b3:13982d20, libqalculate b3:6bb435a7). La cadena entera desde una tecla está en el catálogo: Super → cosmic-launcher → pop-launcher → plugin calc → qalc → mpfr → gmp. Cola 30/30, escritorio-cosmic 68/68. qalc FUNCIONA: -t '2+2' da 4, -f fichero anda, e interactivo sobre terminal calcula. Pero el plugin lo invoca SIN expresión, con stdin en tubería, le escribe la cuenta y cierra — y en ese modo nuestro binario no lee nada. Acotado a que, con el EOF ya pendiente en un stdin que no es terminal, readline() devuelve NULL antes de entregar la línea que sí está en el búfer. Descartado midiendo, para no repetirlo: no es el toolchain (una sonda estática musl del sandbox lee la tubería en C y en C++); no es readline vs no-readline (sin ella es peor: no lee nunca); no es la versión de readline (una 8.3 sombra no movió el síntoma, y se descartó en vez de dejar una receta duplicada inútil); y no es el descriptor 0, porque Could not open "/dev/stdin". —el mismo pipe reabierto por ruta— sí funciona. El que no sirve es el FILE* stdin, y ahí queda la pista. Dos gotchas del empaquetado: gmp va con --disable-assembly (elige rutinas mirando la CPU de quien compila, o sea hornearía la ISA del laptop en el hash), y el configure de libqalculate no encuentra readline porque prueba -lncurses/-lcurses/-ltinfo y el corpus sólo empaqueta libncursesw.a — los alias van en un directorio local, no ensuciando /usr/lib, que es la evidencia de qué se declaró. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
505eaf5e44 |
cosmic: pop-launcher — el lanzador eran DOS programas, y ahora Super abre
cosmic-launcher sólo dibuja: manda lo tecleado por stdin a un proceso hijo, pop-launcher, que es quien busca. Sin ese binario la ventana no tiene qué mostrar y no se muestra — mismo modo de falla que el panel sin applets: falta un HIJO, no una librería, y el log del padre se lee sano. Vive en otro repo (pop-os/launcher), fuera del pin epoch-N. La versión la fija el Cargo.lock de cosmic-launcher (rev a332a3a7 de la 1.2.7), no el último tag: el lock es lo que garantiza que hablen el mismo protocolo. Tarball por commit, porque no hay tag que nombre esa rev. Selló a la primera, b3:64a5cbaa, con un solo NEEDED: libc.so. Verificado de punta a punta: Super abre el lanzador, «?» lista los seis plugins con su sintaxis (o sea que la enumeración y el IPC JSON-sobre-stdio andan) y «=2+2» LANZA el plugin, que contesta «qalc command is not installed». Esa respuesta es la mejor prueba disponible: el hijo corrió, evaluó y devolvió fila. Falta libqalculate, que es un paquete, no un problema. Cola 27/27, escritorio-cosmic 63/63. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
a232bcc0af |
cosmic: los atajos andan (Super+A, Super+W) y el panel tiene un deadline de arranque
Faltaba sanear un SEGUNDO fichero: system_actions de cosmic-settings-daemon, que liga acción→comando, con la misma entrada ScreenReader que el enum del parser no conoce. Con defaults roto no hay ligaduras; con system_actions roto hay ligadura y ningún comando. Ahora Super+A abre la biblioteca y Super+W la vista de espacios de trabajo — con miniatura VIVA del escritorio dentro, o sea que el camino DMA-BUF→GBM de cosmic-workspaces anda de verdad. Super a secas no abre nada porque pop-launcher (el motor del lanzador) no está en el catálogo; los atajos no tienen la culpa. Me equivoqué de fichero teniendo el dato: el error traía línea y columna y busqué el token en vez del fichero que lo tiene en esa posición. Costó 40 minutos de rebuild. Y el panel tiene un DEADLINE para registrar su servidor D-Bus: con -smp 4 arranca sin ala izquierda, sin reloj y sin dock (894 colores vs 130); con -smp 8 -m 8192 son 4 de 4 completos. Perseguí eso como una regresión mía, revirtiendo tres cambios inocentes, porque usé el conteo de procesos como veredicto: un escritorio sano muestra 32, no 48. El framebuffer es el veredicto; los procesos no distinguen «arrancó» de «dibujó». Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
39b91b5146 |
cosmic: la entrada anda — click y teclado por QMP; y 29 atajos caídos por UNA línea
El click sobre «Applications» abre la biblioteca (el color dominante pasa de fondo 91% a 27,27,27 84%) y tecleando aparece «cosmic» en el buscador. Se maneja entero por QMP con input-send-event, sin humano y sin ver la pantalla. USB HID, no virtio-input: el kernel de hammer no trae VIRTIO_INPUT, así que -device virtio-keyboard no crea ni un /dev/input/event*. Con qemu-xhci + usb-kbd + usb-tablet anda, y además es lo que se va a usar en metal. Y el hallazgo de fondo: Super no abría el lanzador TENIENDO la ligadura en el fichero. keybindings.ron de epoch-1.5.0 liga Super+Alt+S a System(ScreenReader), acción que el crate que lo parsea (cosmic-settings-config, rev 8c54bbbc) no tiene en su enum. RON no ignora lo desconocido: falla el mapa entero y se caen las 29 ligaduras. El único rastro era un WARN de cosmic-idle a 200 líneas del arranque hablando de un enum — el síntoma no nombra ni la tecla ni el fichero. El pin lockstep fallando desde adentro de upstream. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
63b777f91e |
cosmic: cosmic-workspaces necesita mesa — la dep sale de lo que DIBUJA, no del toolkit
Sellado b3:a031249e. La vista de espacios de trabajo muestra miniaturas vivas de las ventanas: el compositor se las pasa como DMA-BUF por zcosmic-toplevel-info y el cliente importa el fd con GBM ⇒ -lgbm. Es el único cliente de la suite que toca el pipeline gráfico además del compositor, así que el juego fijo de cuatro no alcanzaba. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
e99fc836fb |
cosmic: los applets necesitan la libdbus COMPARTIDA, y el linker lo dice una hora tarde
`cosmic-applets` declaraba `dbus` a secas. Alcanza para que el build.rs de libdbus-sys pase —le basta el .pc, que el paquete del daemon trae— y el fallo salta recién en el enlace final del multiplexor: 'unable to find dynamic system library dbus-1'. El corpus sólo empaqueta libdbus-1.a; el .so vive en `dbus-shared`, que es lo que ya declaraban settings-daemon y pipewire. Era la única receta de la cola que pedía la estática. De paso, las cuatro piezas que spawnea el PANEL (no cosmic-session) entran como raíces de hydrate-cosmic.sh: se invocan por AppID, así que ningún grafo de deps las alcanza. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
44820a3fa3 |
cosmic: los applets hablan D-Bus por la C, no por zbus
libdbus-sys cortó el build de cosmic-applets. El resto de la suite habla D-Bus con zbus (Rust puro), pero los applets de red, bluetooth y status-area usan la libdbus de verdad por FFI. Gotcha de diagnóstico: el build.rs de libdbus-sys hace 'panic!' a secas en la línea 25, sin mensaje. Lo único que dice qué falta es el NOMBRE DEL CRATE — no buscar una explicación en el error, no la hay. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
0e8abb8059 |
cosmic: la barra de más de cosmic-applets — no es un dedazo, es un truco, y hay que respetarlo
El manifiesto apunta a 'https://github.com/pop-os/cosmic-protocols//' con DOS barras al final. Es como upstream hace que cargo trate esa fuente como DISTINTA de la URL normal, para que el [patch] de al lado no se apunte a sí mismo. Pero GitHub devuelve 404 a '/pop-os/cosmic-protocols//info/refs' y cargo vendor muere en el fetch, antes de compilar una línea. El primer intento fue cambiar '//' por '.git', y falló POR LA RAZÓN QUE HACE QUE EL TRUCO EXISTA: cargo normaliza el .git, así que el patch pasaba a apuntar a la misma fuente que reemplaza — 'patches must point to different sources'. La barra de más no es reemplazable por cualquier variante cosmética: tiene que ser una que cargo considere OTRA fuente y que el servidor sepa servir. Sólo cumple las dos la barra en el MEDIO ('pop-os//cosmic-protocols'), que es justo la forma que usa cosmic-comp — y por eso aquél construyó sin parche. Se toca Cargo.toml y Cargo.lock juntos: cambiar uno solo rompe el --locked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
516610b307 |
cosmic: cosmic-panel selló y no pintó — le faltaban los HIJOS, no una librería
cosmic-panel (b3:ac5e48c5) arranca perfecto: lee su config, crea su wl_output, dice 'Spawning applets' y 'Done spawning applets'. Y la pantalla no cambió ni un color. La respuesta estaba en esa misma línea: spawnea TRECE clientes por AppID y ninguno existía. Un panel sin applets no es un panel vacío, es un panel que no tiene nada que medir y no se dibuja. Es la misma forma del muro de los typelibs en GNOME: un componente puede arrancar sin errores y no pintar porque lo que le falta es un HIJO. El log del padre se lee sano. La receta cubre el panel entero de una: upstream compila UN binario multiplexor y cada applet es un symlink con el nombre que el panel invoca; despacha por argv[0]. Veinte symlinks, dos binarios. Fase compile custom porque hay que construir DOS targets (los default-members) y 'cargo rustc --' sólo admite uno. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
5a4ee1a3bf |
cosmic: el settings-daemon toca TLS, y por donde uno no lo busca
openssl-sys cortó el build con 'Could not find directory of OpenSSL installation'. No lo pide el daemon: llega por native-tls, que llega por el crate geonames — la base de husos horarios que usa para el tema claro/oscuro por hora. Es el único de la suite que toca TLS, y por una función que nadie asocia con la red. El openssl del corpus ya publica openssl.pc, así que alcanza con declararlo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
95cf728991 |
cosmic: receta de cosmic-settings-daemon — la pieza sin la cual NO HAY SESIÓN
Escrita mientras compila su dep: cosmic-session lo lanza con .expect() en main.rs:255, así que si falta panickea la sesión entera JUSTO DESPUÉS de que el compositor arrancó bien. Eso es lo que lo hace confuso de diagnosticar y lo que lo puso último en la cola pese a ser obligatorio. Es el único de la suite con cadena propia en C (audio-server → cosmic-pipewire → libpipewire-0.3 por pkg-config), que es exactamente lo que costó traerlo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
d3c0545c4d |
cosmic: la cadena de pipewire entra a la cola — sale MUCHO más barata de lo estimado
Medido en vez de estimado: copiar pipewire a incoming-cosmic necesita CUATRO recetas hermanas (alsa-lib, dbus-shared, libsndfile, pulseaudio), no las seis que había contado a ojo, y de esas **tres dan hash idéntico y ya están selladas**. Sólo pulseaudio y pipewire hay que construir, porque su glib resuelve al corpus (b3:93d2cad0) en vez de a la sombra de GNOME (b3:f6ccdf98). Y eso refina lo que este runbook advertía: el peligro de las dos glib es MEZCLARLAS EN UNA IMAGEN, y la imagen COSMIC tiene una sola. Acá el costo es de builds, no de corrección. Lo que sigue vigente es no promover a ciegas entre colas. Gotcha del copiado: el se resuelve relativo a la receta, así que copiar el .toml sin su .patch da 'no pude leer patch' — el hash ni siquiera se calcula. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
sergioandClaude Opus 5
|
13dc9e3488 |
cosmic: el juego fijo de deps de todo cliente son CUATRO, leído de una vez del comando del linker
La línea de enlace de cosmic-osd pedía '-ludev -linput -lxkbcommon': los tres llegan por la cadena de libcosmic (enumeración de monitores y de dispositivos de entrada), no por nada que el cliente haga a la vista. Los venía descubriendo de a uno por build —xkbcommon con cosmic-bg, udev con osd, ahora input— hasta leerlos todos juntos en el comando que rustc le pasa al linker. El error dice el que falta primero; el COMANDO dice todos. Entra además cosmic-idle rehecho dinámico (b3:e1806acc). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |