tawasuyu

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 1569Shell 203Rust 109Markdown 993728 Sutichaykuna

recetas craft: el «el corpus no publica alsa» era un falso negativo mío — provee.py apuntaba al store vacío

07baaf4d8f0c1e85701a0909e2b6575ece08c549 · ruwaq Sergio · (10 p'unchaw ñawpaq) · tayta ffea3ddba · kay commitpi sach'ata qhaway

Semántico sayk'uy

Mana ima sutichaypas t'ikrakurqanchu: qillqalla, yachachiylla utaq willaylla t'ikrakurqan.

4 qillqakuna · +36 −12

diff --git a/recipes/deckcraft.toml b/recipes/deckcraft.toml
index dc688d63..210ccccf 100644
--- a/recipes/deckcraft.toml
+++ b/recipes/deckcraft.toml
@@ -126,7 +126,13 @@ test -s /out/usr/bin/deckcraft
 # Igual que las demás de la familia MÁS `alsa-lib`, y ésta no es decorativa: la app trae `cpal`
 # **sin condicionar por plataforma**, que en Linux es `alsa-sys` y pregunta por `alsa.pc` con
 # pkg-config ⇒ sin esta dep el build muere en el `build.rs` de `alsa-sys`, no en el link.
-# ⚠ Y el corpus hoy NO publica `alsa`: `scripts/provee.py --desde corpus alsa` sale «NADIE LO
-# PUBLICA en ninguna cola» aunque `recipes/alsa-lib.toml` exista — la receta está escrita y sin
-# sellar. Declararla acá la construye; no hay que hacer nada aparte.
+# ⚠ **Y acá hay una cicatriz que conviene dejar escrita, porque me mordió a mí.** Escribí que «el
+# corpus no publica alsa» porque `scripts/provee.py --desde corpus alsa` contestaba «NADIE LO PUBLICA
+# en ninguna cola». **Era un falso negativo mío, no del catálogo**: `provee.py` toma el store de
+# `HAMMER_STORE` y su default es `./store`, que en el clon de la jaula está VACÍO — el bueno es
+# `/store`. Con `HAMMER_STORE=/store` la respuesta es `alsa ✓ corpus/alsa-lib ⇒ desde corpus: SÍ`, y
+# el artefacto estaba sellado en las dos máquinas (`b3:73fb200a`, con `alsa.pc` y `libasound.so.2`).
+# El build lo confirmó sin ayuda: `caché: artefacto ya en el store … name=alsa-lib`.
+# ⇒ **Una herramienta que contesta «nadie» apuntando a un store vacío se ve igual que un hueco real.**
+# Antes de declarar que falta algo, mirar a qué store se le está preguntando.
 build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf", "alsa-lib"]
diff --git a/recipes/effectcraft.toml b/recipes/effectcraft.toml
index 82960fe6..59d1838e 100644
--- a/recipes/effectcraft.toml
+++ b/recipes/effectcraft.toml
@@ -126,7 +126,13 @@ test -s /out/usr/bin/effectcraft
 # Igual que las demás de la familia MÁS `alsa-lib`, y ésta no es decorativa: la app trae `cpal`
 # **sin condicionar por plataforma**, que en Linux es `alsa-sys` y pregunta por `alsa.pc` con
 # pkg-config ⇒ sin esta dep el build muere en el `build.rs` de `alsa-sys`, no en el link.
-# ⚠ Y el corpus hoy NO publica `alsa`: `scripts/provee.py --desde corpus alsa` sale «NADIE LO
-# PUBLICA en ninguna cola» aunque `recipes/alsa-lib.toml` exista — la receta está escrita y sin
-# sellar. Declararla acá la construye; no hay que hacer nada aparte.
+# ⚠ **Y acá hay una cicatriz que conviene dejar escrita, porque me mordió a mí.** Escribí que «el
+# corpus no publica alsa» porque `scripts/provee.py --desde corpus alsa` contestaba «NADIE LO PUBLICA
+# en ninguna cola». **Era un falso negativo mío, no del catálogo**: `provee.py` toma el store de
+# `HAMMER_STORE` y su default es `./store`, que en el clon de la jaula está VACÍO — el bueno es
+# `/store`. Con `HAMMER_STORE=/store` la respuesta es `alsa ✓ corpus/alsa-lib ⇒ desde corpus: SÍ`, y
+# el artefacto estaba sellado en las dos máquinas (`b3:73fb200a`, con `alsa.pc` y `libasound.so.2`).
+# El build lo confirmó sin ayuda: `caché: artefacto ya en el store … name=alsa-lib`.
+# ⇒ **Una herramienta que contesta «nadie» apuntando a un store vacío se ve igual que un hueco real.**
+# Antes de declarar que falta algo, mirar a qué store se le está preguntando.
 build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf", "alsa-lib"]
diff --git a/recipes/filmcraft.toml b/recipes/filmcraft.toml
index e348cb01..9b66e4b2 100644
--- a/recipes/filmcraft.toml
+++ b/recipes/filmcraft.toml
@@ -130,7 +130,13 @@ test -s /out/usr/bin/filmcraft
 # Igual que las demás de la familia MÁS `alsa-lib`, y ésta no es decorativa: la app trae `cpal`
 # **sin condicionar por plataforma**, que en Linux es `alsa-sys` y pregunta por `alsa.pc` con
 # pkg-config ⇒ sin esta dep el build muere en el `build.rs` de `alsa-sys`, no en el link.
-# ⚠ Y el corpus hoy NO publica `alsa`: `scripts/provee.py --desde corpus alsa` sale «NADIE LO
-# PUBLICA en ninguna cola» aunque `recipes/alsa-lib.toml` exista — la receta está escrita y sin
-# sellar. Declararla acá la construye; no hay que hacer nada aparte.
+# ⚠ **Y acá hay una cicatriz que conviene dejar escrita, porque me mordió a mí.** Escribí que «el
+# corpus no publica alsa» porque `scripts/provee.py --desde corpus alsa` contestaba «NADIE LO PUBLICA
+# en ninguna cola». **Era un falso negativo mío, no del catálogo**: `provee.py` toma el store de
+# `HAMMER_STORE` y su default es `./store`, que en el clon de la jaula está VACÍO — el bueno es
+# `/store`. Con `HAMMER_STORE=/store` la respuesta es `alsa ✓ corpus/alsa-lib ⇒ desde corpus: SÍ`, y
+# el artefacto estaba sellado en las dos máquinas (`b3:73fb200a`, con `alsa.pc` y `libasound.so.2`).
+# El build lo confirmó sin ayuda: `caché: artefacto ya en el store … name=alsa-lib`.
+# ⇒ **Una herramienta que contesta «nadie» apuntando a un store vacío se ve igual que un hueco real.**
+# Antes de declarar que falta algo, mirar a qué store se le está preguntando.
 build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf", "alsa-lib"]
diff --git a/recipes/soundcraft.toml b/recipes/soundcraft.toml
index 7b338107..b12f9626 100644
--- a/recipes/soundcraft.toml
+++ b/recipes/soundcraft.toml
@@ -131,7 +131,13 @@ test -s /out/usr/bin/soundcraft
 # Igual que las demás de la familia MÁS `alsa-lib`, y ésta no es decorativa: la app trae `cpal`
 # **sin condicionar por plataforma**, que en Linux es `alsa-sys` y pregunta por `alsa.pc` con
 # pkg-config ⇒ sin esta dep el build muere en el `build.rs` de `alsa-sys`, no en el link.
-# ⚠ Y el corpus hoy NO publica `alsa`: `scripts/provee.py --desde corpus alsa` sale «NADIE LO
-# PUBLICA en ninguna cola» aunque `recipes/alsa-lib.toml` exista — la receta está escrita y sin
-# sellar. Declararla acá la construye; no hay que hacer nada aparte.
+# ⚠ **Y acá hay una cicatriz que conviene dejar escrita, porque me mordió a mí.** Escribí que «el
+# corpus no publica alsa» porque `scripts/provee.py --desde corpus alsa` contestaba «NADIE LO PUBLICA
+# en ninguna cola». **Era un falso negativo mío, no del catálogo**: `provee.py` toma el store de
+# `HAMMER_STORE` y su default es `./store`, que en el clon de la jaula está VACÍO — el bueno es
+# `/store`. Con `HAMMER_STORE=/store` la respuesta es `alsa ✓ corpus/alsa-lib ⇒ desde corpus: SÍ`, y
+# el artefacto estaba sellado en las dos máquinas (`b3:73fb200a`, con `alsa.pc` y `libasound.so.2`).
+# El build lo confirmó sin ayuda: `caché: artefacto ya en el store … name=alsa-lib`.
+# ⇒ **Una herramienta que contesta «nadie» apuntando a un store vacío se ve igual que un hueco real.**
+# Antes de declarar que falta algo, mirar a qué store se le está preguntando.
 build = ["mesa", "wayland", "wayland-protocols", "libdrm", "expat", "zlib", "zstd", "libffi", "pkgconf", "alsa-lib"]