gioser

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…

TOML 1572Shell 203Rust 109Markdown 993728 Definitions

receta: churay entra al catálogo — llevaba cinco días sellada y sin receta en el repo

`escritorio-mirada` declara `churay`, el catálogo no tenía receta, y el grafo lo contaba como
`wanted`: uno de los dos únicos nodos declarados-sin-receta de toda la distro (el otro es
`wanted/xwayland` de KDE, y ése es deliberado — la distro es Wayland-only).

Pero la receta EXISTÍA. Vivía sólo como fichero sin commitear en `/opt/takana`, el clon que siembra
al worker, con mtime del **11-oct**: cinco días. La granja la construyó y la selló —
`b3:705d5f0f…`, 20 MiB en el store del hub— así que el store tenía un artefacto que ningún clon
podía reproducir, y la imagen de `escritorio-mirada` lo lleva adentro.

Se trae tal cual, sin tocar una línea. Verificado por lo único que vale: el hash recalculado en el
hub coincide con el del artefacto sellado.

NO ES MÍA. La autoró otro agente —`churay-metal.toml` ya la nombraba («la receta de la cara
*hybrid* que OTRO AGENTE ya tenía escrita (sin commitear) con esta lista probada»)— y trae su
historia medida adentro: las tres veces que movió el pin el 11-oct y por qué, y el único
`--locked` que falta en todo el corpus con su motivo estructural (`churay-hybrid` está excluido del
workspace porque enciende el backend `cpu` de `llimphi-text`, excluyente del `vello` de los otros
1.161 crates, así que tiene lock propio y el vendoreo de la raíz nunca lo vio). Publicarla es sacar
el arreglo del único sitio donde existía, que es la regla que su propio inventario de parches pide.

Con esto `escritorio-mirada` deja de declarar un `wanted` y su clausura describe lo que la imagen
lleva de verdad.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

11bdea1a2098617ad4d609056c91d4df5b0a7286 · by Sergio · (5 d ago) · parent 48a46890c · browse the tree at this commit

Semantic delta

No definition changed: this change is text, documentation or data.

1 files · +141 −0

