Files
Sergio e852f48491 takana etapa 5a: los comentarios de las 741 recetas
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash
movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los
ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no
hasheaban de antes).

El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza
con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una
fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL
también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en
hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de
TOML y no entra ahí.

Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales
dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
2026-09-09 19:23:26 +00:00

104 lines
7.1 KiB
TOML

# CPython 3.12.10 — dependencia de build del frente rust (variante b, SDD 11 §7.2b).
#
# El bootstrap de rust/LLVM corre scripts python3 (mrustc README: "python3, required for building llvm
# in rustc"). El toolchain Alpine lo trae como paquete; esta receta lo construye desde fuente para
# de-Alpinizar el camino de bootstrap de rust.
#
# python3 es una HERRAMIENTA del toolchain (corre scripts en build-time, no se enlaza en el 4/4): no
# necesita casar byte-a-byte con el de Alpine, sólo interpretar igual. Build vainilla, sin patches.
#
# CPython usa autotools (./configure). zlib viene de recipes/zlib.toml (deps.build → materialize en
# /usr); --without-ensurepip evita la red (pip), --disable-test-modules acorta el build (no se necesita
# el test-suite). Enlace dinámico: el intérprete linkea libpython/libc; estático no aporta a una
# herramienta de build-time y CPython estático es frágil. El sandbox exporta CC="zig cc -mcpu=baseline".
#
# CC=gcc/CXX=g++ (NO zig): igual que cmake, el intérprete `_bootstrap_python` compilado con `zig cc`
# SEGFAULTEA al correr (paso de "freeze modules" del build) — zig 0.16 miscompila binarios musl
# grandes (un hello-world dinámico zig sí corre; cmake y python no). Alpine compila python con gcc; el
# toolchain trae gcc/g++ nativos y funcionales en el sandbox. Es herramienta, no input del 4/4 ⇒ el
# compilador da igual mientras el intérprete corra. Con gcc, -Wdate-time ni siquiera molesta (gcc SÍ
# honra SOURCE_DATE_EPOCH para silenciarlo); se deja CFLAGS=-Wno-error=date-time por robustez.
name = "python3"
version = "3.12.10"
license = "Python-2.0"
[source]
tarball = "https://www.python.org/ftp/python/3.12.10/Python-3.12.10.tgz"
sha256 = "15d9c623abfd2165fe816ea1fb385d6ed8cf3c664661ab357f1782e3036a6dac"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "dynamic"
# zig 0.13.0 (NO gcc): con zig 0.14+ el intérprete `_bootstrap_python` SEGFAULTEA en "freeze modules"
# (regresión 0.14 en C/musl, misma clase que flex). 0.13.0 la esquiva ⇒ gcc deja de hacer falta.
# CFLAGS=-Wno-error=date-time se conserva: clang (zig cc) NO silencia -Wdate-time vía SOURCE_DATE_EPOCH.
zig_version = "0.13.0"
[deps]
# ⚠ DEP DE EJECUCIÓN (2026-09-06). Este artefacto sale con `NEEDED libreadline.so.8` y hasta hoy
# ningún artefacto del cierre publicaba ese soname: la `readline` del catálogo es `--disable-shared`.
# En el rootfs hidratado se resolvía contra el sysroot Alpine DEL LAB — que en la máquina de
# desarrollo está y en la distro no. Lo venía reportando `scripts/vigia-sonames.py` en los cuatro
# perfiles. `runtime` NO entra en el ArtifactHash, así que esto NO re-hashea: cambia la CLAUSURA.
# Las CUATRO que `python3` pide por soname y que el cierre no publicaba (lo reporta
# `scripts/vigia-sonames.py`): readline para el REPL, y sqlite/lzma/bz2 para los módulos `sqlite3`,
# `lzma` y `bz2` de la stdlib, que se cargan por `dlopen` y por eso no rompen el arranque sino un
# `import` — un fallo que aparece lejos y no menciona a python.
runtime = ["readline-shared", "sqlite-shared", "xz-shared", "bzip2-shared"]
# `libffi` NO es opcional aunque el build no falle sin él: sin libffi el `configure` de CPython
# construye un intérprete SIN el módulo `_ctypes`, y lo hace en SILENCIO — sella un python3 que
# arranca perfectamente y revienta más tarde, en otra receta, con
# `ModuleNotFoundError: No module named '_ctypes'` (destapado 2026-08-11 en gjs y en el build de
# mozjs). **310 recetas dependen de python3**, así que el fallo no se parece a su causa ni de lejos.
#
# Por qué aparece AHORA: el rootfs del lab trae `libffi` (runtime) pero NO sus headers — no hay
# `libffi-dev` en el lock. El artefacto viejo de python3 sí tenía `_ctypes` porque el rootfs de
# entonces los traía, y el cache-hit lo mantuvo congelado hasta que el corpus se re-hasheó entero.
# Mismo patrón que `make`/`--disable-load`: reconstruir destapa lo que la caché sostenía.
#
# El arreglo va en `[deps]`, NUNCA engordando el rootfs: `recipes/libffi.toml` instala los headers
# y el `.pc`, y `pkgconf` (ya declarado) los encuentra en la capa overlay.
#
# NO es sólo libffi. CPython omite EN SILENCIO cada módulo opcional cuyos headers no encuentra, y el
# rootfs del lab trae los runtime pero casi ningún `-dev` (5 de 92 paquetes). Sin esta lista salen
# intérpretes mutilados que arrancan bien: `_curses` faltaba además de `_ctypes` (gdm, 2026-08-11).
# El corpus tiene receta propia para todas, así que declararlas es además de-Alpinizar.
#
# ✅ `openssl-threads` SÍ va (2026-08-27) — y con él este python3 TRAE `ssl`.
#
# Antes decía acá que era imposible sin tocar la receta de openssl. Lo que faltaba era la causa real:
# **el `no-threads` no venía de openssl, venía de `link = "static"`**. `takana-build/src/lib.rs:285`
# inyecta `LDFLAGS=-static`, y el `Configure` de openssl (línea 1514) hace
# `disable('static','pic','threads')` en cuanto ve `-static` en LDFLAGS. Por eso el `OPENSSL_THREADS`
# no aparecía y CPython abortaba con «Python requires thread-safe OpenSSL».
#
# `recipes/openssl-threads.toml` es la MISMA receta con `link = "dynamic"` (sigue con `no-shared`,
# o sea sigue emitiendo `.a`). Se usa una VARIANTE y no se toca `recipes/openssl.toml` porque de la
# canónica cuelgan los CUATRO kernels (linux, linux-generic, linux-metal, linux-metal-dual) y su
# reproducción bit a bit es un resultado cerrado: moverle el hash la invalidaría.
#
# ⚠ `ssl` entra además en la asserción del install de abajo. Sin eso, el día que vuelva a romperse
# se sellaría un python3 mudo otra vez — que es exactamente cómo esto estuvo escondido meses.
#
# ⚠ Y NO se pueden añadir todas: CPython construye sus módulos opcionales como `.so` COMPARTIDOS, y
# las `.a` del corpus NO son PIC ⇒ `sqlite`/`bzip2`/`xz`/`readline`/`expat` fallan al enlazar con
# «relocation R_X86_64_64 cannot be used against local symbol; recompile with -fPIC» (probado
# 2026-08-11 con `_lzma`). Es la familia del `.a` no-PIC ya conocida en este repo. ⇒ este python3
# NO trae `sqlite3`, `bz2`, `lzma` ni `readline`. Ninguna receta del corpus los necesita para
# construir; habilitarlos pide recetas PIC de esas libs, que es un frente aparte.
# Se declara sólo lo que arregla un fallo MEDIDO: libffi (_ctypes) y ncurses (_curses).
build = ["zlib", "pkgconf", "openssl-threads"]
[build.phases]
configure = "./configure --prefix=/usr --without-ensurepip --disable-test-modules --with-ensurepip=no CFLAGS=\"-Wno-error=date-time\""
compile = "make -j\"$(nproc)\""
# El `install` VERIFICA los módulos opcionales, no sólo copia. Es el guardián del fallo silencioso:
# `configure` omite un módulo sin fallar, `make` termina 0 y el artefacto se sella mutilado — el
# error aparece días después en otra receta (`ModuleNotFoundError`) y no se parece a su causa.
# Importarlos aquí convierte eso en un fallo de build, en la receta correcta y en el momento correcto.
# Se usa el intérprete recién instalado en /out, no el del rootfs, o no probaría nada.
install = '''make install DESTDIR=/out && \
LD_LIBRARY_PATH=/out/usr/lib /out/usr/bin/python3 -c "import ssl, _ctypes, _curses, readline, sqlite3, bz2, lzma, zlib, pyexpat; print('modulos opcionales: OK')"'''