Files
takana/recipes/incoming-gnome/libical.toml
T
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

55 lines
4.0 KiB
TOML

# libical 3.0.20 — implementación de iCalendar (RFC 5545). Es la dep dura de evolution-data-server:
# libecal-2.0 está construida sobre libical-glib, y libecal-2.0 es lo que gnome-shell exige en
# meson.build:72 para el calendario del panel superior. Cadena: gnome-shell → eds → libical.
#
# LISTA CONTRA EL CMakeLists.txt REAL (3.0.20), no de memoria:
# Perl :193 find_package(Perl REQUIRED) — DURA, sin perilla. Genera código a partir de las
# tablas de propiedades/valores. Sale gratis: perl ya se promovió a recipes/perl.toml
# cuando el barrido de harkaq en la granja lo destapó como el único irreducible.
# LibXML :485 — la pide ICAL_GLIB, pero SÓLO la enlaza `ical-glib-src-generator`
# (src/libical-glib/CMakeLists.txt:12), un ejecutable de BUILD que parsea el XML de la
# API para generar las fuentes. No entra en ningún .so ⇒ la libxml2.a canónica (no-PIC)
# sirve tal cual y NO hace falta una variante libxml2-shared. Es la segunda vez en esta
# cadena que leer el build real ahorra una receta.
# ICU :214 COMPONENTS uc i18n data — opcional, da soporte RSCALE (calendarios no
# gregorianos). Se enciende porque icu4c ya está sellada por KDE: sale gratis.
# BerkeleyDB :256 — opcional, apagada. Es un backend de almacenamiento heredado que eds no usa.
#
# Cada apagado y lo que compra:
# -DWITH_CXX_BINDINGS=OFF → viene en True por defecto (:136). Encenderlo mete el runtime C++ en el
# artefacto, que es exactamente la deuda irreducible que harkaq destapó en
# brotli y que se cerró con -static-libstdc++. No hay consumidor: eds es C.
# -DUSE_BUILTIN_TZDATA=ON → clave para la reproducibilidad. Por defecto libical lee la tzdata del
# SISTEMA (/usr/share/zoneinfo), o sea que el artefacto quedaría atado al
# sysroot del constructor y cambiaría con cada actualización de zoneinfo del
# host. Con la tzdata del propio tarball el artefacto es autocontenido y entra
# entero al ArtifactHash. El CMakeLists avisa "(Careful)" porque esa tabla
# envejece con el tarball; es el precio correcto acá — un store direccionable
# por contenido no puede depender del reloj del anfitrión.
# -DICAL_BUILD_DOCS=OFF -DLIBICAL_BUILD_TESTING=OFF → ambas vienen en True por defecto (:421, :677).
# -DICAL_GLIB_VAPI=OFF → Vala; no hay valac en el corpus y nadie lo consume.
#
# -DGOBJECT_INTROSPECTION=ON y SHARED_ONLY: isla dinámica. eds expone ECal a gjs y ese typelib
# arrastra ICalGLib; sin .so real no hay typelib. Ver [[gnome-introspection-dinamica]].
name = "libical"
version = "3.0.20"
# licencia: LICENSE del tarball: «distributed under two licenses. You may choose the terms of either: MPL v2.0 or LGPL v2.1». El fichero no dice «or later» en ningún sitio
license = "MPL-2.0 OR LGPL-2.1-only"
[source]
tarball = "https://github.com/libical/libical/releases/download/v3.0.20/libical-3.0.20.tar.gz"
sha256 = "e73de92f5a6ce84c1b00306446b290a2b08cdf0a80988eca0a2c9d5c3510b4c2"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
[build.phases]
configure = "PKG_CONFIG_PATH=/usr/lib/pkgconfig PYTHONPATH=/usr/lib/python3.12/site-packages cmake -S . -B build -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DSHARED_ONLY=ON -DICAL_GLIB=ON -DGOBJECT_INTROSPECTION=ON -DICAL_GLIB_VAPI=OFF -DWITH_CXX_BINDINGS=OFF -DUSE_BUILTIN_TZDATA=ON -DICAL_BUILD_DOCS=OFF -DLIBICAL_BUILD_TESTING=OFF -DICAL_ERRORS_ARE_FATAL=OFF"
compile = "PYTHONPATH=/usr/lib/python3.12/site-packages cmake --build build -j\"$(nproc)\""
install = "PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out cmake --install build"
[deps]
build = ["cmake", "pkgconf", "python3", "perl", "py3-setuptools", "gi-foreign-girs", "gobject-introspection", "glib", "glib-introspected", "libxml2", "icu4c", "libffi", "pcre2", "zlib-shared"]