diff --git a/recipes/churay.toml b/recipes/churay.toml
new file mode 100644
index 00000000..1750e181
--- /dev/null
+++ b/recipes/churay.toml
@@ -0,0 +1,141 @@
+# churay — el instalador/actualizador de la suite tawasuyu, **como ejecutable normal de Linux**.
+#
+# ══ POR QUÉ ESTA RECETA ═══════════════════════════════════════════════════════════════════════
+# churay tiene tres caras y las elige solo (`churay_core::cara`, SDD-CAMINOS §1):
+#
+#   Escritorio  → hay un compositor: una ventana, como cualquier otra app   ← ESTE binario
+#   Framebuffer → hay pantalla y no hay compositor: pinta directo sobre DRM  (binario aparte)
+#   Terminal    → no hay ni una cosa ni la otra, y dice por qué
+#
+#   SinComputo  → hay compositor y la GPU NO digiere compute shaders           ← ESTE binario
+#
+# El medio que se venía publicando era un kernel más el binario de framebuffer: alcanzaba para
+# instalar y no alcanzaba para lo que se prometió —un demo de takana, un Linux en un USB que
+# alguien pueda probar antes de decidir—. Con el rootfs gráfico (Mesa + `mirada-compositor --drm`)
+# la cara que corresponde es la de ventana.
+#
+# ══ POR QUÉ LA CARA «hybrid» Y NO LA DE VELLO ═════════════════════════════════════════════════
+# Porque la de vello no se ve acá. Medido y escrito en `scripts/mirada-usb.sh` §5c: una app Llimphi
+# sobre wgpu/Vello exige `SHADER_FLOAT16_IN_FLOAT32`, y llvmpipe y lavapipe —los dos únicos que hay
+# en este rootfs por software— no lo ofrecen. El compositor levanta igual (smithay rinde por GL
+# común) y el cliente queda negro; es lo que ya le pasa al greeter.
+#
+# `churay-hybrid` monta la MISMA pantalla sobre `vello_hybrid`: CPU+GPU, sin compute. Su salida está
+# careada contra la del rasterizador de CPU sobre llvmpipe con conteo exacto de píxeles
+# (`02_ruway/churay/churay-hybrid/examples/volcar.rs`, y antes
+# `llimphi-hybrid/tests/hybrid_vs_cpu.rs`: Δ0:236 Δ1:0 sobre 19.200 px). O sea que anda con driver y
+# sin driver, y dibuja lo mismo en los dos.
+#
+# ⚠️ **No está construida en el martillo todavía.** `churay-hybrid` está EXCLUIDO del workspace de
+# tawasuyu —enciende el backend `cpu` de `llimphi-text`, excluyente del `vello` de los otros 207
+# crates— así que tiene workspace y `Cargo.lock` propios y se compila por `--manifest-path`. El
+# vendoreo de abajo apunta a ESE manifiesto; si el martillo se queja del `--locked`, lo que falta es
+# regenerar el lock de ese subdirectorio, no tocar esta receta.
+#
+# La cara de framebuffer **no desaparece**: es el plan B de una máquina donde el compositor no
+# levanta, y existe por una razón dura —el backend `cpu` de `llimphi-text` es EXCLUYENTE del
+# `vello` que usa esta ventana, y las features de cargo se unifican por build, así que son dos
+# binarios por fuerza y no por gusto—. Lo que cambia es cuál se arranca de fábrica.
+#
+# ══ EL PATRÓN ═════════════════════════════════════════════════════════════════════════════════
+# Calcado de `mirada-greeter.toml`, que es el otro consumidor del stack Mesa del rootfs: app
+# Llimphi (runtime Elm sobre winit + wgpu), cliente wayland, EGL/GLES por el backend GL de wgpu
+# —Mesa 24.0.9 acá es iris GL-only, sin Vulkan— y link DINÁMICO, porque wgpu/winit hacen dlopen de
+# libEGL/libGLESv2/libwayland y un binario `crt-static` no puede dlopen.
+#
+# Sin `linux-pam`: churay no pasa por `auth-core` (verificado en sus tres Cargo.toml). El salto a
+# root, cuando hace falta, es un reexec por `pkexec`, no una sesión PAM propia.
+#
+# ⚠️ **El pin es lo que decide qué churay lleva el medio.** El operador arrancó diez veces un
+# pendrive para encontrar defectos de pantalla; cada uno de esos arranques midió el commit que
+# estuviera fijado acá. Mover el pin es publicar una pantalla distinta: se mueve a propósito, y se
+# dice en el mensaje del commit cuál es la diferencia.
+name    = "churay"
+version = "0.0.1"
+license = "MIT"
+
+[source]
+repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
+commit = "b92ed8cf13689d8ed5e4a32308ad3516fdaaccbd"
+# El pin se movió tres veces hoy y cada vez por algo medido, así que queda la historia:
+#   f5395bd9  era de ANTES de que la cara existiera — habría compilado un crate ausente.
+#   d1bae2468 trae la cara, con un `Cargo.lock` propio que se resolvió solo y divergía del
+#             de la raíz en 148 de 451 paquetes; el vendoreo se hace con el lock de la RAÍZ,
+#             así que el build offline moría pidiendo blake3 1.8.7 contra el 1.8.5 vendoreado.
+#   831543aae alinea los dos locks, pero a este subworkspace le faltaba repetir el `[patch]`
+#             de la raíz: resolvía taffy de crates.io donde el vendoreo trae el fork
+#             («unable to verify that taffy v0.12.2 is the same as when the lockfile was
+#             generated»). Un `[patch]` sólo vale desde la raíz del workspace que compila.
+#   b92ed8cf1 repite el patch. Es el que se construye.
+# 2026-10-11: el commit que trae `churay-hybrid`. El pin anterior (f5395bd9) era de antes de
+# que la cara existiera, o sea que esta receta habria construido un crate que no estaba.
+# Igual que el greeter y el compositor: tawasuyu commitea su propio `vendor/` (smithay parcheado
+# por ruta) y el `cargo vendor` de takana lo convertiría en reemplazo de fuente, donde cada crate
+# debe traer `.cargo-checksum.json` — que ese patch nunca tuvo. Con esta clave los crates caen en
+# `.hammer-cargo-vendor/` y no pisan el `vendor/` del monorepo. No entra en `hash_inputs`.
+cargo_vendor_dir = ".hammer-cargo-vendor"
+
+[build]
+compiler = "zig-cc"
+target   = "x86_64-linux-musl"
+link     = "dynamic"
+flags    = ["--manifest-path", "02_ruway/churay/churay-hybrid/Cargo.toml"]
+
+# ⚠️ **ESTA RECETA NO LLEVA `--locked`, y es la unica. El motivo es estructural, no un atajo.**
+#
+# El vendoreo de takana corre `cargo vendor` en la RAIZ del arbol de fuentes, o sea contra el
+# `Cargo.lock` del workspace raiz. `mirada-greeter` y el compositor se construyen con `-p <crate>`:
+# son MIEMBROS de ese workspace, usan ese mismo lock, y `--locked` verifica exactamente lo que se
+# vendoreo. `churay-hybrid` no puede ser miembro —enciende el backend `cpu` de `llimphi-text`,
+# excluyente del `vello` que declaran los otros 1.161— asi que tiene workspace y lock PROPIOS, y el
+# vendoreo no los vio nunca. Con `--locked` cargo se planta antes de compilar:
+#   «cannot update the lock file … because --locked was passed to prevent this»
+#
+# Se saca `--locked` y se deja `--offline`, que es lo que cargo mismo sugiere en ese error. La
+# reproducibilidad NO queda al aire: `--offline` no puede alcanzar la red, asi que el conjunto de
+# versiones disponibles es exactamente el del directorio vendoreado —una entrada fija y direccionada
+# por contenido— y el lock de este subworkspace ya esta alineado con el de la raiz (cero pares
+# nombre+version fuera de el, medido). Lo que cargo reescribe es la contabilidad de `[patch]`, no la
+# eleccion de versiones.
+#
+# La cura de raiz es que el vendoreo cubra tambien los subworkspaces del arbol; eso es trabajo en
+# `takana-build::fetch` y no en esta receta.
+#
+# Fases Cargo EXPLÍCITAS por el mismo motivo que el greeter: `llimphi-ui` → `accesskit_winit` →
+# atspi → `zbus-lockstep-macros`, cuyo `#[validate]` escanea el dir `xml/` de atspi-common llamando
+# `.extension().expect(...)` en CADA entrada ⇒ panica en el SUBDIR `xml/schemas/`. Apuntando
+# LOCKSTEP_XML_PATH a un dir con sólo los `.xml` se evita. (El arreglo limpio es hacer accesskit
+# opcional en llimphi-ui; un instalador no necesita a11y por esa vía.)
+[build.phases]
+compile = '''
+set -e
+XMLDIR="$PWD/.atspi-lockstep-xml"
+mkdir -p "$XMLDIR"
+ls .hammer-cargo-vendor/atspi-common/xml/*.xml >/dev/null 2>&1 || { echo "no hay .hammer-cargo-vendor/atspi-common/xml/*.xml — ¿cambió el vendoreo o la versión de atspi? sin esto zbus-lockstep-macros panica en xml/schemas/" >&2; exit 1; }
+cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
+export LOCKSTEP_XML_PATH="$XMLDIR"
+printf '%s\n' '#!/bin/sh' 'for a do' 'case "$a" in --target=*) a=--target=x86_64-linux-musl ;; esac' 'set -- "$@" "$a"' 'shift' 'done' 'exec zig cc -mcpu=baseline "$@"' > "$PWD/.hammer-zig-cc"
+chmod +x "$PWD/.hammer-zig-cc"
+RF="-C linker=$PWD/.hammer-zig-cc"
+rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
+CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --offline \
+  --manifest-path 02_ruway/churay/churay-hybrid/Cargo.toml -- -C target-feature=-crt-static
+'''
+# El `target/` del subworkspace es el suyo, no el de la raíz.
+install = '''
+set -e
+# El subworkspace tiene `target/` propio, pero el sandbox puede fijar CARGO_TARGET_DIR: se buscan
+# los dos sitios en vez de suponer uno, que es la diferencia entre instalar y fallar al final de
+# una compilacion de dos horas.
+for d in 02_ruway/churay/churay-hybrid/target/release target/release; do
+  if [ -x "$d/churay-hybrid" ]; then
+    install -Dm755 "$d/churay-hybrid" /out/usr/bin/churay-hybrid
+    exit 0
+  fi
+done
+echo "no encontre el binario churay-hybrid en ninguno de los dos target/" >&2
+exit 1
+'''
+
+[deps]
+build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]