Muestra del lote Rust #2 cerrada: eza/lsd/just/tealdeer/choose construyen+corren
(static-musl) -> 5 al corpus validado + repo firmado (71 paquetes). ouch FALLA por
MSRV (pide rustc 1.93.0; sandbox topa en 1.91.1, techo conocido) -> queda staged.
build-yield muestra = 5/6 = 83% (1 solo fallo, y por MSRV, no por toolchain musl).
Flujo staging->corpus en accion: del lote Rust #2, los 3 primeros de la muestra
construyen+corren (ELF static-musl) -> promovidos incoming/->recipes/ y publicados
al repo firmado (69 paquetes). eza (ls moderno), lsd (ls+iconos), just (task runner).
Quedan 24 staged; se promueven a medida que la granja los construye.
Respuesta a "asi de a poquitos no cubrimos miles": el grueso va por LOTE, no a mano.
import-batch sobre tandas/cli-rust-2.txt (30 CLIs) -> yield import 29/30 en ~2 min
(nix=27, alpine=2; solo rargs fallo). pin-recipes anclo 26 tag->SHA. A esta tasa,
1000 paquetes ~ 1-2h de import desatendido.
ESTRUCTURA: recipes/incoming/ = COLA DE STAGING (el import vuelca en masa); recipes/
= corpus VALIDADO (construye+corre) del que build-repo.sh arma el repo firmado. La
granja/CI promueve incoming->recipes a medida que cada uno construye. Asi el corpus
mantiene su invariante sin frenar la importacion masiva.
27 recetas staged (todas parsean): eza lsd zellij starship just delta difftastic
gitui broot choose dog gping grex jless miniserve navi onefetch pastel pueue tealdeer
watchexec xsv bandwhich fclones mcfly viu ouch.
Build-yield (muestra en curso): eza OK, lsd OK (static-musl ELF). El resto se ancla
progresivamente. Las recetas a mano de las tandas previas (libs/gueto/lib+bin) fueron
para endurecer el importador en los casos duros; el largo tail navega por este lote.
nano 9.0: editor de terminal real, segundo consumidor de ncurses tras htop/less
(API curses widec). deps.build=[ncurses, linux-headers]; gueto gcc; sale static-pie
y corre. Redondea el userland con un editor de verdad. --disable-libmagic/-nls
(libmagic/gettext no en corpus, sólo autodetección/i18n). Publicado al repo (66).
Pueblo el userland de ARRANQUE real del distro con los helpers del init arje
(hermanos de arje-zero PID 1), patrón Cargo commit 9967b02c --locked estático:
- arje-getty-stub: agetty mínimo (ciclo de vida del login).
- arje-net-bring-up: oneshot que sube el enlace de la primera interfaz (corre: eth0 up).
- arje-installer: copia kernel+initramfs+seed a una ESP / arma USB GPT booteable.
- arje-absorb: traduce la config de otro init a una Semilla brahman (migración a arje).
Los 4 construyen+corren estáticos, publicados al repo firmado (65 paquetes).
GOTCHA recetas Cargo con lib+bin: arje-installer tiene [lib]+[[bin]]; el lab hace
'cargo rustc -p X -- <crt-static>' y cargo exige UN solo target tras '--' => agregar
'--bin <name>' a flags. arje-loader DESCARTADO: bootloader EFI (no_std, target uefi),
no static-musl userland.
Sigo poblando con apps propias de tawasuyu (patrón Cargo, commit 9967b02c --locked,
estático zig-cc, bin==package, reusan el árbol fuente):
- tinkuy-sim: simulador de dinámica molecular Lennard-Jones; corre 200 steps de 343
partículas con reporte BLAKE3 por step (cómputo puro determinista).
- mirada-ctl: control CLI del compositor mirada (estilo swaymsg/hyprctl, cliente IPC).
Ambos construyen+corren estáticos, publicados al repo firmado (61 paquetes).
uya-cli DESCARTADO: requiere la lib de audio alsa (alsa-sys/libasound C), no en el
corpus -> fuera de alcance hasta portar esa lib. Texture honesta: no toda app
tawasuyu es static-musl pura; las que tocan audio/GPU/p2p necesitan libs o no aplican.
Poblar el catálogo no es sólo CLI de terceros (Rust/C): tambien las APPS PROPIAS
del monorepo tawasuyu. dominium-cli es el runner headless del simulador físico de
dominium — patrón Cargo igual que arje-zero/llimphi-counter: source = tawasuyu a
commit fijado 9967b02c (con Cargo.lock committeado -> build --locked reproducible),
-p dominium-cli, estático zig-cc. bin==package (sin mismatch de workspace). Cómputo
puro (clap+serde+physics), sin GPU/red. Comparte commit con arje-zero -> reusa el
árbol fuente fetcheado.
Construye+corre: simulación de 100 ticks a 62k tps con métricas Gini/Moran.
Dogfood e2e: publicado al repo firmado (57 paq) -> install --require-signed ->
trusted -> reproduce desde fuente (hash casa) -> hidrata -> corre.
htop 3.5.1 ejerce la API curses real de ncurses (ventanas/teclado/colores widec),
no sólo el lookup de terminfo de less. deps.build=[ncurses, linux-headers]; sale
static-pie y corre (--version). Valida ncurses como lib TUI completa del corpus.
Ajustes sobre el import: quito lm-sensors (opcional, no en corpus) con
--disable-sensors; gueto gcc (zig-cc miscompila); auto-detecta ncursesw widec.
ncurses es la lib fundacional del userland TUI (destraba less/htop/top/nano/ncdu).
La importo de Alpine pero RE-ANCLADA al release ESTABLE 6.5 de GNU (pineable; el
import traia el snapshot semanal de invisible-mirror, no reproducible) y
SIMPLIFICADA a estatico widec (--without-shared --enable-widec), sin el binding
C++ (rompe contra el libstdc++ del host) ni la maraña .so del APKBUILD. El install
crea los symlinks libncurses/libtinfo/libcurses -> libncursesw para que un
consumidor que enlaza -lncurses/-ltinfo resuelva.
less 704 es el primer CONSUMIDOR que lo valida: deps.build=[ncurses], enlaza
-ltinfo, sale static-pie y pagina. Confirma ncurses usable como lib del corpus.
Notas: gcc del lab = Alpine musl gcc (x86_64-alpine-linux-musl, no glibc) -> mezcla
limpia con objetos zig-cc/musl. gueto gcc en ambos (el build de ncurses corre tic
para generar terminfo; zig-cc lo miscompila). Corpus 53->55.
jq estaba bloqueado por su lib de regex faltante. Importo oniguruma de Alpine
(lib build-dep como zlib/libcap: el lab apila libonig.a + oniguruma.pc en /usr)
y cableo jq con deps.build=[oniguruma].
Fricciones C resueltas, documentadas en las recetas:
- oniguruma: el archive/ de GitHub no trae configure (Alpine corre autoreconf,
pide autoconf/automake/libtool ausentes del corpus); uso el tarball de RELEASE
que sí trae configure pregenerado -> sin autoreconf.
- jq: gueto gcc (zig-cc lo miscompila -> segfault, igual que file). Estático vía
libtool requiere -all-static en make Y en make install (libtool relinkea al
instalar y descartaba el flag -> binario dinámico). Ahora jq sale static-pie.
- el import emitia sed como build-dep; es herramienta del sandbox, no lib -> la quito.
Ambos construyen+corren: jq-1.8.1 static-pie evalua JSON. Corpus 51->53.
BUILD-YIELD C MEDIDO (no especulacion): 6/8 de la tanda construyen+corren como ELF
estatico musl. Promovidos: file 5.47, gawk 5.3.2, gzip 1.14, tar 1.35, tree 2.3.2,
which 2.23 (+ sus parches musl de Alpine).
Texture honesta del tier-2 C (la friccion que el tier-1 Rust no tiene):
- gawk/tar/tree/which: zig-cc directo, sin tocar nada.
- file: zig-cc MISCOMPILA -> el `file` recien hecho segfaultea generando magic.mgc
(mismo sintoma que binutils). Escape compiler="gcc" -> construye.
- gzip: (1) configure "C compiler cannot create executables" con zig-cc -> compiler="gcc";
(2) luego el install fallaba por `local i;` de la package() de Alpine.
- jq (oniguruma), sed (perl): NO build-friction sino dep faltante en el corpus
(completitud) -> quedan pendientes hasta importar esas libs.
Fix generico que destrabo gzip (y futuros): el importador Alpine ENVUELVE el cuerpo de
build()/package() en una funcion shell. abuild los corre COMO funciones (donde `local`
es valido); el lab corre la fase plana bajo sh -c, donde `local` fuera de funcion es
error. Envolver restaura el contexto de abuild sin tocar el sandbox ni las fases planas
del corpus (solo lo importado). test translate_wraps_body_in_function_for_local.
Confirmado: los 6 binarios corren (--version). file/gzip llevan compiler="gcc" en su
receta (escape declarativo, gueto conocido).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Arranca el escalado del catálogo con la tanda tier-1 (tandas/cli-rust.txt) por el
pipeline completo: import-batch (escalera) → pin (tag→SHA) → build (medir) → promover.
BUILD-YIELD MEDIDO (no especulación): 11/12 de la tanda construyen+corren como ELF
estático musl en el lab. Los 11 promovidos al corpus:
bat 0.26.1, bottom 0.12.3, dust, fd 10.4.2, hexyl, hyperfine, procs, sd, tokei,
xh 0.25.3 (rustls, no openssl), zoxide.
(ripgrep ya estaba en el corpus con su patch jemalloc; no se duplica.)
El primer corte dio 8/12: los 4 con deps fallaban por buildInputs espurias de nix
(bat→zlib, fd→jemalloc, ripgrep→pcre2, xh→openssl) — backends C que el build Rust por
defecto NO usa. Arreglado en el importador (commit anterior): re-importados bat/fd/xh
SIN [deps] → los 3 construyen (bat 372s, fd 251s, xh 413s). Sube 8/12 → 11/12.
Verificado: los binarios CORREN (fd/bat/xh --version), estáticos musl stripped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Poblar una ESP FAT sin privilegios (ni loop-mount root) para el arranque UEFI
exige mtools (mformat/mcopy/mmd), ausente en el host. Pieza simétrica a xorriso
para la rama EFI. zig 0.13.0, estático musl, --without-x, sin deps (iconv
built-in de musl). Sella d7892990.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El host no trae xorriso (y grub-mkrescue lo exige) ⇒ se construye desde fuente
con hammer para fabricar el medio ISO. Tarball GNU (libburn+libisofs+libisoburn
en un árbol), zig 0.13.0, 100% estático musl, todas las libs opcionales
desactivadas (readline/edit/acl/xattr/zlib/bz2/cdio) ⇒ binario autocontenido sin
deps. Sella b63d1a64, corre standalone (xorriso 1.5.8 + personalidad xorrisofs
mkisofs-compatible). Mismo patrón -static/-target musl de openssh.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bump del commit pinneado de c78a0ada → 06184e43 (rama tawasuyu selfhost/arje-zero-attest-
lockfile = c78a0ada + Cargo.lock del workspace force-committeado). Sin lock, tawasuyu lo
gitignora y `cargo vendor` corre SIN --locked ⇒ las deps derivan ⇒ el gated arje-zero (y el
of_tree del producto atestado) no es reproducible. Con el lock, el build es
`cargo rustc --release --locked --offline` ⇒ bit-reproducible. Espeja el patrón del núcleo
(arje-zero.toml @ selfhost/arje-zero-lockfile 9967b02c).
Lock regenerado sobre c78a0ada reusando los pins de main (1 línea de diff ⇒ versiones
MSRV ≤ 1.91.1 del sandbox preservadas). Rebuild --locked validado en host: compila limpio
(418 crates, sin error MSRV), sella arje-zero-attest d1a6f5c7 + arje-packager 2267b9b0;
producto atestado d35a9c09 BOOTEA en QEMU (gate anclado a rootkey soberana, 3 ✓, SSH OK).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cierra la integración canónica firmada de I4 (decisión del usuario): la mitad de
arje (gate) + la mitad de hammer (firma) acopladas con la cripto real de
arje-attest/agora — NO el manifiesto plano de /ente/attest.json.
tawasuyu (pusheado, commit c78a0ada en main): `arje-packager --seed-out` emite el
seed FIRMADO standalone (el gate attest_gate.rs ya estaba en main).
hammer:
- recipes/arje-packager.toml: el firmador (build-time tool, static musl, corre en
el host). GOTCHA: lib+bin + monorepo virtual ⇒ flags `-p ... --bin ...`.
- recipes/arje-zero-attest.toml: arje-zero CON gate, variante SÓLO de producto
(commit c78a0ada). El arje-zero del núcleo (9967b02c) NO se toca ⇒ of_tree
baseline (9adefb82/7fa6cb4e) BLINDADO. Separación Mecanismo/Política.
- scripts/attest-boot-test.sh: valida E2E sobre una copia del product-rootfs
(override del PID1 por el gated + seed firmado por arje-packager + boot QEMU).
Validado in-VM (rootkey fija ⇒ firmas Ed25519 deterministas):
- ÍNTEGRO: gate atesta arje-zero+hammerd+busybox ✓ (politica=Halt) → servicios
arriba → SSH OK.
- TAMPER (1 byte en hammerd tras firmar): "atestación ✗ binario no atestado" →
"ARRANQUE FALLIDO ... Halt — abortando antes de incarnar" → shell de rescate,
SIN SSH. La integridad comprometida NO levanta el entorno.
Pendiente (estructurar bien): cablear esto en hammer-bootstrap product() (firmar
+ hidratar el gated automáticamente) y reproducibilidad (Cargo.lock committeado
en tawasuyu para el gated). El mecanismo ya está probado.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
OpenSSH 10.3p1 desde fuente — LA excepción C del userland Rust (no hay
servidor SSH Rust de producción). Provee sshd+ssh+ssh-keygen+scp/sftp.
deps.build = zlib + openssl (libcrypto.a/libz.a estáticas), zig 0.13.0.
Binarios 100% estáticos musl. Tres gotchas zig-cc/-static resueltos:
- -pie de OpenSSH ANULA -static (sale dinámico) -> --without-hardening
desactiva el PIE automático del "toolchain hardening".
- zig cc -static -lz, con .a y .so en /usr/lib, PREFIERE el libz.so de
Alpine (NEEDED libz.so.1) -> sed CHANNELLIBS a -l:libz.a/-l:libcrypto.a
(archivo estático exacto).
- zig cc NATIVO (sin -target) -static deja libc.so dinámico igual ->
CC con -target x86_64-linux-musl usa el musl embebido de zig.
Validado en host: todos los binarios statically linked y corren
(ssh -V, sshd -V, ssh-keygen genera ed25519 con cripto real). Handshake
loopback en bwrap llega a preauth (accept TCP + IPC privsep monitor/child
+ parse hostkey OK); sólo lo frena chroot("/var/empty") por falta de
CAP_SYS_CHROOT en el userns anidado -> el E2E completo va a la card de
servicio in-VM (root real). Runtime: usuario sshd + /var/empty + host
keys via ssh-keygen -A.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Construye `-p netup` del workspace hammer (commit 6886f81) con deps vendoreadas
--offline, static musl vía zig cc. A diferencia de uutils/findutils/ripgrep
(adopción de binario maduro), netup es código hammer-propio (patrón hammerd).
Construye+sella: b3:9189d86…-netup, ELF static sin interpreter.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ripgrep 14.1.1 (tag, commit 4649aa97) como receta Cargo, mismo patrón que
uutils/findutils/diffutils. Es su propio workspace ⇒ sin patch [workspace].
Estático musl, zig cc sólo linker; MSRV 1.72 ≤ 1.91.1.
ripgrep-no-jemalloc.patch: ripgrep mete jemallocator incondicional en musl64,
pero jemalloc-sys compila C (autotools) y embebe rutas de OUT_DIR ⇒ rompería la
reproducibilidad bit-a-bit del lab. El patch lo quita (dep Cargo.toml + stanzas
Cargo.lock + global_allocator en main.rs) ⇒ build 100% Rust, hermético, con el
allocator de musl. PCRE2 ya es opt-in ⇒ regex puro, sin C.
Construye+sella+corre: ELF static sin interpreter, `ripgrep 14.1.1
features:-pcre2`, búsqueda recursiva/glob OK. `rg` no es flag-compatible con
POSIX grep ⇒ no se symlinkea a grep; convive con el grep interino.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
B1 — kernel con disco+FS: linux.toml añade VIRTIO_BLK/VIRTIO_PCI/VIRTIO_NET/EXT4_FS
built-in (=y, sin módulos), aditivo al path initramfs. B2 — infra de disco:
- scripts/disk-image.sh: empaqueta un rootfs como imagen ext4 booteable con
`mke2fs -d` bajo `unshare -r` (archivos root-owned sin sudo, como el cpio
--owner=root:root; evita EACCES en el copy-up de overlay del rebuild).
- scripts/drive-rebuild.py: modo DISK= ⇒ QEMU monta la imagen como virtio /dev/vda
y el kernel arranca con `root=/dev/vda rw rdinit=/sbin/init` — sin initramfs.
Verificado en QEMU/KVM: el kernel monta /dev/vda ext4 como root REAL y arje-zero
arranca como PID 1 DIRECTO, sin el hack /init+switch_root (el muro pivot_root del
path initramfs desaparece por construcción: / ya es un mount pivotable).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
uutils/findutils 0.9.1 --bin xargs (mismo crate/commit/patch que findutils.toml).
Construye+sella+corre: xargs 0.9.1, ELF estático, -n1/-I{}/pipe OK.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
uutils/findutils 0.9.1 (tag 17d852c4, --bin find, static musl). Construye+sella
+corre: find (Rust) 0.9.1, ELF estático sin interpreter, -name/-type/-maxdepth OK.
onig_sys (C vía cc-rs) linkea con el wrapper zig-cc.
Gotcha general de toda receta Cargo de un crate suelto: hammer copia la fuente a
work/sources/ dentro del repo hammer (un workspace), así cargo vendor la absorbe y
aborta. Fix: findutils-workspace.patch inyecta un [workspace] vacío. coreutils lo
esquiva por ser ya raíz de workspace.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
zig 0.13 compila los host-tools del kernel (wrapper que traduce el depfile
-Wp,-MMD,PATH → -MMD -MF PATH; cache de zig deshabilitado), pero el target
choca con la traducción de flags x86 de zig cc (-mtune=generic, -march=x86-64).
gcc se retiene SOLO para {kernel, cmake}; el resto del userland C es gcc-free
vía zig 0.13. Futuro intento limpio: make LLVM=1 con el clang que zig empaqueta.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mata gcc para 5 de las 7 recetas que lo forzaban, vía una escotilla nueva:
- hammer-core/hammer-build: campo `[build].zig_version` por receta. Cuando se
fija, el lab resuelve ese zig (hermano del por defecto, `zig-x86_64-linux-<v>`)
en vez del global, y entra al hash SÓLO si está presente (baseline 9adefb82
intacto). `effective_zig_dir` lo aplica en ensure_layout + Sandbox.
- Causa: BISECT con oráculo flex (reproducido sólo vía lab: musl DINÁMICO) — el
miscompile es una REGRESIÓN de zig 0.14; 0.13.0 compila limpio, 0.14/0.15/0.16
fallan. Es C/musl-dinámico, NO afecta C++.
- Flip a zig_version="0.13.0" (quitando CC=gcc): flex, openssl, elfutils,
binutils, python3. Verificados: `as` 2.45.1 corre, python3 3.12.10 corre
(deepfreeze OK), libcrypto/libelf sellan. Todas son tools (no inputs del 4/4).
cmake queda en gcc: su segfault es C++ (libc++/musl), bug distinto que 0.13 NO
arregla (ni con -static). El kernel queda pendiente de verificar.
Tests: hammer-core/hammer-build verdes.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Primera pieza del userland Rust-nativo (Etapa C): adopta uutils/coreutils 0.9.0
(MIT) como receta Cargo — el patrón de hammerd/arje-zero, no recompila C ni se
escribe de cero. Multicall static-musl (12 MB) + 79 symlinks por applet
(ls/cp/cat…), drop-in de busybox/GNU coreutils.
- Esquiva el miscompile de zig por construcción: codegen rustc/LLVM, zig cc sólo
como linker.
- `--bin coreutils` (no `-p`): el paquete tiene lib+bin y `cargo rustc -- flags`
exige un único target (gotcha vs arje-zero).
- Install custom (sólo esa fase; configure/compile siguen auto-Cargo) crea los
symlinks con `coreutils --list`.
Construido + sellado + verificado funcional (ls/cat/echo vía dispatch argv0).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
tools/objtool del kernel enlaza -lelf (libelf+gelf.h); venía de `apk add
elfutils-dev`. Ahora recipes/elfutils.toml construye SÓLO libelf (0.194, lo que
objtool necesita — no libdw/libdwfl/src) desde fuente, wired como deps.build del
kernel. Con esto NINGÚN build-dep del kernel viene de Alpine: el camino del
kernel es 100% hammer-from-source.
elfutils es glibc-céntrico; musl no trae <error.h>/<argp.h>/<libintl.h>/fts/
obstack/rawmemchr. En vez del parche completo de Alpine, shims mínimos en compat/
(vía CPPFLAGS/-include): error.h y argp.h (sólo los usan color.c/printversion.c,
cuyos .o van en libeu.a pero objtool NO referencia ⇒ basta que compilen); libintl
no-op (+ --disable-nls); rawmemchr inline; y libargp/libfts/libobstack.a stubs
para pasar los AC_SEARCH_LIBS del configure (símbolos inertes para libelf). CC=gcc.
bootstrap-devfs.sh: elfutils-dev fuera del NEEDED. Validado: purgué elfutils-dev
del devfs, rebuild → objtool linkea el libelf hammer (sin gelf.h Alpine), y
HAMMER_KERNEL=1 verify → ✓ REPRODUCIBLE bit a bit, DRIVER_RC=0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
certs/extract-cert (host-tool del kernel, lo arrastra CONFIG_SYSTEM_DATA_
VERIFICATION=y) enlaza -lcrypto; venía de `apk add openssl-dev`. Ahora
recipes/openssl.toml (OpenSSL 3.5.4, CC=gcc, libcrypto/libssl ESTÁTICAS vía
no-shared) lo construye desde fuente, wired como deps.build del kernel
(materializado como capa overlay en /usr: libcrypto.a + headers + pkgconfig).
bootstrap-devfs.sh: openssl-dev fuera del NEEDED. El runtime libcrypto3/libssl3
(que curl/git necesitan) lo sigue trayendo Alpine aparte — no es openssl-dev.
Validado: purgué openssl-dev del devfs, rebuild del kernel → certs/extract-cert
compila con el libcrypto hammer (sin Alpine openssl), y HAMMER_KERNEL=1 verify →
✓ REPRODUCIBLE bit a bit, DRIVER_RC=0. libelf (objtool) sigue como bootstrap-lib
apk (elfutils-en-musl es el difícil; de-Alpinizable luego).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El defconfig compilaba un PC completo (i915/DRM, sound, USB, media, wireless,
infiniband, BT, HID...) — nada de eso lo usa la VM headless del selfhost-verify
(consola serie + e1000 + initramfs + bwrap). Desactivo esos subsistemas + ATA/
SCSI/NVME/MD (sin disco, todo initramfs) + filesystems de disco innecesarios.
Verificado: HAMMER_KERNEL=1 con el kernel lean → ✓ REPRODUCIBLE bit a bit,
DRIVER_RC=0. Build baja de ~35min a ~14min.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Hito: el kernel hammer-built 6.16.12 BOOTEA la VM del selfhost-verify:
console ttyS0, arje-zero (PID1) levanta, hammerd corre, y la red e1000 vendorea
los crates OK (cargo vendor completo). El compile in-VM falla sólo en el sandbox
bwrap: "pivot_root: Invalid argument" (--tmp-overlay /) ⇒ DRIVER_RC=1.
Iteración de config (vs el kernel Arch/Artix que sí corre bwrap):
- +FANOTIFY +FANOTIFY_ACCESS_PERMISSIONS: hammerd lo usa para el watcher del
diario (sin él: WARN ENOSYS, no fatal — pero ahora queda funcional).
- +OVERLAY_FS_{REDIRECT_DIR,INDEX,XINO_AUTO,METACOPY}: el defconfig los deja off,
el working los tiene =y; hipótesis para el pivot_root del overlay en userns.
Estado: el kernel compila+bootea+inicia+red; falta el pivot del sandbox.
Pendiente tras esto: optimizar config (defconfig es grande, build ~35min).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Avance del frente kernel: el build pasó objtool y certs.
- bootstrap-devfs.sh: +flex +bison +elfutils-dev +openssl-dev al NEEDED.
* elfutils-dev (libelf/gelf.h): objtool lo exige — en x86_64 las mitigaciones
seleccionan CONFIG_OBJTOOL aunque se use frame-pointer unwinder.
* openssl-dev: el host-tool certs/extract-cert lo #incluye — el defconfig
fuerza CONFIG_SYSTEM_DATA_VERIFICATION=y vía KEYS←NFS/integrity/dns_resolver
(no apagable sin desarmar media config).
Ambas son build-libs de arranque (status g++/zlib-dev), SEGURAS para el of_tree
del self-host: hammerd no usa openssl (Cargo.lock limpio) y arje-zero va
preseeded/cacheado (no se reconstruye). De-Alpinizables luego con
recipes/{elfutils,openssl}.toml.
- linux.toml: quité los -d de keyring que no pegan (olddefconfig/syncconfig los
revierten por el select-chain); openssl resuelve extract-cert. Comentario
actualizado con el diagnóstico.
Estado: build compila el kernel completo (objtool+certs OK); defconfig es grande
(GPU/wireless), pendiente el bzImage + boot-test + optimización de config.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Arranque del último frente de soberanía del bootstrap: construir el kernel que
bootea la VM del selfhost-verify (hoy importado pinned). Versión 6.16.12
(coherente con recipes/linux-headers.toml).
Estado: defconfig + ajustes monolíticos (e1000/overlay/userns =y, BTF/firma
off, frame-pointer unwinder). deps.build=[flex,bison,m4] (materializados como
capa overlay en /usr). flex/bison YA funcionan: kconfig parsea y asm-offsets se
genera. BLOQUEO confirmado: tools/objtool necesita libelf (gelf.h) — en x86_64
las mitigaciones seleccionan CONFIG_OBJTOOL aunque se use frame-pointer.
PRÓXIMO PASO: recipes/elfutils.toml (libelf) como dep.build → completa el
bzImage. Luego: KERNEL=<bzImage> ./scripts/selfhost-verify.sh debe dar
✓ REPRODUCIBLE (iterar la config hasta que el builder bootee).
CC=gcc/HOSTCC=gcc (zig miscompila binarios grandes; el kernel es el mayor).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Primeros prerequisitos para construir el kernel Linux desde fuente: el kbuild
usa flex (lexer de kconfig) y bison (parser LALR de kconfig/dtc), ausentes del
toolchain Alpine base. Herramientas de build-time, no inputs del 4/4.
- flex 2.6.4: CC=gcc (zig miscompila el stage1flex que procesa su propio scan.l
→ "unrecognized rule"; mismo gotcha que binutils/python/cmake). link=dynamic.
- bison 3.8.2: zig cc estático (tool chica, corre bien). Necesita m4 en runtime
(recipes/m4.toml) y sus skeletons en /usr/share/bison (BISON_PKGDATADIR).
Validados: flex 2.6.4 / bison 3.8.2 corren y procesan specs (.l→1736 líneas,
.y→1270 líneas).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Última pieza del toolchain hammer-from-source (variante b). Misma versión que
Alpine 3.23.4 (binutils-2.45.1-r0). INERTE para el of_tree del 4/4: el lab usa
`zig cc` (ensamblador interno + lld + zig ar/ranlib/objcopy), así que las
recetas del 4/4 no invocan el ld/as de binutils ⇒ el swap no cambia
of_tree(stage1'). Existe para completar la provenance (builder 100%
reconstruible desde fuente), sin flag SWAP_* dedicado (vía SWAPS= como
patch/m4/pkgconf).
CC=gcc/CXX=g++ (NO zig), igual que python3/cmake: zig 0.16 miscompila binarios
musl grandes ⇒ binutils con zig cc segfaultea al correr (as: "Internal error
(Segmentation fault)"). gcc nativo (como Alpine) los produce funcionales.
link=dynamic: libtool descarta el -static del exe final; gcc dinámico enlaza
contra el musl del toolchain, idéntico al binutils de Alpine.
Validado: ld/as/ar/strip/objcopy/nm/objdump/ranlib/readelf reportan 2.45.1 y
pasan smoke funcional (as ensambla, ar archiva, nm lee símbolos, strip reduce,
objdump desensambla).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bump del commit fijado 35ec8ef9 → 9967b02c (rama tawasuyu selfhost/arje-zero-lockfile =
35ec8ef9 + Cargo.lock del workspace committeado). Causa raíz del drift del baseline: el
monorepo tawasuyu gitignora Cargo.lock ⇒ el fetch de hammer vendoreaba SIN --locked ⇒ las
versiones de deps derivaban en el tiempo ⇒ arje-zero (y of_tree(stage1)) no reproducible
entre corridas (musl/busybox/hammerd sí, por tener lock o ser C). Con el lock fijo, el
fetch detecta Cargo.lock y vendorea --locked ⇒ build bit-reproducible.
Verificado: el fetch resuelve el commit nuevo (mirror --all) y vendorea SIN el warn de
"sin Cargo.lock". El input-hash de la receta cambia ⇒ nuevo baseline estable (≠ 9adefb82,
que queda como ancla histórica pre-lock).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El rebuild de python3 con zig cc pasó el date-time pero el intérprete
`_bootstrap_python` (zig cc) SEGFAULTEÓ en el paso de "freeze modules" —
mismo fallo que cmake: zig 0.16 miscompila binarios musl grandes (un
hello-world dinámico zig sí corre). Fix idéntico: CC=gcc/CXX=g++ en las
fases (gcc nativo del toolchain, como compila Alpine). Con gcc además
-Wdate-time deja de molestar (gcc honra SOURCE_DATE_EPOCH).
NOTA: rebuild gcc EN CURSO (fase compile, ya pasó configure) al commitear;
aún no sellado. zlib (f3ddad6) validado.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Primer intento de ambas falló; correcciones tras diagnóstico con probes aislados:
- cmake: el cmake mínimo que `./bootstrap` compila con `zig c++` SEGFAULTEA al
correr ("Problem while running initial CMake") — interacción libc++/musl de
zig. Fix: forzar CC=gcc/CXX=g++ en las fases (Alpine compila cmake con gcc;
el toolchain ya trae gcc/g++, nativos y funcionales en el sandbox).
- python3: Modules/getbuildinfo.c usa __DATE__/__TIME__ y la build habilita
-Wdate-time; zig (clang) lo promueve a ERROR. Probé que SOURCE_DATE_EPOCH=1
(que el sandbox ya exporta) fija el VALOR a 1970-01-01 (determinista) pero
clang NO silencia -Wdate-time vía SDE (eso es sólo-GCC). Fix:
CFLAGS="-Wno-error=date-time" — degrada a warning, valor sigue determinista.
NOTA: ambos rebuilds estaban EN CURSO al commitear (aún no sellados en store);
si fallan otra vez, commit de seguimiento. zlib (f3ddad6) sí validado.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dependencias de build que rustc usa para construir su LLVM bundled (mrustc
README: cmake ≥3.4.3 + python3). De-Alpinizan el camino de bootstrap de rust;
hoy satisfechas por apk de arranque.
- cmake 3.31.6: build vía ./bootstrap (zig cc/c++), enlace dinámico, OpenSSL OFF.
- python3 3.12.10: ./configure autotools (zig cc), deps.build=[zlib],
--without-ensurepip --disable-test-modules, enlace dinámico.
NOTA: ambos están EN VALIDACIÓN — sus builds estaban en fase `configure` (sin
errores, zig cc aceptado) al commitear, todavía NO sellados en store. Si la
compilación/instalación falla, requerirán ajuste en un commit de seguimiento.
zlib (f3ddad6) sí está validado y sellado.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
zlib 1.3.1 estática (zig cc) — primera dependencia de build de la cadena rust
construida desde fuente. mrustc enlaza -lz y el toolchain Alpine sólo trae el
.so runtime (sin zlib.h/libz.a/zlib.pc); esta receta sella libz.a + headers +
zlib.pc en /usr (mismo patrón que libcap → materialize_build_deps los overlaya
en el sandbox), reemplazando el zlib-dev de arranque cuando se cablee como
deps.build de la receta mrustc/rust.
Validada: build+sello OK (store cf716586…-zlib). configure de zlib es a mano
(rechaza flags autotools) ⇒ fases override como musl (./configure --static).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Más de-Alpinización del builder (variante b, SDD 11 §7.2b): recetas para construir desde fuente
tres build-tools del toolchain que hoy vienen de Alpine.
- recipes/patch.toml (GNU patch 2.8): lo invoca apply_patches (hammer-build/fetch.rs) cuando una
receta trae source.patches, p.ej. el overlay de linux-headers.
- recipes/m4.toml (GNU m4 1.4.20): base de la cadena autotools.
- recipes/pkgconf.toml (pkgconf 2.5.1): lee los .pc que materialize_build_deps deja en el sandbox.
Las 3 estáticas musl con zig cc (AutoconfReady), validadas: corren, versión correcta y funcionales
(patch aplica, m4 expande, pkgconf resuelve). El 4/4 mínimo no las invoca ⇒ sin flag SWAP_* dedicado
(swapeables con el escape SWAPS="name=hash:rel"); avanzan "builder reconstruible al completo".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Quinta pieza del toolchain hammer-from-source (variante b, SDD 11 §7.2b): GNU coreutils 9.8
(cp/mkdir/ln/chmod/mv/install…), que el `make install` de musl y busybox invocan.
- recipes/coreutils.toml: empaquetada multicall (--enable-single-binary), mismo layout que el
paquete de Alpine (un /bin/coreutils + ~100 symlinks que despachan por argv[0]). Estática musl
con zig cc, vainilla sin patches (es tool del toolchain, no input compilado del 4/4).
- scripts/selfhost-verify.sh: SWAP_COREUTILS=1 construye la receta y monta el único binario sobre
/toolchain/bin/coreutils — los symlinks del toolchain (cp/mkdir/install/…) lo siguen, un solo --swap.
Bisección host fuerte: con hammer-coreutils pisando el de Alpine (trap-restore en .dev-fs), musl Y
busybox rebuildearon BYTE-IDÉNTICO (57b66a2e, 56664d70). Pendiente: corrida in-VM acumulando swaps.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cuarta pieza del toolchain hammer-from-source (variante b, SDD 11 §7.2b): bubblewrap, el
sandbox del propio lab. Binario estático ⇒ swap de archivo sobre /toolchain/usr/bin/bwrap.
Como herramienta del toolchain (no input del 4/4) no necesita casar byte-a-byte con Alpine,
sólo aislar igual.
Tres piezas:
- recipes/libcap.toml (2.78): dep obligatoria de bwrap; el toolchain Alpine no trae el -dev
(libcap.a / sys/capability.h). Build estático musl con zig cc, sin patches (es tool, no input).
- materialización de build-deps (hammer-build): deps.build ahora se CONSTRUYE recursivamente
(build() llama build() por cada dep) y cada artefacto sellado se apila como capa --overlay-src
bajo el rootfs del sandbox, dejando usr/{include,lib,lib/pkgconfig} en /usr. pkgconf y zig cc
las hallan sin plumbing de flags. Recetas sin deps: sandbox byte-igual (baseline intacto).
Tests nuevos: no_deps_emits_single_overlay_src, deps_stack_as_overlay_layers_under_rootfs.
- recipes/bwrap.toml (0.11.0): el toolchain no trae meson/ninja/python, así que bypaseamos meson
compilando los 4 .c de bubblewrap directo con zig cc (+config.h trivial). deps.build=["libcap"].
Validación host fuerte: hammer-bwrap es estático, corre --version y sandboxea, y musl rebuildeó
BYTE-IDÉNTICO usándolo de sandbox (bisección). Expuesto con SWAP_BWRAP=1. Tests verdes.
Pendiente: corrida in-VM acumulando swaps para el sello ✓ REPRODUCIBLE.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tercera pieza del toolchain hammer-from-source (variante b, SDD 11 §7.2b): los headers
UAPI del kernel 6.16.12 que musl/busybox #include, hoy tomados del paquete linux-headers
de Alpine.
- recipes/linux-headers.toml: `make headers` (no `headers_install` — su rsync final falta
en el toolchain hermético) + unifdef vía HOSTCC=zig cc; .tar.gz (busybox-tar lo
descomprime sin xz). Sella los 13 subdirs kernel-owned de usr/include.
- assemble_builder: el swap ahora soporta rel_path de DIRECTORIO (reemplaza el árbol
entero: remove + copy), no sólo binarios. Cubierto por test nuevo
(builder_rootfs_swaps_toolchain_header_tree_from_source, incl. borrado de huérfanos).
- recipes/linux-headers-alpine-compat.patch: el paquete de Alpine no es el `make headers`
crudo. Aporta content-pinned 5 archivos que difieren de la salida vainilla; 3 son
REQUERIDOS (scsi/{scsi,scsi_ioctl,sg}.h — legacy userspace, NO UAPI) porque el applet
`eject` de busybox los incluye y sin ellos no compila. install los pisa sobre /out y
limpia el junk (.cmd/Makefile/headers_check.pl/drm) que `cp -a` arrastra.
- scripts/selfhost-verify.sh: SWAP_LINUX_HEADERS=1 construye la receta y emite un --swap
por subdir kernel-owned (auto-derivado del artefacto sellado).
Criterio de éxito fuerte: `diff -r` del header-tree de hammer contra el de Alpine = VACÍO
⇒ el toolchain swapeado es byte-idéntico al baseline ⇒ reproducibilidad por construcción.
Ensamblado end-to-end en host OK (13 swaps, musl bits/sys intactos). 133 tests verdes.
Pendiente: corrida in-VM para el sello ✓ REPRODUCIBLE.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Arranca el auto-alojamiento *puro* (SDD 11 §7.2b): reemplazar una a una las
piezas que el builder toma de Alpine (/toolchain) por recetas hammer desde
fuente, con Stage 2 reverificando cada paso.
make es la pieza base de toda receta autotools. Build estático musl con zig cc
(mismo camino que grep: tarball release con configure → AutoconfReady), sellado
b3:fbad44ac… y reproducible bit-a-bit (dos builds en stores distintos ⇒ árbol
idéntico). Pendiente: swap al /toolchain del builder + Stage 2.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El rebuild in-rootfs de Stage 2 cazó un no-determinismo real: stage1 reconstruido
en la VM divergía del host (of_tree host=b3:94a4f1… vs VM=b3:ab615b…), aun con el
seal hash idéntico (el seal es of_inputs: mismo key ≠ mismos bytes).
Diagnóstico (control en el host, sin VM): un rebuild de hammerd en el host es
byte-idéntico al cacheado, así que la receta es determinista host-a-host y el cache
no está stale. La divergencia es del entorno de build de la VM: `zig cc` default a
`-mcpu=native` y hornea la ISA del builder en el C/asm de los build-scripts (blake3,
curve25519-dalek). El host tiene SHA-NI+AVX2; `-cpu Broadwell` (VM bajo TCG) no tiene
SHA-NI ⇒ codegen distinto ⇒ bytes distintos ⇒ of_tree distinto. Misma raíz que el
SIGILL de AVX del runbook §7 (binarios al CPU del builder, no a un baseline genérico).
Fix: `-mcpu=baseline` en TODOS los sitios zig cc — CC/CXX del sandbox, los dos
wrappers Cargo (.hammer-zig-cc) y CC/HOSTCC de la receta de busybox. Las rutas SIMD
del runtime (blake3/sha2) son asm con dispatch en runtime: siguen presentes. Bonus:
cierra el AVX/SIGILL del §7 (corre en qemu64 sin -cpu Broadwell).
Validado en el host: con baseline hammerd cambia de bytes (1672448 vs 1677584 —
confirma que el default no era baseline) y los 3 componentes rebuildan limpio
(stage1 rc=0). Nueva referencia CPU-independiente of_tree(stage1-baseline)=
b3:4408e44e2ec51c3769deffcd64dd1f6c2010d414418937c3fa7930a0ded3f845. Runbook §8c
documenta el cruce del muro Rust-offline (cargo vendor por la NIC, hammerd sellado
in-VM en 74m35s) y este diagnóstico+fix.
Nota (plan C.2): el flag de CPU no entra en of_inputs ⇒ cambio de toolchain/flags da
cache-hit con bytes viejos; cerrar ese "pin de toolchain al hash" es trabajo aparte.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La verificación de reproducibilidad de Stage 2 (dos builds + diff de bytes) probó
que musl reconstruye bit-idéntico pero busybox NO, y cazó dos no-determinismos:
1. Config interactiva: tras editar .config, silentoldconfig prompea por opciones
NEW leyendo stdin → set de applets variable (build no-determinista y flaky).
Fix en busybox.toml: `yes '' | make oldconfig` (defaults, determinista;
1.36.1 no tiene olddefconfig).
2. Headers UAPI del kernel: el config determinista habilita console-tools, que
exige linux/kd.h (zig no la bundlea). Fix: linux-headers en bootstrap-devfs.sh
(zig cc nativo la halla en /usr/include).
Con ambos, musl y busybox reconstruyen bit-idéntico. Runbook §8b documenta la
verificación y deja pendiente: reproducibilidad de los componentes Rust y el
rebuild dentro de un builder rootfs (auto-alojamiento pleno).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Tercera iteración del fix de la corrida real (runbook §8). +crt-static (y
relocation-model=static) en RUSTFLAGS rompen los proc-macros en build nativo:
RUSTFLAGS alcanza a las deps, y un proc-macro es un dylib PIC que no puede ser
estático ("cannot produce proc-macro for clap_derive ... crate types").
Fix: pasar los flags de codegen del binario por `cargo rustc --release … -- <flags>`,
que los aplica SÓLO a la crate top-level, dejando proc-macros/deps intactos. Así el
binario final es crt-static + relocation-model=static (AUTOCONTENIDO y ET_EXEC sin
interpreter, como busybox: sin libc.so, sin loader, sin soname). El linker (zig cc)
sigue por RUSTFLAGS. musl queda --disable-shared (no se necesita loader).
Validado por unit tests; la corrida real rebuildea hammerd/arje-zero crt-static.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cierra el último bloqueo del boot que la corrida en QEMU destapó (runbook §8):
arje-zero/hammerd buildeaban DINÁMICOS contra musl (el rust de Alpine es dinámico
por defecto) → DT_NEEDED libc.musl-x86_64.so.1, y nuestro libc.so (musl shared con
zig cc) no exporta memcpy/memset/… → el loader falla y el init muere.
Fix golden-path: para link=static, RUSTFLAGS ahora fuerza
-C target-feature=+crt-static -C relocation-model=static
⇒ binarios AUTOCONTENIDOS (musl dentro), ET_EXEC sin interpreter, como busybox:
sin libc.so, sin loader, sin el soname de Alpine. musl vuelve a --disable-shared
(no se necesita el loader). Boot en QEMU: usar -cpu Broadwell (el qemu64 default no
tiene el AVX que zig emite).
Validado por la corrida real: los 4 componentes buildan y el rootfs se sella; el
kernel arranca el initramfs y ejecuta arje-zero como PID 1. Falta rebuildear
hammerd/arje-zero con crt-static para cerrar el boot (cache-bust + rebuild).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Primera ejecución del runbook en el host. El userland C builda end-to-end; el
camino Rust queda bloqueado por una decisión de toolchain. Hallazgos verificados:
recipes/busybox.toml — tres incompatibilidades GNU-toolchain ↔ zig, resueltas:
- gcc hardcodeado (CC/HOSTCC = gcc con `=` ignora el env): pasar CC='zig cc'
HOSTCC='zig cc' en línea de comando de make
- flags GNU-ld que zig cc valida y rechaza (--warn-common, -Map, --verbose):
quitarlos de scripts/trylink con sed
Con esto musl 1.2.5 y busybox 1.36.1 compilan, linkean y se sellan.
scripts/bootstrap-devfs.sh — añade rust+cargo al rootfs (las recetas Cargo
corren cargo en el sandbox), con CAVEAT: el rust de Alpine es
x86_64-alpine-linux-musl pero BuildSys::Cargo pide x86_64-unknown-linux-musl
(no instalado, sin rustup) → bloquea hammerd/arje-zero. Decisión de toolchain
abierta (plan C.2).
docs/runbooks/stage1-vm-boot.md §8 — bitácora con la tabla de etapas, los fixes
y las opciones para resolver el triple Rust.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
sergio
