sergio/takana
> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…
bump(takana): las 5 recetas de nuestro propio repo saltan juntas a c0ded9ac
1# harkaq-exec — el último eslabón de la jaula, empaquetado como receta.
2#
3# POR QUÉ EXISTE (descubierto el 2026-09-15, mudando `api.sergio.gioser.net` a la caja nueva).
4# `takana qorpa provision` murió en la caja de producción con:
5#
6# Error: no encuentro harkaq-exec en /root/.cache/harkaq/harkaq-exec — la instancia NO va a
7# correr enjaulada y eso no se hace en silencio.
8# construilo: gcc -O1 -Wall -static -o … scripts/harkaq/harkaq-exec.c
9#
10# El mensaje es bueno y la receta que propone es imposible: **en una caja instalada no hay gcc, ni
11# árbol de desarrollo, ni `scripts/`**. El binario sólo existía como un `gcc` a mano en el hub, en
12# una caché de `$HOME` — o sea que la jaula del ADR 0015 funcionaba únicamente en la máquina donde
13# alguien la había compilado. Es [[subcomando-sin-driver]] otra vez, un piso más abajo: `takana
14# qorpa` viaja en TODAS las imágenes y su herramienta en NINGUNA.
15#
16# ⚠ Y su compañero `bwrap` estaba igual: sellado desde hace meses, declarado en CERO perfiles
17# (`"perfiles": []` en `build-state.json`) — y lo invocan por PATH tanto `qorpa` como el sandbox de
18# `takana build` (`takana-build/src/sandbox.rs`). Los dos entran a `perfil.base` en la misma unidad
19# de trabajo: una imagen de takana que no puede enjaular no puede ni construir.
20#
21# ── EL PIN VA AL COMMIT QUE TOCÓ LA FUENTE, no a HEAD ─────────────────────────────────────────────
22# `scripts/harkaq/harkaq-exec.c` no cambia desde el 2026-09-03; el repo, cada media hora (el cron de
23# la cosecha commitea el estado del grafo). Pinear HEAD re-hashearía esta receta cada media hora sin
24# que su fuente se moviera. El commit de abajo es el último que tocó el `.c` y su `.h`.
25#
26# La fuente vive en `scripts/` y no en un árbol propio de la receta a propósito: `harkaq-run.sh`,
27# `harkaq-farm-setup.sh` y `q2-runtime-base.sh` la compilan desde ahí, y dos copias del mismo `.c`
28# divergen en silencio. El precio es subir el `commit` cuando la jaula cambie — el mismo que paga
29# `recipes/takana.toml`.
30
31name = "harkaq-exec"
32version = "0.0.1"
33license = "MIT"
34
35[source]
36# El repo del propio takana; la URL es sólo locator y no entra en `hash_inputs` (ADR 0013 §1).
37repo = "https://git.gioser.net/sergio/takana.git"
38commit = "c0ded9acb285ee6c7c6b191590c9635a6242a274"
39
40[build]
41compiler = "zig-cc"
42target = "x86_64-linux-musl"
43# Estático **obligatorio**, no por costumbre: harkaq-exec corre DENTRO del rootfs del sandbox, donde
44# no hay cargador dinámico que valga (lo dice el encabezado del propio `.c`).
45link = "static"
46
47[build.phases]
48# El árbol es el repo entero, sin sistema de build que detectar: las tres fases van a mano.
49configure = "true"
50# `-mcpu=baseline` por reproducibilidad independiente de la CPU del builder, como el resto del lab
51# (y ver [[cgo-sin-baseline-sigill]]: hornear la ISA del que compila es un SIGILL en otra caja).
52# Los headers de seccomp/landlock salen del rootfs del lab; `harkaq-uapi.h` está al lado del `.c`.
53compile = "zig cc -mcpu=baseline -static -O1 -Wall -o harkaq-exec scripts/harkaq/harkaq-exec.c"
54install = "mkdir -p /out/usr/bin && cp harkaq-exec /out/usr/bin/harkaq-exec"
55
56[deps]
57build = ["binutils"]