El repo temporalio/cli tiene 3 mains bajo cmd/ (gen-commands, gen-docs,
temporal); detect_go_main elegía gen-commands ⇒ binario equivocado, quedó
en needs-review. Fix: flags=["./cmd/temporal"] apunta al CLI real (verificado
vía API de GitHub en el commit fijado). El binario se llama `temporal`, así
que agrego el alias temporal-cli→temporal al gate de harvest-go.sh (mismo
patrón que opentofu→tofu). Vuelve a recipes/incoming-go para que el worker
lo selle y la cosecha lo promueva.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
build-farm.sh asumía 'sin colisión entre recetas distintas', falso para deps transitivas
compartidas no selladas: dos consumidores (p.ej. libadwaita/gtksourceview) construyen gtk4 a
la vez en el mismo sources/gtk4-<sha>/output ⇒ 'Some other Meson process is already using this
build directory'. Fase 1b: tras el pool paralelo, reintenta EN SERIE los fallos con firma de
colisión — la dep ya la selló el ganador ⇒ cache-hit y compila. Un pase basta (cada build
arrastra sus deps). Sólo reintenta colisiones, no MSRV/dep-faltante reales.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El watchdog de disco purgaba work/sources/* protegiendo solo árboles bind-montados
por bwrap (prot.1) o cuyo nombre coincide con la receta en vuelo (prot.2). Una dep
transitiva (cairo bajo pango/gtk4) se extrae host-side ANTES del bwrap y con nombre
que no coincide con la receta ⇒ el rm -rf competía con el tar y dejaba el árbol a
medias: 'Cannot mkdir' durante la extracción, luego 'Directory not empty' para
siempre (falla rápido antes de bwrap, nunca se recupera). Prot.3: no purgar árboles
modificados hace <2 min (extrayéndose ahora); los fríos se purgan y re-extraen limpio.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Dos bugs del promote de build-farm.sh, hallados al cosechar incoming-clib:
1. mv movía el .toml pero NO sus .patch (quedaban en la cola) ⇒ toda receta
parcheada fallaba el pack ("leyendo patch ...: No such file or directory").
Ahora mueve los patches referenciados junto al .toml.
2. mv sobrescribía a ciegas una receta canónica de recipes/ con una variante
homónima de la cola (p.ej. curl 8.11 mínimo-para-appstream pisando el
curl 8.20 full). Se agrega guarda: si ya existe recipes/<n>.toml, NO se
promueve la variante (queda staged para triage) ni se re-publica.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La 1ª corrida promovió+FIRMÓ binarios equivocados que pasaban el smoke por solo 'correr':
katana/naabu→functional-test, gosec→gosecutil, buf→protoc-gen-buf-lint (detect_go_main eligió un
main helper). El gate ahora localiza el binario cuyo nombre == receta (o alias conocido tofu/mc/
nats/dlv/flux/ct/kubeseal/node_exporter/...); si instaló otro → a needs-review-weekend con el motivo,
NO se firma. Lección eksctl aplicada al gate.
- farm-worker-loop.sh: construye QUEUES='recipes/incoming recipes/incoming-go' (en serie por vuelta;
la cola Go aislada se muele 24/7 sin pisar el incoming/ del otro agente).
- scripts/farm/harvest-go.sh: cosecha determinista sin IA (cron del laptop). Baja el store sellado,
y por cada receta SELLADA (cache-hit bajo timeout, NO compila en el hub) hace SMOKE-TEST del binario
(existe + corre version/--help sin panic/segfault) antes de promover+firmar. Lo que falla el smoke va
a tandas/needs-review-weekend/ para el lunes. add explícito (nunca -A), push con reintento.
vault (go-15) falló en 'go mod vendor' con '~/.cache/go-build/...: no such file': durante el compile
de telegraf el disco cruzó DISK_HIGH, el watchdog corrió 'go clean -cache', y el vendor de vault (que
usa esa cache) arrancó en la ventana siguiente sin ficheros. El guard anterior solo miraba 'go mod
vendor' activo en ese instante; ahora difiere la purga si hay cualquier 'hammer build' en vuelo.
go-13 (dnscontrol/lazysql, árboles de deps Go enormes) destapó otra race del watchdog: durante el
fetch/'go mod vendor'/resolve_phases (host-side, antes del bwrap) el árbol no está bind-montado ⇒ el
watchdog lo borraba a mitad del vendor → go.mod desaparecía → 'receta sin compile, heurística no
encontró build system'. Ahora además protege work/sources/<name>-* si <name> tiene un proceso
'hammer build' activo (cubre toda la vida del build, no solo la fase sandbox).
- mesa/wayland/wayland-protocols/libdrm/seatd/samurai/meson + patches: batch C de gráficos previo
que jamás se mandó al worker, arrastrado en incoming/. Parqueado en tandas/hold-nongo/.
- syncthing: build especial (genera la GUI embebida 'auto.Assets' vía go generate/build.go) ⇒
diferida a staged-fallidos con el motivo. Quedan 18 go-12 limpias en la cola.
go-12 (terraform/k8s) destapó la race: con árboles de deps de varios GB en paralelo, el disco
cruza DISK_HIGH y el watchdog corría 'go clean -modcache' a mitad de los 'go mod vendor' en vuelo
(.partial: no such file) ⇒ 5 recetas no convergían. Ahora difiere la purga del modcache si hay un
vendor de host activo (la purga de work/sources ya libera lo grueso y es segura). syncthing: main
real en ./cmd/syncthing (la raíz tiene build-constraints que excluyen todo).
El 'go mod vendor' acumula GOMODCACHE (~/go/pkg/mod) sin tope: una tanda Go
grande lo llevo a 31G y lleno el disco de 80G -> I/O-wait disparo el load a 23
(cuello real, no CPU/RAM). El watchdog ahora purga 'go clean -modcache/-cache'
cuando el disco supera DISK_HIGH% (def 82). El vendor/ local de cada receta ya
tiene lo necesario; si pisa un vendor en curso, esa receta reintenta.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cierra la fragilidad manual del patron Go (path del main por receta). Ahora
importar Go es tan automatico como Rust: import -> pin -> build, sin tocar nada.
- lib.rs: BuildSys::Go (go.mod, prioritario sobre configure/make auxiliares que
traen muchos proyectos Go). resolve_phases deriva el compile generico:
'go install -trimpath -ldflags=-buildid=' del paquete main. install='true'
(go install ya deja en GOBIN=/out/usr/bin).
- detect_go_main(): detecta el dir del main por FILESYSTEM (no compila, evita
contaminarse con mains de ejemplo rotos en docs/scripts que rompen go list).
Heuristica raiz > cmd/<x> > menor profundidad; excluye vendor/docs/test/etc.
go install nombra el binario solo (cmd/mlr->mlr, raiz->modulo).
- nix_import.rs + nix-import.sh: detecta is_go (vendorHash de buildGoModule),
emite deps.build=['go'] sin phases (BuildSys::Go las deriva).
- tests: go_mod_wins_over_configure, detect_go_main_picks_cmd_over_docs.
Validado end-to-end: miller (cmd/mlr->mlr, esquiva docs rotos), amfora (raiz),
duf (import->pin->build 100% automatico, binario estatico que corre).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cierra el muro del frente Go (vendoring) replicando el patron de Rust:
vendorear in-situ en el fetch (host, con red), no tarball-al-mirror.
- fetch.rs: vendor_go_deps() analoga a vendor_cargo_deps — corre go mod vendor
en el host si hay go.mod; el sandbox compila offline con -mod=vendor.
- lib.rs: engancha vendor_go_deps tras los patches cuando el arbol trae go.mod
(sin BuildSys::Go; el compile lo fija la receta en build.phases).
- bootstrap-devfs.sh: instala el toolchain go del host (1.26.4, estatico) en
.dev-fs/tools/go + symlink en ~/.cargo/bin (PATH del worker via .cargo/env).
- amfora: PRIMERA receta Go del corpus. Build end-to-end validado (repo+commit
-> fetch vendorea -> sandbox offline -> binario estatico que corre, Amfora
v1.11.0). REPRODUCIBLE bit-a-bit: dos stores independientes dan of_tree
b3:9ec1d5fe (trimpath + buildid= en el compile). Promovida al repo (282).
Quedan 12 recetas Go en tandas/staged-2026-06-26/ (cheat/dnsx/croc/dyff/csvtk/
git-town/miller/jump/gron/qrcp/walk/gtrash): mecanico, copiar el patron de
amfora ajustando el nombre del binario.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
scripts/product-image-from-repo.sh cierra el lazo Etapa F+G entero:
base product-rootfs (arje-zero PID1 + musl/busybox) → hidrata userland rico vía
`hammer install --require-signed` del repo firmado → imagen GRUB auto-booteable →
boot en QEMU + handshake SSH que CORRE los tools del repo.
VALIDADO e2e: booteó, arje-zero PID1, hammerd+netup+sshd, y por SSH corrieron
bat 0.26.1 / fd 10.4.2 / jq 1.8.1 / eza — userland farmeado, servido desde el
repo firmado, no del bootstrap hardcodeado. 240 bins en /usr/bin (base+repo).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cierra el lazo Etapa F+G: el userland del producto se arma vía `hammer install
--repo --prefix --require-signed` desde el repo firmado, no del bootstrap
hardcodeado. scripts/product-userland-from-repo.sh hidrata un set curado (13+
tools validados estáticos del repo).
Dos bugs reales del path install/pack encontrados+arreglados:
1. pack derivaba target_bin=/usr/bin/{name}; para paquetes con binario≠nombre
(ripgrep→rg, repgrep→rgr) quedaba mal y el sanity-check de install fallaba.
Ahora pack lo deriva del flag `--bin <X>` de la receta Cargo.
2. La reproducción del source_patch derivaba el NOMBRE de la receta del
target_bin ⇒ "rg" ≠ "ripgrep" del corpus ⇒ no cache-hit ⇒ rebuild + dup en
el store (find_by_hash ambiguo). build_source_patch/run_apply ahora reciben
el nombre del paquete (install/bootstrap lo pasan; apply=None) ⇒ cache-hit
del artefacto del corpus, sin duplicar.
(El "EACCES" inicial era sólo --store ausente: DEFAULT_STORE=/store root-only.)
hammer-build 49/49 tests ok; ripgrep install validado e2e (rg hidratado).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tres frentes que aparecieron al provisionar un CCX13 (Ubuntu 24.04) de verdad:
- bootstrap-devfs §3b: el loader musl-256-keys ahora DETECTA la versión del
rootfs (apk db) en vez de hardcodear 1.2.5. Alpine edge avanzó a musl 1.2.6 ⇒
un loader 1.2.5 vs coreutils 1.2.6 da `renameat2: symbol not found` → chmod
roto en el sandbox → el wrapper zig-cc no queda +x → EACCES. case con sha de
1.2.5 y 1.2.6, die si aparece una nueva.
- vps-setup §2b: compila bubblewrap 0.11.2 si el de la distro no soporta
--overlay-src (Ubuntu 24.04 trae 0.9.0 sin overlayfs; el sandbox lo necesita).
- farm-sync: excluye /.scratch (44G de fuentes mrustc/rustc) + *.png/content*
del rsync al worker (casi copia 44G de más).
Smoke test en el VPS: builds compilan código real (pasan cc/chmod), rustc 2
cores al 93%, RAM holgada. Worker funcional.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Paraleliza el build a un/varios VPS sin exponer gitea ni la clave de firma.
Modelo: el laptop es el HUB (firma + gitea); el worker sólo construye la cola
incoming/ y sella al store local (PROMOTE=0). Reproducibilidad bit-a-bit +
content-addressing ⇒ el store del worker es byte-idéntico, se rsync-ea de vuelta
y el hash valida solo (no hay que confiar en el VPS).
- vps-setup.sh: provisiona Debian/Ubuntu (deps, userns p/bwrap, swap 16G,
rustup, build hammer, bootstrap-devfs rootfs Alpine edge, systemd unit).
- farm-worker-loop.sh: loop autónomo 24/7, PROMOTE=0, watchdog de disco
integrado; muele lo que haya sin esperar al hub.
- hammer-farm.service: systemd, JOBS=2 (CCX13 = 2 vCPU dedicado), Nice/idle-io.
- farm-sync.sh (hub): rsync código+cola arriba, store sellado abajo,
promote+firma+commit+push. Acceso único laptop->VPS por SSH.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diagnóstico cerrado: el reboot-probe probó que el kernel está VIVO en el metal del
usuario (se reinicia solo); la pantalla negra es porque el panel TigerLake se apaga al
pasar el kernel y solo i915 (driver Intel real) lo reenciende — efifb/simpledrm/earlyprintk
escriben a un fb muerto (validado: nomodeset tampoco). Era un recorte de más (i915 venía
-d del kernel QEMU). Fix = lo que toda distro normal trae:
- linux-metal.toml: -e DRM_I915 -e DRM_FBDEV_EMULATION (saca -d DRM_I915).
- metal-firmware.sh: inyecta i915/tgl_* (DMC/GuC/HuC, 1.3M) en /lib/firmware/i915.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Diagnóstico metal: con systemd-boot, earlyprintk=efi NO imprime NADA del kernel
(solo 'Loaded initrd MEDIA_GUID' + 'Measured initrd PCR 9' y cuelga) ⇒ el kernel
no llega ni a su consola temprana: hang en ExitBootServices o el decompresor.
- metal-usb-sdboot.sh: piso de 48MiB a la ESP (FAT32 -F exige ~33MiB; con initramfs
chico caía debajo y la firmware no leía el BOOTX64.EFI → 'Not Found').
- USB de bisección (work/hammer-tiny-usb.img, initramfs busybox 1.3MB): ✓ OVMF llega a
/init. Si en el metal del usuario ARRANCA a shell ⇒ el cuelgue era el initrd 100MB;
si TAMBIÉN cuelga ⇒ es el kernel/EBS (probar nokaslr/no5lvl).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El boot por EFI-stub DIRECTO se cuelga en el firmware del usuario tras 'Measured initrd
PCR 9' (quirk EFI_LOAD_OPTION del firmware + initrd 100MB por la firmware). Pivote:
- scripts/metal-usb-sdboot.sh: arma work/hammer-metal-usb.img (disco GPT+ESP FAT32) con
systemd-boot (binario del host, crutch de bringup) como BOOTX64.EFI + loader entry.
systemd-boot provee el initrd por LoadFile2 (esquiva el parseo de cmdline del firmware)
y permite EDITAR la cmdline en vivo (tecla 'e') ⇒ iterar sin recompilar 45min.
✓ VALIDADO OVMF: menú → 'Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID' → arje-zero PID1.
- linux-metal.toml: kernel diagnóstico — cmdline +earlyprintk=efi,keep +ignore_loglevel
+efi=novamap (ve el boot en pantalla post-ExitBootServices) y -DEBUG_WX (saca el trace).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
work/hammer-metal.iso (257M) bootea en OVMF por las dos vías como DISCO:
- virtio-disk y USB-storage(xhci): EFI-stub carga kernel+initrd de la ESP (GPT
isohybrid), cmdline horneado aplica, usbhid/cfg80211 init, arje-zero PID1, SIN panic.
- El '-cdrom' falla (El Torito EFI se trunca >32MB) pero es IRRELEVANTE: un USB es disco
⇒ la firmware lee la ESP por GPT. Confirmado el escenario real del pendrive.
Falta solo el hardware: quemar y bootear (Secure Boot OFF).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
scripts/hammer-banner.txt: icono ASCII cabeza-de-martillo rellena de '#' (el hash
content-addressed) + handle, wordmark 'hammer' (toilet pagga, estilo pixel-block que
rima con la cabeza de hashes) + acrónimo HAMMER + uso WiFi. metal-iso.sh lo copia a
/etc/motd ⇒ es lo primero que ves al loguear en consola. Reutilizable como base de
logo/wallpaper.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
La rama GRUB-EFI cuelga (bug GRUB 2.14 del host rolling, afecta a cualquier kernel).
Solución: bootear el kernel por su EFI-STUB directo, sin GRUB-EFI.
- linux-metal.toml: CONFIG_CMDLINE_BOOL=y + CMDLINE horneado
('console=tty0 ... initrd=/initramfs.cpio.gz rdinit=/init'). Sin FORCE ⇒ en BIOS
GRUB sigue mandando su cmdline. Confirmado en fuente (libstub/file.c:50): el
EFI-stub convierte '/'→'\' y efi_load_initrd cae a la carga por cmdline sin loader.
- iso-image.sh: modo EFI_STUB=1 ⇒ la ESP lleva el bzImage como \EFI\BOOT\BOOTX64.EFI
+ initramfs.cpio.gz en su raíz (FAT32). La firmware lanza el kernel directo.
- metal-iso.sh: pasa EFI=1 EFI_STUB=1 (híbrido: BIOS GRUB + UEFI EFI-stub).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- scripts/metal-iso.sh: arma work/hammer-metal.iso (kernel metal + firmware AX201
+ wpa_supplicant + wifi-connect), consola en pantalla (console=tty0).
- VALIDADO BIOS (QEMU): el kernel metal bootea, inicializan usbhid/i8042 (teclado),
e1000/e1000e/igb, cfg80211+regulatory (stack WiFi), simpledrm/VGA console, y
arje-zero arranca PID1. iwlwifi/nvme presentes (no bindean en QEMU sin hw real).
- HALLAZGO: la rama UEFI (OVMF) NO bootea el kernel — regresión pre-existente de
GRUB 2.14 (host rolling): GRUB-EFI dice 'Booting' y el kernel queda mudo, con
CUALQUIER kernel (el QEMU tmb falla; efi-boot-test FALLA UEFI / PASA BIOS).
Fix propuesto: boot por EFI-stub directo (sin GRUB-EFI) — requiere kernel con
CONFIG_CMDLINE embebido + ESP con bzImage como BOOTX64.EFI.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pieza 1+2 de 'hammer en el metal' (laptop TigerLake, WiFi AX201):
- recipes/linux-metal.toml: variante del kernel con hardware real built-in
(efifb/simpledrm, USB+HID, AHCI/NVMe, cfg80211+mac80211+iwlwifi/iwlmvm,
e1000e/r8169, USB-CDC). Conserva los bits hammer (overlay/userns/fanotify/
virtio) ⇒ sigue booteando en QEMU. MODULES=off (monolítico, sin modprobe).
Deja linux.toml INTOCADO (su of_tree es load-bearing del selfhost).
- scripts/metal-firmware.sh: inyecta iwlwifi-QuZ-a0-hr-b0/cc-a0 + regulatory.db
en /lib/firmware de un rootfs (descomprime .zst → .ucode plano). Blobs fijos
(TODO pin a linux-firmware).
- ESTADO.md: resumen humano del proyecto.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El edge rust depende de scudo-malloc y los shims rustc/cargo lo linkean como primer NEEDED ⇒
scudo interpone malloc en todo el proceso y CRASHEA a rustc en ciertos proc-macros (corrupted
chunk header / SIGSEGV). No se puede apk-del (rust depende). Mitigación: aliasar
/usr/lib/libscudo.so → la libc musl ⇒ el NEEDED resuelve pero malloc cae a musl, sin scudo.
Los shims no usan símbolos scudo-específicos (sólo querían el override), seguro y reversible
(.orig-scudo). bootstrap-devfs.sh lo reproduce (paso 3a-bis).
Destrabados+promovidos: trippy (trip 0.13.0), jnv (0.7.1), presenterm (0.16.1) — antes
crasheaban rustc, ahora construyen+corren static-musl.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El usuario aprobó subir el rustc del sandbox. El rootfs de build (.dev-fs/alpine) migró a
repos Alpine edge: rust/cargo 1.96.0 (+ gcc 15.2/musl 1.2.6/llvm22) + clang-dev/clang-libs
(libclang p/bindgen de los *-sys). bootstrap-devfs.sh actualizado para reproducirlo. El 4/4
NO se afecta (usa SWAP_RUST con el rust hammer-built 1.91.1); esto es el toolchain del CATÁLOGO.
Destrabados+promovidos: oxlint (1.94) y ruff (1.94) construyen+sellan static-musl. ouch lleva
gueto gcc pero queda staged: sus deps C++ (unrar-ng-sys/libbzip3-sys) chocan en el link final
(-lstdc++ vs la libc++ de zig). Frontera C++ = ortogonal al MSRV.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
La pieza que escala a miles: scripts/build-farm.sh construye N recetas a la vez
(worker pool xargs -P) sobre recipes/incoming/, y lo que CONSTRUYE+sella lo promueve
incoming/->recipes/ + publica al repo firmado (en serie: el index.json es mutable
compartido); lo que falla queda staged con su motivo. Idempotente (cache-hit del store).
Corrida sobre las 22 del lote Rust #2, JOBS=4 en la laptop libre (8 cores/19GB):
BUILD-YIELD 11/22 promovidos, los 11 corren static-musl (bandwhich/difftastic/fclones/
gping/grex/mcfly/miniserve/navi/onefetch/pastel/viu). Corpus 71->82, repo 82.
Los 11 fallos, FLAGEADOS por la granja (esto es el valor: triage automatico, no
adivinanza) y staged en incoming/ para revision:
- crate+dep-C bajo zig-cc (frente conocido, mismo family que el gueto gcc): delta
(libgit2-sys), gitui (openssl-sys), jless (libc-stdhandle).
- MSRV > 1.91.1 (techo del sandbox): ouch (1.93). watchexec: feature nightly E0658.
- LINK colgado con zig-cc en binarios Rust grandes (deadlock, hubo que matarlos):
broot, pueue, starship. Patron a investigar (zig cc + lld en binarios pesados).
- import roto (no build): xsv/zellij 'No such file' (la fuente no clasifico),
dog (importo un dog.c ajeno, no el cliente DNS Rust).
GOTCHA infra: builds Rust grandes pueden COLGARSE en el link final con zig-cc
(broot 7min frozen, pueue/starship idem); la granja deja matar el slot
(pkill -f 'build recipes/incoming/<n>.toml') y sigue con los demas.
Arranca el tier-2 de la escalera (C clasico via Alpine, que trae los parches musl):
- import-batch.sh: env PREFER=nix|alpine. Para tandas C, PREFER=alpine antepone Alpine —
el import de nix de un C tiene exito (tarball) pero SIN parches musl => romperia al
construir. Refactor a 'tiers' ordenados (misma escalera, dos sentidos).
- tandas/cli-c.txt: primera tanda C (tree/which/sed/gawk/gzip/tar/jq/file).
- importador Alpine: build-deps = SOLO makedepends. El depends de abuild es RUNTIME
(gzip depends=less para zless) — no hace falta para compilar y rompia hammer build
(buscaba recipes/less.toml). Ahora va como comentario de provenance. Mismo patron que
el fix de buildInputs-de-nix en recetas Rust.
VALIDADO: import C 8/8 desde Alpine/main con parches musl bajados; gzip pierde el less
espurio. test extracts_source_patches_deps_phases actualizado (depends != build-dep).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Faltaba el orquestador de "importar tandas a escala": las piezas per-paquete ya
existían (nix-import.sh, alpine-import.sh) pero sin un driver que aplicara la ESCALERA
DE FALLBACK en lote.
- import-batch.sh <pkg...> | -f <listfile>: por paquete intenta nix (Rust/Go/CLI,
~100% musl) y cae a Alpine main→community si el import falla (Alpine trae los parches
de musl). Mapeo opcional nixattr=alpinepkg. Escribe OUTDIR/<pkg>.toml.
- Mide el YIELD POR TIER (nix / alpine / fallaron) — el dato real al escalar, sin
especular. stdout limpio = nombres importados (encadenable con xargs/pin-recipes).
- Encadena con las piezas existentes: pin-recipes.sh (Fase 2 tag→SHA) + build-repo.sh
(Etapa F pack --build + repo firmado).
- tandas/cli-rust.txt: primera tanda curada (tier 1 Rust) para el modo -f.
VALIDADO REAL en vivo (nix 2.34.7): tanda {fd, hyperfine, jq} → yield 3/3, nix=2
(fd/hyperfine), alpine=1 (jq cae a main + baja test-portable.patch). pin en lote sobre
la tanda: fd v10.4.2 → SHA 7027d453, jq (tarball) salteado.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Los imports github salen con commit=tag flotante (v1.1.0); el pin lo resuelve al SHA inmutable
⇒ el laboratorio se vuelve determinista al estilo Nix (origen anclado a un punto fijo).
- hammer-cli: `hammer pin <recipe>` (in-place o --out). Usa `git ls-remote` (host-agnóstico, sin
API ni tokens ni rate-limits), prefiere el commit dereferenciado `^{}` para tags anotados.
Reescritura DIRIGIDA de la línea `commit = "<tag>"` (preserva comentarios/formato; no toca
version u otras que casen). No-op si ya es SHA (idempotente) o tarball (ya anclado por sha256).
is_git_sha (40 hex sha1 / 64 hex sha256). +1 test.
- scripts/pin-recipes.sh: ancla en lote (recipes/*.toml).
- Validado real: sd v1.1.0 → 4a7b216552d6… (git ls-remote), idempotente. 31 suites verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El tier de mayor yield (Rust) salía como github sin --bin ni install ⇒ no buildeable. Ahora un
paquete buildRustPackage sale build-ready, con el patrón de la receta ripgrep.
- nix_import.rs: NixPkg gana is_rust + main_program. Si is_rust ⇒ flags=["--bin", <bin>] (bin =
meta.mainProgram, ripgrep→rg) + install "cp target/release/<bin> /out/usr/bin/<bin>". +1 test.
- nix-import.sh: detecta Rust por `hasAttr "cargoDeps" p`; main_program = meta.mainProgram or pname.
- Validado real: import fd → repo+commit, flags=["--bin","fd"], install template. Build-ready
(sólo el commit es tag, no SHA — refinamiento aparte). 31 suites verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mueve las recetas de Alpine de "importan" a "casi buildean":
- alpine_import.rs: translate_abuild() en las fases — substituye $pkgdir→/out (el DESTDIR del lab),
$pkgname→nombre, $pkgver→versión. NO toca $CBUILD/$CHOST/--shared (juicio por-paquete, marcado).
+1 test.
- scripts/alpine-import.sh: baja el tarball UNA vez y calcula el sha256 (Alpine publica sha512,
hammer pide sha256), reemplazando el FIXME ⇒ receta lista sin tocar el hash a mano.
- VALIDADO real: import bzip2 → sha256 ab5a0317… resuelto, 5 parches musl bajados, install
traducido a /out. Recipe build-ready (sin $pkgdir ni FIXME en código). 31 suites verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Segunda fuente del catálogo, y la RESPUESTA a "¿qué si el build falla en musl?": Alpine ya
porta miles de paquetes a musl CON los parches; su APKBUILD los trae. Un import de nix los pierde.
- crates/hammer-cli/alpine_import.rs: PARSEA el APKBUILD (no lo ejecuta) → receta hammer.
Extrae pkgname/pkgver (expande $var), la URL del tarball, LOS .patch (→ source.patches, lo
central), makedepends+depends → deps (filtra -dev, !negados, pins versionados, auto-refs),
build()/package() → fases. sha256 queda FIXME (Alpine publica sha512; el wrapper lo calcula). 3 tests.
- `hammer import-alpine [FILE|-]`; scripts/alpine-import.sh <pkg> [main|community] baja el
APKBUILD + sus .patch de aports.
- VALIDADO contra aports REAL: import coreutils 9.11 → patches renameat2-fakeroot.patch +
coreutils-9.10-dash-tests.patch BAJADOS a disco; deps limpias (acl/attr/bash/openssl/perl/utmps);
fases build/package capturadas. 31 suites verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Poblar el catálogo no es opcional: 34 recetas a mano = userland desierto. nixpkgs es el mayor set
de recetas DESDE FUENTE ⇒ semilla natural. Importamos la RECETA (source+hash+deps), nunca el
binario del cache de nix — hammer reconstruye desde fuente ("verificar, no confiar").
- crates/hammer-cli/nix_import.rs: consume el JSON normalizado de nix y emite una receta hammer.
Clasifica el origen: fetchurl flat → tarball+sha256 (convierte el hash nix SRI/base32/hex → hex);
fetchFromGitHub → repo+commit (hammer pinea por commit, no necesita el hash NAR). Filtra el ruido
de stdenv (setup-hooks, wrappers). nix_base32 decode portado. 11 tests.
- `hammer import-nix [FILE|-]` (stdin) → receta .toml; valida que parsee como Recipe.
- scripts/nix-import.sh <attr>: `nix eval --apply` produce el JSON normalizado y lo pipea al
importador. NIX_STORE= para store local si /nix/store no es escribible.
- VALIDADO contra nixpkgs REAL (nix 2.34): import hello (tarball, sha256→hex) + ripgrep (github→
repo+commit); pipeline completo nix→import→pack→.swm probado con hello. 31 suites verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Convierte la maquinaria de paquetería en la cadena de suministro real: cada receta del corpus
se vuelve un .swm, el repo es el catálogo firmado, install lo reproduce localmente.
- scripts/build-repo.sh: packea recipes/*.toml al repo, anclando expected_hash con `pack --build`
(cache-hit si el artefacto ya está sellado; fallback a pack sin ancla por timeout/fallo), y
firma el release (clave efímera o KEY=). Env: REPO/STORE/KEY/DISTRO/BUILD_TIMEOUT.
- /dist/ gitignoreado (el repo es artefacto reproducible desde el script).
- Validado: poblado de 34 paquetes (31 con expected_hash anclado), release firmado. install
ripgrep desde el repo FIRMADO en modo --require-signed → release trusted → reproduce
b3:9e6079fd (casa el ancla del catálogo) → hidrata → rg 14.1.1 corre. Cadena completa.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El modelo de generaciones es in-place (sin menu NixOS que ofrecer en GRUB); lo
que encaja es auto-sanar un upgrade interrumpido al boot. crates/hammer-recover
= mini-binario static-musl (lo unico que el producto necesita, sin el CLI hammer
completo): sin pending.json es no-op; con uno completa (roll-forward) o deshace
(roll-back) -> FHS siempre consistente; nunca aborta el boot. iso-image.sh
INSTALLER=1 lo compila (target musl) y bundlea al payload; hammer-live-install.sh
lo copia a /usr/sbin/hammer-recover y el wrapper /sbin/init instalado lo corre
tras montar /store y /var/lib/hammer, antes de incarnar arje-zero. iso-install-
test.sh valida el hook al boot (marker 'hammer-recover: sin upgrade interrumpido').
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
El apply escribe el plan completo a pending.json ANTES de proyectar y lo limpia
al commitear; un corte a media proyección deja pending.json + FHS a medias. La
proyección se hizo re-entrante (project_plan, backups idempotentes via
backup_existing_once que nunca pisa el original) ⇒ recover COMPLETA (roll-forward,
re-verifica of_tree) o DESHACE (roll-back: restaura backups, borra la gen a
medias, current->padre). apply se niega con PendingExists si hay intento; status
lo avisa. CLI: hammer upgrade recover [--rollback]. 5 tests (corte a media
proyeccion -> ambos modos) + ejercicio en upgrade-e2e-test.sh. 14 tests verde.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
iso-image.sh EFI=1 añade un 2º El Torito EFI: ESP FAT (poblada con el mtools de
hammer, recipes/mtools.toml) con EFI/BOOT/BOOTX64.EFI = grubx64.efi
(grub-mkimage -O x86_64-efi). GRUB EFI lee el mismo grub.cfg y carga el kernel
EFI_STUB (ya en el kernel, sin rebuild) + initrd vía protocolo EFI. El mismo ISO
sigue booteando por BIOS (El Torito i386-pc) ⇒ híbrido. efi-boot-test.sh valida
ambas firmwares E2E (OVMF→grubx64.efi→sshd, y SeaBIOS→sshd).
GOTCHA: mformat -F fuerza FAT32 (min ~33MiB); sobre ESP chica deja FAT inválido
que la firmware no lee -> sin -F, auto FAT12/16.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cierra el lazo ISO live -> disco instalado -> bootea solo. iso-image.sh
INSTALLER=1 bundlea kernel + GRUB MBR (boot/core.img + modulos) en el initramfs
bajo /usr/lib/hammer/install/ + inyecta /usr/bin/hammer-install. hammer-install
corre dentro del live como root real (busybox fdisk/mke2fs/mount/dd + uutils cp):
particiona MBR (/,/store,/var/lib/hammer), formatea, copia la propia raiz del
live (autoinstalador), escribe /boot+wrapper, instala GRUB con 2 dd (boot->MBR,
core->hueco post-MBR; punteros default 1/2 ya valen en MBR contiguo, sin parcheo).
AUTO_INSTALL=<dev> = /init desatendido (install+poweroff). iso-install-test.sh
valida E2E: ISO+disco blanco -> HAMMER-INSTALL-OK -> boot del disco solo ->
GRUB->kernel->arje-zero->sshd, particiones dedicadas montadas.
GOTCHAS: busybox fdisk CHS-alinea a 63 (hueco 62 < core 281 sectores) -> pisa el
FS de p1 -> grub>; fix sectores explicitos (p1@2048). Copiar top-level de /
enumerado, no lista fija, o se escapa /ente/seed.card.json.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
sergioandClaude Fable 5