Files
sergioandClaude Opus 5 a6a9d59e4f licencias: 936 de 1141 (82%) — detección por evidencia, con sus dos imprecisiones declaradas
Esta mañana eran 0. Tras la tabla curada (228) y este paso, 936. Ninguna receta se
re-hasheó: verificado en 30 de las 708 tocadas, 30 hashes idénticos, 0 cambiados.

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

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

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

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

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

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

Quedan 205 sin licencia y 71 por desambiguar.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 13:26:22 -04:00

46 lines
2.0 KiB
TOML

# zlib-ng 2.2.4 — el veredicto del piloto T5 (plan-variantes-cpu, 2026-07-17): la respuesta a
# "¿zlib v3?" no es una variante de la zlib de madler sino este fork — SIMD (SSE4/AVX2/AVX512)
# con DISPATCH EN RUNTIME ⇒ un solo artefacto rinde en cualquier CPU, cero maquinaria de
# variantes. Probado en serio: Fedora 40 lo envía como la zlib del sistema.
#
# ENTRADA AL CATÁLOGO, NO REEMPLAZO: recipes/zlib.toml queda INTOCADA (es dep del frente rust
# —mrustc la enlaza— y pieza del toolchain sellado). zlib-ng se construye en modo compat
# (ZLIB_COMPAT=ON ⇒ libz.a con la ABI de zlib) para poder medir zlib-ng vs zlib en una máquina
# quieta y, si paga, adoptarla consumidor a consumidor vía [deps] — jamás con un rename mágico.
#
# cmake y no el ./configure propio: el configure de zlib-ng asume bash-ismos que el busybox sh
# del sandbox no trae; el generador cmake ya está sellado en el catálogo (y tras matar-gcc no
# arrastra runtime C++ de Alpine).
#
# PENDIENTE construir en el WORKER (el laptop no compila recetas C). sha256 verificado del
# tarball de GitHub 2026-07-17.
name = "zlib-ng"
version = "2.2.4"
license = "Zlib"
[source]
tarball = "https://github.com/zlib-ng/zlib-ng/archive/refs/tags/2.2.4.tar.gz"
sha256 = "a73343c3093e5cdc50d9377997c3815b878fd110bf6511c2c7759f2afb90f5a3"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "static"
[deps]
build = ["busybox", "make", "cmake"]
[build.phases]
# -fno-sanitize=undefined: mismo motivo que zlib/libarchive (UBSan de zig cc en el .a estático).
# WITH_GTEST/ZLIB_ENABLE_TESTS off: el sandbox no corre tests y gtest arrastraría C++.
# CMAKE_POSITION_INDEPENDENT_CODE: mismo argumento que el -fPIC de zlib (enlazable en .so).
configure = """
cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr \
-DZLIB_COMPAT=ON -DBUILD_SHARED_LIBS=OFF -DZLIB_ENABLE_TESTS=OFF -DWITH_GTEST=OFF \
-DCMAKE_POSITION_INDEPENDENT_CODE=ON \
-DCMAKE_C_FLAGS='-O2 -fno-sanitize=undefined'
"""
compile = "make -C build -j\"$(nproc)\""
install = "make -C build install DESTDIR=/out"