Files
hammer/recipes/python3.toml
T
sergioandClaude Opus 4.8 d99ed58850 harkaq: revertir busybox (era runtime base, rompía builds) + coordinar el §3 con Fable 5
DOS ERRORES MÍOS, uno de dirección y otro técnico, los dos en la cosecha automática:

1. DIRECCIÓN: declaró `busybox` como dep en 29 recetas — cuando la Etapa C lo está
   ELIMINANDO (USERLAND_COMPONENTS=[uutils,findutils,…], ya cerrada; joyas-reusables
   §5 lo confirma: "uutils… Ubuntu 25.10 los envía como default"). Estaba cimentando
   la deuda que el roadmap borra.
2. TÉCNICO: busybox YA está en el runtime base de harkaq (`ro /bin/busybox`, `ro
   /bin/sh` — el sandbox corre `sh -c` y /bin/sh→/bin/busybox). Es CONTRATO, no dep.
   Declararlo apila el busybox de hammer sobre el de Alpine y ROMPE el build:
   binutils daba "cannot run C compiled programs" en las DOS máquinas. Verificado:
   sin busybox declarado, binutils construye (b3:f4507dcd…). Y la cadena se explica:
   binutils roto ⇒ zlib (que lo declara) tampoco construía.

Auditoría de la cosecha (diff real, no la línea completa del +): añadió sólo 5 deps
distintas — make ×73, busybox ×29, perl ×8, pkgconf ×5, binutils ×1. Sólo busybox
estaba mal; las otras 4 son deps reales medidas. busybox revertido de 30 recetas
(queda sólo en busybox.toml, pre-existente).

Es el mismo error que ya me habían señalado con otro disfraz: MEDIR BIEN Y ACCIONAR
MAL. harkaq midió correcto (el build toca /bin/busybox: es el shell); la acción
correcta no era declararlo sino reconocerlo como contrato.

+ COORDINACIÓN del §3 con Fable 5 (mismo diseño, tareas repartidas):
  - Su lección casper queda CONFIRMADA y REFORZADA: la clausura de build no sólo le
    FALTAN las clases del mundo (offline) — también le SOBRA casi todo (headers, gcc).
    Medido: htop (estático, 0 NEEDED) no toca NADA al correr ⇒ política = su binario.
  - Su "la clase viaja como campo de la ConcesionCapacidad, sin formato nuevo" se
    cumple LITERALMENTE: lo firmado es format::Permisos = u32 bitmask en 36 bytes
    canónicos (Ring 0) ⇒ las clases SON los bits. La cripto no se toca.
  - Diseño unificado: frontera (clases, u32, declaradas) + detalle (paths, Landlock,
    medidos). D3 rige en ambos.
  - Reparto: clases→Fable 5; medición/harness→Opus. CONTACTO: runtime-policy.sh ahora
    emite la CLASE detectada (/etc/resolv.conf→dns, /etc/ssl/certs→tls-certs, …), no
    sólo el path: la medición alimenta la tabla, la tabla decide el bit.
  - Consumidor esperando: plan-jaula-juegos F1 (Steam que no puede leer ~/.ssh).

+ juez.sh (§10): nombre único por corrida (con uno fijo pega en caché ⇒ falso
  "sin evidencia"). Fue el juez quien destapó todo esto en su primera corrida real.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-16 23:14:19 -04:00

45 lines
2.4 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"
[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]
build = ["zlib", "pkgconf"]
[build.phases]
configure = "./configure --prefix=/usr --without-ensurepip --disable-test-modules --with-ensurepip=no CFLAGS=\"-Wno-error=date-time\""
compile = "make -j\"$(nproc)\""
install = "make install DESTDIR=/out"