SergioandClaude Opus 5
cd78bb98c9
EL LOGO. El usuario pasó el PNG oficial. El ASCII no se inventa: se MIDE. Extraído celda por celda
del original — bbox 348×348 en un lienzo de 512, cuadrícula **7×7**, celda de 49,7 px — con cuatro
colores exactos y ninguno más:
#a63a25 ladrillo · #df6b2a naranja · #e3a63d dorado · #fff6de crema
La primera versión que puse era un martillo dibujado a ojo: era *un* martillo, no *el* logo. Cada
celda son DOS caracteres de bloque porque un carácter de terminal es alto y angosto, y `██` es lo que
conserva la geometría cuadrada del original; reconstruirlo a ojo la pierde y deja de ser el logo.
Van los dos ficheros: `logo.png` (el oficial, tal cual) y `logo.txt` (el mismo en ANSI de color
verdadero), más la config global de fastfetch con `file-raw` — con `file` los escapes se imprimirían
como texto. Y `os-release` se mueve de `cli` a **`base`**: toda imagen de takana debe saber decir qué
es, incluida la más pelada. «No sólo para esta máquina, para siempre en takana».
De paso, dos cosas que sólo se ven construyendo: `cp -a` aborta en el sandbox («failed to preserve
ownership»), va `cp -r`; y un config de fastfetch que sólo define `logo` dibuja el logo y NI UN DATO
— `modules` hay que listarlo aunque parezca redundante.
RUSTC, PASO 1. `rust-toolchain-bin` 1.97.0, el tarball oficial de rust-lang verificado por su sha256
y sellado tal cual, con `foreign = true` porque son bytes ajenos y no un build nuestro (clase
`ajeno`: no infla el recuento del corpus, ADR 0015). Target **musl**, no gnu: un toolchain gnu
traería el cargador de glibc y sería needed-colgante otra vez.
Por qué importa, y no es gusto: TODO el instrumental de takana es Rust —12 crates, 42 555 líneas— y
el `rustc` que los construye sale del LAB, un rootfs ajeno que ENTRA en el ArtifactHash. La distro
depende de bytes de otro para reconstruirse a sí misma. Y el corpus tenía **44 recetas `cargo-*` y
CERO de rustc**: subcomando-sin-driver a escala de toolchain.
Es el paso 1 de tres, y los otros dos no son opcionales: (2) rustc desde fuente con el `llvm18` que
YA está sellado (379 M), y (3) la cadena mrustc→1.91.1 que ya existe documentada en el selfhost pero
vive en el bootstrap, no en el corpus.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
55 lines
2.9 KiB
TOML
55 lines
2.9 KiB
TOML
# takana — EL BINARIO DEL PROYECTO, empaquetado como una receta más del corpus.
|
|
#
|
|
# POR QUÉ EXISTE (SDD 28 §3.4). El corpus construía 869 recetas y no la suya: `takana` sólo existía
|
|
# como `cargo build --release` sobre un clon del repo. Eso bloqueaba lo de arriba de todo — que un
|
|
# servidor takana **se sirva sus propios paquetes a su propio host**: el host necesita `takana`
|
|
# instalado para consumir el repo, y no podía instalarlo DESDE el repo porque no estaba en el repo.
|
|
#
|
|
# Receta Cargo, mismo patrón que `hammerd`/`netup`/`arje-zero`: crate del workspace takana a un
|
|
# commit fijado (ADR 0006), deps vendoreadas en el fetch para un build hermético `--offline`, enlace
|
|
# estático con `zig cc`. Sin dependencias C: el CLI es Rust puro (clap/serde/toml/nix/tracing).
|
|
#
|
|
# ⚠ EL ALIAS DEL ADR 0016 VOLVÍA AL CRATE INEMPAQUETABLE, y se descubrió acá porque takana nunca se
|
|
# había empaquetado. `takana-cli` declara DOS `[[bin]]` sobre el mismo `main.rs` (`takana` y `hammer`,
|
|
# la compatibilidad de la etapa 2). El camino Cargo del corpus invoca `cargo rustc … -- -C
|
|
# target-feature=+crt-static`, y **`cargo rustc` con argumentos extra sólo admite UN target**:
|
|
#
|
|
# error: extra arguments to `rustc` can only be passed to one target, consider filtering
|
|
# the package by passing, e.g., `--lib` or `--bin NAME` to specify a single target
|
|
#
|
|
# Por eso `--bin takana` en los flags. Y `hammer` se repone en la fase de instalación como ENLACE, no
|
|
# como segundo binario: en el ÁRBOL DE BUILD un symlink no sobrevive (`cargo clean` lo borra y la
|
|
# siembra de la granja excluye `/target` — por eso el ADR eligió dos `[[bin]]`), pero en el ARTEFACTO
|
|
# sellado es permanente y no duplica los megas.
|
|
#
|
|
# Que `hammer` esté en el artefacto TAPA además un agujero real: `arje-zero` todavía invoca el binario
|
|
# por el nombre viejo — en el primer arranque de la caja de producción se leyó `hammer no corre, sin
|
|
# menú de arranque` — y viene pineado desde tawasuyu, así que no se arregla desde este repo. Cuando la
|
|
# etapa 6 retire el alias, hay que subir arje-zero ANTES.
|
|
|
|
name = "takana"
|
|
version = "0.0.1"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
# El repo del propio takana: el `commit` es el identificador inmutable; la URL es sólo locator y no
|
|
# entra en `hash_inputs` (ADR 0013 §1). Subirlo cuando el CLI avance.
|
|
repo = "https://git.gioser.net/sergio/takana.git"
|
|
commit = "0d0ab79092b282f45bfb1158694f4eaf5df58af5"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
|
|
# Split de la info de depuración (SDD 23 etapa 4). Entra en `hash_inputs`.
|
|
strip_debug = true
|
|
flags = ["-p", "takana-cli", "--bin", "takana"]
|
|
|
|
[build.phases]
|
|
# Sobrescribe el `find target/release …` por defecto: hay que reponer el alias `hammer` (ver arriba).
|
|
install = "mkdir -p /out/usr/bin && cp target/release/takana /out/usr/bin/takana && ln -s takana /out/usr/bin/hammer"
|
|
|
|
[deps]
|
|
build = ["binutils"]
|