From 589c656262f9d6eb48fbf834b75f90045da272b5 Mon Sep 17 00:00:00 2001 From: Sergio Date: Fri, 18 Sep 2026 10:17:38 +0000 Subject: [PATCH] =?UTF-8?q?atuq:=20la=20b=C3=B3veda=20del=20navegador=20co?= =?UTF-8?q?ntesta=20CERRADA=20=E2=80=94=20faltaban=20el=20due=C3=B1o=20y?= =?UTF-8?q?=20el=20di=C3=A1logo,=20no=20el=20guardi=C3=A1n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El §7.quinquies.bis cerró la unidad 12 diciendo que el guardián de METAL «ahora sí se puede escribir porque hay con qué correrlo». No se podía, y la primera pregunta que ese guardián iba a hacer lo dice en veinte segundos, contra el artefacto sellado y por marcos de 4 bytes: ← {"id":1,"ok":true,"verb":"ping","version":"0.1.0"} ← el control: el host ESTÁ ← {"id":2,"ok":true,"verb":"vault.status","locked":true,...} ← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]} stderr: puriy-costura: sin bóveda (No such file or directory): los verbos vault.* dirán «cerrada» Lo que engaña es el `ok:true`: **«cerrada» es una respuesta exitosa**, así que ningún log, ningún reintento y ninguna insignia la distinguen de un usuario que todavía no desbloqueó la suya. Hoy, en las cuatro imágenes de escritorio, atuq instala la décima extensión y la función está apagada. Las dos mediciones del §7.quinquies eran correctas y lo siguen siendo —`strings` da `vault` 10 veces, `vigia-atuq-verbos` da cero verbos sin dueño—, pero las dos preguntan si el host CONOCE el verbo. Ninguna pregunta quién contesta del otro lado del socket: el host no abre la bóveda nunca, a propósito (sled toma un lock exclusivo y el proceso que lanza el navegador muere con cada pestaña), así que le habla a un DUEÑO — y el dueño no estaba en el corpus. Saber el verbo no es poder contestarlo. Entran las dos piezas que faltaban, las dos con el mismo efecto de «se ve apagado y nada falla»: `boveda` (pacha-boveda-llimphi, el dueño único de la base, que levanta el socket del navegador) y `shuma-pregunta` (el diálogo que lanza `PorDialogo`; sin él `Command::new` falla y **todo vault.fill se deniega**, indistinguible de que el usuario haya dicho que no). Las dos pineadas al MISMO 23a292863 que ya comparten puriy-costura, shuma-* y pacha-* —un pin distinto es otro vendoreo de 2,4 G— y con la forma de mirada-greeter, que es el patrón de una llimphi GUI: link dinámico (winit/wgpu dlopean EGL/Vulkan/wayland) y la inyección de LOCKSTEP_XML_PATH que evita el panic de zbus-lockstep-macros en el subdir xml/schemas/ de atspi. ⚠ El sello TODAVÍA NO ESTÁ: las dos están encoladas en el worker detrás del build de rust, bajo `flock -o`. Hasta que sellen, estas recetas son una hipótesis escrita, no un artefacto medido. Co-Authored-By: Claude Opus 5 (1M context) --- docs/26-atuq-envoltorio-gecko.md | 64 ++++++++++++++++++++++- recipes/boveda.toml | 88 ++++++++++++++++++++++++++++++++ recipes/shuma-pregunta.toml | 69 +++++++++++++++++++++++++ 3 files changed, 219 insertions(+), 2 deletions(-) create mode 100644 recipes/boveda.toml create mode 100644 recipes/shuma-pregunta.toml diff --git a/docs/26-atuq-envoltorio-gecko.md b/docs/26-atuq-envoltorio-gecko.md index 9fe71004..2511c09d 100644 --- a/docs/26-atuq-envoltorio-gecko.md +++ b/docs/26-atuq-envoltorio-gecko.md @@ -2988,7 +2988,67 @@ su control positivo intacto (`sct.observe` sigue apareciendo ⇒ el grep mide). **Lo que queda de la unidad 12** es el guardián de METAL de la bóveda —servidor, navegador real, login real, el diálogo de consentimiento a la vista—, que ahora sí se puede escribir porque hay con -qué correrlo. +qué correrlo. ⚠ **Esto último resultó FALSO y está corregido en el §7.sexies: faltaban el dueño de la +bóveda y el diálogo de consentimiento, y sin ellos el host contesta «cerrada».** + +### 7.sexies «Hay con qué correrlo» era falso: la bóveda del navegador contesta CERRADA (2026-09-18) + +El párrafo de arriba cerró el §7.quinquies.bis diciendo que el guardián de metal «ahora sí se puede +escribir porque hay con qué correrlo». **No se podía, y la primera pregunta del guardián lo dice en +veinte segundos.** Antes de escribirlo se le preguntó al artefacto sellado —el mismo binario que va +en las cuatro imágenes de escritorio— por marcos de 4 bytes, igual que le habla la extensión: + +``` +← {"id":1,"ok":true,"verb":"ping","version":"0.1.0"} +← {"id":2,"ok":true,"verb":"vault.status","locked":true,"count":0} +← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]} +stderr: puriy-costura: sin bóveda (No such file or directory (os error 2)): + los verbos vault.* dirán «cerrada» +``` + +`ping` es el control: el host **está**, atiende y contesta. Lo que no hay es bóveda. Y el `ok:true` +de las otras dos es la parte que engaña: **«cerrada» es una respuesta exitosa**, no un error, así que +ningún reintento, ningún log y ninguna insignia distinguen esto de un usuario que todavía no +desbloqueó la suya. + +**Por qué faltaba, y por qué el §7.quinquies no podía verlo.** Ese capítulo midió lo que se podía +medir desde acá: que el commit pineado del host CONOCE los verbos (`strings` → `vault` 10 veces, +`vigia-atuq-verbos` → cero verbos sin dueño). Las dos mediciones eran correctas y siguen siéndolo. +Lo que ninguna preguntaba es **quién contesta del otro lado del socket**: el host no abre la bóveda +nunca, a propósito —`sled` toma un lock exclusivo y el proceso que lanza el navegador muere y revive +con cada pestaña—, así que le habla a un DUEÑO, y el dueño no estaba en el corpus. Es la misma forma +de fallo del §7.quinquies una capa más abajo: **saber el verbo no es poder contestarlo**. + +Las dos piezas ausentes, las dos con el mismo efecto de «se ve apagado y nada falla»: + +| pieza | qué es | qué pasa sin ella | +|---|---|---| +| `boveda` (`pacha-boveda-llimphi`) | la app de la bóveda, y el **dueño único** de la base: la abre para su ventana y levanta el socket del navegador en un hilo | `vault.*` contesta `locked:true`: insignia vacía, nada que ofrecer | +| `shuma-pregunta` | el diálogo de consentimiento que `PorDialogo` lanza como proceso | todo `vault.fill` se **deniega** —`Command::new` falla ⇒ «no»—, indistinguible de que el usuario haya dicho que no | + +⇒ Hoy, en las cuatro imágenes de escritorio, `atuq` instala la décima extensión y la función está +apagada de fábrica. Entran `recipes/boveda.toml` y `recipes/shuma-pregunta.toml`, las dos pineadas al +**mismo** `23a292863` que ya comparten `puriy-costura`, `shuma-*` y `pacha-*` —un pin distinto es +otro vendoreo de 2,4 G del workspace entero— y las dos con la forma de `mirada-greeter`, que es el +patrón de una llimphi GUI: `link = "dynamic"` porque winit/wgpu cargan EGL/Vulkan/wayland por +`dlopen`, y la inyección de `LOCKSTEP_XML_PATH` que evita el panic de `zbus-lockstep-macros` en el +subdir `xml/schemas/` de atspi (mismo `accesskit_winit` 0.33, mismo `atspi-common` 0.13 en el lock). + +⚠ **Y quedan DOS decisiones que no se toman de paso**, las dos de producto: + +1. **en qué imágenes se declaran.** La función del navegador no existe sin las dos, así que o entran + a las cuatro de escritorio o la bóveda de `atuq` se queda como una extensión que no ofrece nada. + Es la misma pregunta abierta que el §6.7 dejó con `llama-cpp`, y se contesta con el tamaño medido + al lado, no antes; +2. **de dónde sale la raíz de las claves.** La app la saca de la seed de identidad del llavero del + kernel, que en una máquina de desarrollo no está desbloqueada — y por eso existe `BOVEDA_TEST_ROOT`, + que deriva la raíz de una cadena y abre **otra** bóveda, vacía, diciéndolo en pantalla. Es la + escotilla con la que el guardián de metal va a poder sembrar una credencial sin tocar la de nadie. + +**Lo que queda de la unidad 12**, entonces, no es «escribir el guardián de metal»: es sellar estas +dos y recién ahí escribirlo. Lo que sí queda escrito desde hoy es la pregunta con la que ese guardián +tiene que empezar —`vault.status` contra el host— porque es la que separa «la bóveda dijo que no» de +«no hay bóveda», que se ven idénticas desde la extensión. ## 8. Plan, por unidades de trabajo @@ -3017,7 +3077,7 @@ siguiente. | 9 | **Medios (6.6) ✅ y torrent (6.9) ✅ — 2026-09-10.** El medio lo abre `mpv`; el torrent lo toma `puriy-costura-torrent`, un daemon **propio, configurable y perezoso** que sobrevive al navegador y cosecha al CAS. Medido antes de decidir: la pila de librqbit compila para musl (226 crates), así que la decisión fue «no ahí» y no «no se puede». **Faltan** el foco (6.5) y la IA local (6.7), ésta bloqueada porque el corpus no tiene modelo ni embeddings | 6.5–6.7, 6.9 | 5 ✅ | | 10 | **Foco (6.5) — 2026-09-10.** Entra al corpus la cadena `nftables` (libmnl + libnftnl + nft 1.1.6), que el grafo pedía y nadie había puesto, con dos arreglos de fábrica: el sello de tiempo que rompía la reproducción y un bashismo. Medido con root: el cgroup en foco no sale y el de al lado sí. Y del lado del navegador, la extensión `foco` MUESTRA el estado y **no tiene verbo para apagarlo**. **Falta** quién pone a `atuq` en un cgroup (delegación, decisión de arje) y quién aplica la política (root) | 6.5 | 6 ✅ | | 11 | **Motor de inferencia local (6.7) — 2026-09-11.** Entra `recipes/llama-cpp.toml` (b10901, estática, 199 M, **REPRODUCE**), que resulta ser **un solo muro para dos pendientes**: el §6.7 y la mitad semántica del §6.3 no eran dos problemas, era que el corpus no tenía con qué correr un modelo (`pluma-llm` sólo tiene backends de nube; `rimay-verbo-fastembed` DESCARGA onnxruntime glibc + el modelo). ⚠ Y dejó medido lo que no se podía deducir: **`SOURCE_DATE_EPOCH` —la variable que nos da reproducibilidad— apagaba las SEIS perillas de ISA de ggml**, y el artefacto sellaba y corría con 0 `%ymm`. Ahora van declaradas y el `install` las comprueba. Guardián `scripts/test-llama-cpp.py` con control negativo vivo. **Faltan** el modelo (fuente pineada, no receta), los verbos del host y quién levanta el servidor | 6.7, y la mitad semántica de 6.3 | 5 ✅ | -| 12 | **La bóveda (SDD-BOVEDA §8) — a medias, 2026-09-15.** La décima extensión: ofrece la credencial del sitio abierto y no puede sacar una contraseña por su cuenta —`vault.match` contesta títulos y usuarios; la contraseña sale por `vault.fill`, que **pregunta en el escritorio**—. La dirección la pone el chrome, nunca la página. El gestor de Gecko se aparta como VALOR DE ARRANQUE y no como política. **Destrabada el 2026-09-16** (§7.quinquies.bis): el `Cargo.lock` de tawasuyu publicado —y resultó ser byte a byte el que la otra sesión ya tenía sin commitear—, el pin subido a `23a292863` ⇒ `b3:7d63655a`, construido en el worker (el vendoreo son 2,4 G y el hub estaba al 99%) y medido con el mismo `strings` que había diagnosticado el hueco: `vault` de **0 a 10**, con `cas`/`sct` de control. **Falta**: el guardián de METAL | el gestor de contraseñas de la suite dentro del navegador | 5 ✅ | +| 12 | **La bóveda (SDD-BOVEDA §8) — a medias, 2026-09-15.** La décima extensión: ofrece la credencial del sitio abierto y no puede sacar una contraseña por su cuenta —`vault.match` contesta títulos y usuarios; la contraseña sale por `vault.fill`, que **pregunta en el escritorio**—. La dirección la pone el chrome, nunca la página. El gestor de Gecko se aparta como VALOR DE ARRANQUE y no como política. **Destrabada el 2026-09-16** (§7.quinquies.bis): el `Cargo.lock` de tawasuyu publicado —y resultó ser byte a byte el que la otra sesión ya tenía sin commitear—, el pin subido a `23a292863` ⇒ `b3:7d63655a`, construido en el worker (el vendoreo son 2,4 G y el hub estaba al 99%) y medido con el mismo `strings` que había diagnosticado el hueco: `vault` de **0 a 10**, con `cas`/`sct` de control. **Falta**, y no era lo que este renglón decía (§7.sexies, 2026-09-18): el host sellado contesta `vault.status → locked:true` porque **el dueño de la bóveda y el diálogo de consentimiento no estaban en el corpus** — la función está apagada de fábrica en las cuatro imágenes. Entran `recipes/boveda.toml` y `recipes/shuma-pregunta.toml`; después de eso, el guardián de METAL | el gestor de contraseñas de la suite dentro del navegador | 5 ✅ | | 9.a | **Proxy por contenedor ✅ v0.5** — contenedores por política + extensión con `proxy.onRequest` | 6.8, y NO dependía de 5: es API de Firefox | — | Las unidades 2 y 4 son **paralelizables**: la toolchain no toca el chrome y el chrome no toca la diff --git a/recipes/boveda.toml b/recipes/boveda.toml new file mode 100644 index 00000000..5c7888d9 --- /dev/null +++ b/recipes/boveda.toml @@ -0,0 +1,88 @@ +# boveda — la app de la bóveda de la suite, y **el dueño único** de su base (SDD-BOVEDA §8.5). +# +# ── POR QUÉ ESTA RECETA, Y POR QUÉ RECIÉN AHORA (2026-09-18) ──────────────────────────────────── +# `atuq` trae desde el 2026-09-15 la extensión `boveda@atuq.tawasuyu` —la décima— y desde el +# 2026-09-16 el host `puriy-costura` pineado a un commit que SÍ atiende `vault.*`. Con eso el SDD 26 +# (§7.quinquies.bis) dio la unidad 12 por destrabada y anunció que «ahora sí se puede escribir el +# guardián de metal porque hay con qué correrlo». +# +# ⚠ **Y no había.** Medido contra el artefacto sellado, en esta máquina, con el binario que va en la +# imagen: +# +# ← {"id":2,"ok":true,"verb":"vault.status","locked":true,"count":0} +# ← {"id":3,"ok":true,"verb":"vault.match","locked":true,"items":[]} +# stderr: puriy-costura: sin bóveda (No such file or directory (os error 2)): +# los verbos vault.* dirán «cerrada» +# +# El host **nunca abre la bóveda por su cuenta, a propósito**: `sled` toma un lock exclusivo, y el +# proceso que lanza el navegador muere y revive con cada pestaña, así que no es un buen dueño de la +# base. El host le habla al DUEÑO por un socket… y el dueño no estaba en el corpus. O sea que la +# función que el navegador anuncia —insignia, `vault.match`, `vault.fill`— hoy contesta «cerrada» +# en las cuatro imágenes de escritorio, sin un solo error a la vista. Es exactamente la forma de +# fallo que el §7.quinquies describe: ficheros en orden, navegador sin la función. +# +# El dueño es ESTA app: abre la bóveda para su propia ventana y levanta el socket en un hilo para +# el navegador (`atender_al_navegador`), con políticas distintas de cada lado — sin preguntar a +# quien está mirando la ventana, preguntando SIEMPRE a lo que llega de afuera (`PorDialogo`, que +# lanza `shuma-pregunta`; ver `recipes/shuma-pregunta.toml`, sin la cual todo `vault.fill` se +# deniega). +# +# ── LA FORMA DE LA RECETA ────────────────────────────────────────────────────────────────────── +# Es una llimphi GUI del monorepo: el patrón es `mirada-greeter` (winit + wgpu/vello ⇒ `link = +# "dynamic"`, porque EGL/Vulkan/wayland se cargan por `dlopen` en runtime y `crt-static` lo +# impediría) sobre el pin `23a292863`, que es el que ya comparten `puriy-costura`, `shuma-*`, +# `pacha-*` y `tejido`: **un pin distinto es otro vendoreo de 2,4 G**, no un detalle de gusto. +name = "boveda" +version = "0.1.0" +license = "MPL-2.0" + +[source] +repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git" +commit = "23a292863f53b355c5c02d6185904f2c33d8ab42" +# tawasuyu COMMITEA su propio `vendor/` (smithay parcheado por `[patch.crates-io]` POR RUTA); el +# `cargo vendor` de takana lo pisaría y el error hablaría de un crate cualquiera, no de esto. +# No entra en `hash_inputs`. +cargo_vendor_dir = ".hammer-cargo-vendor" + +[build] +compiler = "zig-cc" +target = "x86_64-linux-musl" +link = "dynamic" +flags = ["-p", "pacha-boveda-llimphi", "--bin", "boveda"] + +# Fase `compile` EXPLÍCITA —réplica de la que takana genera para Cargo— porque hay que inyectar +# `LOCKSTEP_XML_PATH` ANTES del build. La causa está escrita entera en `mirada-greeter.toml` y es +# la misma acá, con el mismo `accesskit_winit` 0.33 y el mismo `zbus-lockstep-macros` 0.5.2 en el +# lock: su `#[validate]` escanea el dir `xml/` de `atspi-common` llamando `.extension().expect()` +# en CADA entrada ⇒ PANICA en el subdirectorio `xml/schemas/`. Apuntando la variable a un dir con +# sólo los `.xml` se evita. +# +# ⚠ La ruta NO es `vendor/` como en `mirada-greeter`: con `cargo_vendor_dir` los crates vendoreados +# caen en `.hammer-cargo-vendor/`. Y la comprobación es a GRITOS: si mañana `atspi-common` deja de +# vendorearse ahí, un `cp` que falla en silencio dejaría la variable apuntando a un dir vacío y el +# panic volvería con el error lejos de la causa. +[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 --locked --offline -p pacha-boveda-llimphi --bin boveda -- -C target-feature=-crt-static +''' +install = ''' +set -e +test -x target/release/boveda || { echo "no hay target/release/boveda — ¿cambió el nombre del bin en pacha-boveda-llimphi?" >&2; exit 1; } +install -Dm755 target/release/boveda /out/usr/bin/boveda +''' + +[deps] +# Las mismas que `mirada-greeter` menos `linux-pam` (eso era de `auth-core`, que esta app no usa: +# su segundo factor es `nakui-auth`, Rust puro). El stack gráfico se consulta en build-time por +# pkg-config y se carga por `dlopen` en runtime. +build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"] diff --git a/recipes/shuma-pregunta.toml b/recipes/shuma-pregunta.toml new file mode 100644 index 00000000..68755a7b --- /dev/null +++ b/recipes/shuma-pregunta.toml @@ -0,0 +1,69 @@ +# shuma-pregunta — la pregunta con opciones que contesta una PERSONA, y devuelve la elegida por +# stdout en una línea de JSON. Hermano de `shuma-askpass`: dentro del cajón de shuma si el pedido +# sale de una de sus pestañas, y en su propia ventana llimphi si no. +# +# ── POR QUÉ ENTRA AL CORPUS AHORA (2026-09-18) ───────────────────────────────────────────────── +# Porque es **el consentimiento de la bóveda**, y sin él la bóveda del navegador no entrega nada. +# `pacha_boveda::navegador::PorDialogo` —la política que la app le pone al socket del navegador— +# es literalmente un `Command::new("shuma-pregunta")`, y su primera línea de manejo de error es: +# +# let Ok(mut hijo) = hijo else { +# // No hay con qué preguntar ⇒ no. +# return false; +# }; +# +# O sea que **sin este binario en la imagen, todo `vault.fill` se deniega**, y se deniega bien: la +# extensión lee `f.denied === true` y se calla, que es lo correcto y es indistinguible de que el +# usuario haya dicho que no. La función se ve apagada y nada falla. Ver `recipes/boveda.toml`, que +# trae la otra mitad (el dueño de la base) y la medición que destapó las dos ausencias. +# +# No es sólo de la bóveda: es el diálogo declarado de la suite (`COLA-SHUMA` §I2), y existe para +# sacar del medio la costumbre de reconocer un menú por su forma en la pantalla de un terminal y +# contestarlo a ciegas con flechas. +# +# ── LA FORMA DE LA RECETA ────────────────────────────────────────────────────────────────────── +# llimphi GUI del monorepo, igual que `recipes/boveda.toml`: `link = "dynamic"` (winit + wgpu +# cargan EGL/Vulkan/wayland por `dlopen`) y el mismo pin `23a292863` que comparten `shuma-daemon`, +# `shuma-gateway`, `shuma-tui`, `puriy-costura` y `pacha-*` — un pin distinto es otro vendoreo de +# 2,4 G del workspace entero. +name = "shuma-pregunta" +version = "0.1.0" +license = "MIT OR Apache-2.0" + +[source] +repo = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git" +commit = "23a292863f53b355c5c02d6185904f2c33d8ab42" +cargo_vendor_dir = ".hammer-cargo-vendor" + +[build] +compiler = "zig-cc" +target = "x86_64-linux-musl" +link = "dynamic" +flags = ["-p", "shuma-pregunta", "--bin", "shuma-pregunta"] + +# Fase `compile` explícita por `LOCKSTEP_XML_PATH` — la causa, entera, está en `mirada-greeter.toml` +# y repetida en `recipes/boveda.toml`: `accesskit_winit` → `atspi` → `zbus-lockstep-macros`, cuyo +# `#[validate]` panica al encontrar el subdir `xml/schemas/`. La comprobación falla a gritos porque +# un `cp` mudo dejaría la variable apuntando a un directorio vacío. +[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 --locked --offline -p shuma-pregunta --bin shuma-pregunta -- -C target-feature=-crt-static +''' +install = ''' +set -e +test -x target/release/shuma-pregunta || { echo "no hay target/release/shuma-pregunta" >&2; exit 1; } +install -Dm755 target/release/shuma-pregunta /out/usr/bin/shuma-pregunta +''' + +[deps] +build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf"]