SergioandClaude Opus 5
dbfb7d492b
Mudando `api.sergio.gioser.net` a la caja de produccion, `takana qorpa provision` aborto:
Error: no encuentro harkaq-exec en /root/.cache/harkaq/harkaq-exec
construilo: gcc -O1 -Wall -static -o ... scripts/harkaq/harkaq-exec.c
El mensaje es bueno y la receta que propone es IMPOSIBLE de seguir: en una caja instalada no hay
gcc, ni `scripts/`, ni arbol de desarrollo. El binario solo existia como un `gcc` a mano en la
cache de `$HOME` del hub, o sea que la jaula del ADR 0015 funcionaba unicamente en la maquina
donde alguien la habia compilado.
Y su companero estaba igual, medido en `build-state.json`: `bwrap` sellado desde hace meses con
`"perfiles": []` — CERO perfiles. Lo invocan por PATH tanto `qorpa` como el sandbox de
`takana build` (`takana-build/src/sandbox.rs`), asi que **ninguna imagen de takana podia enjaular
nada, ni construir**. Es [[subcomando-sin-driver]] un piso mas abajo: el CLI que los llama viaja
en todas las imagenes y sus herramientas en ninguna.
Tres piezas:
· `recipes/harkaq-exec.toml` — nueva. Estatico musl, `b3:cd34954f...`, 269 K. El pin va al commit
que toco la FUENTE (`1d9ddcee`, 2026-09-03) y no a HEAD: el `.c` no se mueve desde entonces y el
repo commitea cada media hora por el cron de la cosecha — pinear HEAD re-hashearia la receta cada
media hora sin que su fuente cambiara. La fuente sigue en `scripts/harkaq/` y no en un arbol
propio porque tres scripts la compilan desde ahi y dos copias divergen en silencio.
· `qorpa.rs` — busca el binario tambien en `/usr/bin`, que es de donde sale en cualquier maquina
que no sea el hub. El orden es HARKAQ_BIN (lo que el operador declara) → arbol de desarrollo →
paquete, para que un cambio en la jaula se pruebe sin instalar nada. Y el error ya nombra las
dos salidas, no solo la del hub.
· `targets.toml` — los dos en `perfil.base`.
Medido en la caja de produccion tras aplicarlos: `bwrap 0.11.0` + harkaq-exec responden, y
`takana qorpa provision sergioh-api` instala python 3.14.7 con pacman DENTRO de la jaula
(`[harkaq] jaula puesta: ABI 9`). El 3.14 no es casualidad: el venv de gioser trae extensiones
`cpython-314-...-gnu.so`, asi que la imagen de Arch pineada da la misma serie.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
58 lines
3.2 KiB
TOML
58 lines
3.2 KiB
TOML
# harkaq-exec — el último eslabón de la jaula, empaquetado como receta.
|
|
#
|
|
# POR QUÉ EXISTE (descubierto el 2026-09-15, mudando `api.sergio.gioser.net` a la caja nueva).
|
|
# `takana qorpa provision` murió en la caja de producción con:
|
|
#
|
|
# Error: no encuentro harkaq-exec en /root/.cache/harkaq/harkaq-exec — la instancia NO va a
|
|
# correr enjaulada y eso no se hace en silencio.
|
|
# construilo: gcc -O1 -Wall -static -o … scripts/harkaq/harkaq-exec.c
|
|
#
|
|
# El mensaje es bueno y la receta que propone es imposible: **en una caja instalada no hay gcc, ni
|
|
# árbol de desarrollo, ni `scripts/`**. El binario sólo existía como un `gcc` a mano en el hub, en
|
|
# una caché de `$HOME` — o sea que la jaula del ADR 0015 funcionaba únicamente en la máquina donde
|
|
# alguien la había compilado. Es [[subcomando-sin-driver]] otra vez, un piso más abajo: `takana
|
|
# qorpa` viaja en TODAS las imágenes y su herramienta en NINGUNA.
|
|
#
|
|
# ⚠ Y su compañero `bwrap` estaba igual: sellado desde hace meses, declarado en CERO perfiles
|
|
# (`"perfiles": []` en `build-state.json`) — y lo invocan por PATH tanto `qorpa` como el sandbox de
|
|
# `takana build` (`takana-build/src/sandbox.rs`). Los dos entran a `perfil.base` en la misma unidad
|
|
# de trabajo: una imagen de takana que no puede enjaular no puede ni construir.
|
|
#
|
|
# ── EL PIN VA AL COMMIT QUE TOCÓ LA FUENTE, no a HEAD ─────────────────────────────────────────────
|
|
# `scripts/harkaq/harkaq-exec.c` no cambia desde el 2026-09-03; el repo, cada media hora (el cron de
|
|
# la cosecha commitea el estado del grafo). Pinear HEAD re-hashearía esta receta cada media hora sin
|
|
# que su fuente se moviera. El commit de abajo es el último que tocó el `.c` y su `.h`.
|
|
#
|
|
# La fuente vive en `scripts/` y no en un árbol propio de la receta a propósito: `harkaq-run.sh`,
|
|
# `harkaq-farm-setup.sh` y `q2-runtime-base.sh` la compilan desde ahí, y dos copias del mismo `.c`
|
|
# divergen en silencio. El precio es subir el `commit` cuando la jaula cambie — el mismo que paga
|
|
# `recipes/takana.toml`.
|
|
|
|
name = "harkaq-exec"
|
|
version = "0.0.1"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
# El repo del propio takana; la URL es sólo locator y no entra en `hash_inputs` (ADR 0013 §1).
|
|
repo = "https://git.gioser.net/sergio/takana.git"
|
|
commit = "1d9ddcee373fa58f3a311cf5444b2d30040046ab"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
# Estático **obligatorio**, no por costumbre: harkaq-exec corre DENTRO del rootfs del sandbox, donde
|
|
# no hay cargador dinámico que valga (lo dice el encabezado del propio `.c`).
|
|
link = "static"
|
|
|
|
[build.phases]
|
|
# El árbol es el repo entero, sin sistema de build que detectar: las tres fases van a mano.
|
|
configure = "true"
|
|
# `-mcpu=baseline` por reproducibilidad independiente de la CPU del builder, como el resto del lab
|
|
# (y ver [[cgo-sin-baseline-sigill]]: hornear la ISA del que compila es un SIGILL en otra caja).
|
|
# Los headers de seccomp/landlock salen del rootfs del lab; `harkaq-uapi.h` está al lado del `.c`.
|
|
compile = "zig cc -mcpu=baseline -static -O1 -Wall -o harkaq-exec scripts/harkaq/harkaq-exec.c"
|
|
install = "mkdir -p /out/usr/bin && cp harkaq-exec /out/usr/bin/harkaq-exec"
|
|
|
|
[deps]
|
|
build = ["binutils"]
|