sergio/takana

1# churay — el instalador/actualizador de la suite tawasuyu, **como ejecutable normal de Linux**.
2#
3# ══ POR QUÉ ESTA RECETA ═══════════════════════════════════════════════════════════════════════
4# churay tiene tres caras y las elige solo (`churay_core::cara`, SDD-CAMINOS §1):
5#
6#   Escritorio  → hay un compositor: una ventana, como cualquier otra app   ← ESTE binario
7#   Framebuffer → hay pantalla y no hay compositor: pinta directo sobre DRM  (binario aparte)
8#   Terminal    → no hay ni una cosa ni la otra, y dice por qué
9#
10#   SinComputo  → hay compositor y la GPU NO digiere compute shaders           ← ESTE binario
11#
12# El medio que se venía publicando era un kernel más el binario de framebuffer: alcanzaba para
13# instalar y no alcanzaba para lo que se prometió —un demo de takana, un Linux en un USB que
14# alguien pueda probar antes de decidir—. Con el rootfs gráfico (Mesa + `mirada-compositor --drm`)
15# la cara que corresponde es la de ventana.
16#
17# ══ POR QUÉ LA CARA «hybrid» Y NO LA DE VELLO ═════════════════════════════════════════════════
18# Porque la de vello no se ve acá. Medido y escrito en `scripts/mirada-usb.sh` §5c: una app Llimphi
19# sobre wgpu/Vello exige `SHADER_FLOAT16_IN_FLOAT32`, y llvmpipe y lavapipe —los dos únicos que hay
20# en este rootfs por software— no lo ofrecen. El compositor levanta igual (smithay rinde por GL
21# común) y el cliente queda negro; es lo que ya le pasa al greeter.
22#
23# `churay-hybrid` monta la MISMA pantalla sobre `vello_hybrid`: CPU+GPU, sin compute. Su salida está
24# careada contra la del rasterizador de CPU sobre llvmpipe con conteo exacto de píxeles
25# (`02_ruway/churay/churay-hybrid/examples/volcar.rs`, y antes
26# `llimphi-hybrid/tests/hybrid_vs_cpu.rs`: Δ0:236 Δ1:0 sobre 19.200 px). O sea que anda con driver y
27# sin driver, y dibuja lo mismo en los dos.
28#
29# ⚠️ **No está construida en el martillo todavía.** `churay-hybrid` está EXCLUIDO del workspace de
30# tawasuyu —enciende el backend `cpu` de `llimphi-text`, excluyente del `vello` de los otros 207
31# crates— así que tiene workspace y `Cargo.lock` propios y se compila por `--manifest-path`. El
32# vendoreo de abajo apunta a ESE manifiesto; si el martillo se queja del `--locked`, lo que falta es
33# regenerar el lock de ese subdirectorio, no tocar esta receta.
34#
35# La cara de framebuffer **no desaparece**: es el plan B de una máquina donde el compositor no
36# levanta, y existe por una razón dura —el backend `cpu` de `llimphi-text` es EXCLUYENTE del
37# `vello` que usa esta ventana, y las features de cargo se unifican por build, así que son dos
38# binarios por fuerza y no por gusto—. Lo que cambia es cuál se arranca de fábrica.
39#
40# ══ EL PATRÓN ═════════════════════════════════════════════════════════════════════════════════
41# Calcado de `mirada-greeter.toml`, que es el otro consumidor del stack Mesa del rootfs: app
42# Llimphi (runtime Elm sobre winit + wgpu), cliente wayland, EGL/GLES por el backend GL de wgpu
43# —Mesa 24.0.9 acá es iris GL-only, sin Vulkan— y link DINÁMICO, porque wgpu/winit hacen dlopen de
44# libEGL/libGLESv2/libwayland y un binario `crt-static` no puede dlopen.
45#
46# Sin `linux-pam`: churay no pasa por `auth-core` (verificado en sus tres Cargo.toml). El salto a
47# root, cuando hace falta, es un reexec por `pkexec`, no una sesión PAM propia.
48#
49# ⚠️ **El pin es lo que decide qué churay lleva el medio.** El operador arrancó diez veces un
50# pendrive para encontrar defectos de pantalla; cada uno de esos arranques midió el commit que
51# estuviera fijado acá. Mover el pin es publicar una pantalla distinta: se mueve a propósito, y se
52# dice en el mensaje del commit cuál es la diferencia.
53name    = "churay"
54version = "0.0.1"
55license = "MIT"
56
57[source]
58repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
59commit = "b92ed8cf13689d8ed5e4a32308ad3516fdaaccbd"
60# El pin se movió tres veces hoy y cada vez por algo medido, así que queda la historia:
61#   f5395bd9  era de ANTES de que la cara existiera — habría compilado un crate ausente.
62#   d1bae2468 trae la cara, con un `Cargo.lock` propio que se resolvió solo y divergía del
63#             de la raíz en 148 de 451 paquetes; el vendoreo se hace con el lock de la RAÍZ,
64#             así que el build offline moría pidiendo blake3 1.8.7 contra el 1.8.5 vendoreado.
65#   831543aae alinea los dos locks, pero a este subworkspace le faltaba repetir el `[patch]`
66#             de la raíz: resolvía taffy de crates.io donde el vendoreo trae el fork
67#             («unable to verify that taffy v0.12.2 is the same as when the lockfile was
68#             generated»). Un `[patch]` sólo vale desde la raíz del workspace que compila.
69#   b92ed8cf1 repite el patch. Es el que se construye.
70# 2026-10-11: el commit que trae `churay-hybrid`. El pin anterior (f5395bd9) era de antes de
71# que la cara existiera, o sea que esta receta habria construido un crate que no estaba.
72# Igual que el greeter y el compositor: tawasuyu commitea su propio `vendor/` (smithay parcheado
73# por ruta) y el `cargo vendor` de takana lo convertiría en reemplazo de fuente, donde cada crate
74# debe traer `.cargo-checksum.json` — que ese patch nunca tuvo. Con esta clave los crates caen en
75# `.hammer-cargo-vendor/` y no pisan el `vendor/` del monorepo. No entra en `hash_inputs`.
76cargo_vendor_dir = ".hammer-cargo-vendor"
77
78[build]
79compiler = "zig-cc"
80target   = "x86_64-linux-musl"
81link     = "dynamic"
82flags    = ["--manifest-path", "02_ruway/churay/churay-hybrid/Cargo.toml"]
83
84# ⚠️ **ESTA RECETA NO LLEVA `--locked`, y es la unica. El motivo es estructural, no un atajo.**
85#
86# El vendoreo de takana corre `cargo vendor` en la RAIZ del arbol de fuentes, o sea contra el
87# `Cargo.lock` del workspace raiz. `mirada-greeter` y el compositor se construyen con `-p <crate>`:
88# son MIEMBROS de ese workspace, usan ese mismo lock, y `--locked` verifica exactamente lo que se
89# vendoreo. `churay-hybrid` no puede ser miembro —enciende el backend `cpu` de `llimphi-text`,
90# excluyente del `vello` que declaran los otros 1.161— asi que tiene workspace y lock PROPIOS, y el
91# vendoreo no los vio nunca. Con `--locked` cargo se planta antes de compilar:
92#   «cannot update the lock file … because --locked was passed to prevent this»
93#
94# Se saca `--locked` y se deja `--offline`, que es lo que cargo mismo sugiere en ese error. La
95# reproducibilidad NO queda al aire: `--offline` no puede alcanzar la red, asi que el conjunto de
96# versiones disponibles es exactamente el del directorio vendoreado —una entrada fija y direccionada
97# por contenido— y el lock de este subworkspace ya esta alineado con el de la raiz (cero pares
98# nombre+version fuera de el, medido). Lo que cargo reescribe es la contabilidad de `[patch]`, no la
99# eleccion de versiones.
100#
101# La cura de raiz es que el vendoreo cubra tambien los subworkspaces del arbol; eso es trabajo en
102# `takana-build::fetch` y no en esta receta.
103#
104# Fases Cargo EXPLÍCITAS por el mismo motivo que el greeter: `llimphi-ui` → `accesskit_winit` →
105# atspi → `zbus-lockstep-macros`, cuyo `#[validate]` escanea el dir `xml/` de atspi-common llamando
106# `.extension().expect(...)` en CADA entrada ⇒ panica en el SUBDIR `xml/schemas/`. Apuntando
107# LOCKSTEP_XML_PATH a un dir con sólo los `.xml` se evita. (El arreglo limpio es hacer accesskit
108# opcional en llimphi-ui; un instalador no necesita a11y por esa vía.)
109[build.phases]
110compile = '''
111set -e
112XMLDIR="$PWD/.atspi-lockstep-xml"
113mkdir -p "$XMLDIR"
114ls .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; }
115cp .hammer-cargo-vendor/atspi-common/xml/*.xml "$XMLDIR"/
116export LOCKSTEP_XML_PATH="$XMLDIR"
117printf '%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"
118chmod +x "$PWD/.hammer-zig-cc"
119RF="-C linker=$PWD/.hammer-zig-cc"
120rustc -vV | grep -q 'host: .*-alpine-' || RF="$RF -C link-self-contained=no"
121CC="$PWD/.hammer-zig-cc" RUSTFLAGS="$RF" cargo rustc --release --offline \
122  --manifest-path 02_ruway/churay/churay-hybrid/Cargo.toml -- -C target-feature=-crt-static
123'''
124# El `target/` del subworkspace es el suyo, no el de la raíz.
125install = '''
126set -e
127# El subworkspace tiene `target/` propio, pero el sandbox puede fijar CARGO_TARGET_DIR: se buscan
128# los dos sitios en vez de suponer uno, que es la diferencia entre instalar y fallar al final de
129# una compilacion de dos horas.
130for d in 02_ruway/churay/churay-hybrid/target/release target/release; do
131  if [ -x "$d/churay-hybrid" ]; then
132    install -Dm755 "$d/churay-hybrid" /out/usr/bin/churay-hybrid
133    exit 0
134  fi
135done
136echo "no encontre el binario churay-hybrid en ninguno de los dos target/" >&2
137exit 1
138'''
139
140[deps]
141build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]