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 1184Shell 70Rust 62Markdown 501503 Definiciones

libsndfile: su configure sólo busca python2.x — tumbaba CUATRO recetas y parecía fallo de cada una

COSMIC cerró 25 de 30 raíces. De los 5 fallos, CUATRO daban el mismo mensaje —
«error: no suitable Python interpreter found»— en wireplumber, xdg-desktop-portal,
xdg-desktop-portal-cosmic y cosmic-settings-daemon.

NO ERA DE ELLAS, Y NI SIQUIERA ERA DE MESON. El error viene de un `configure` de AUTOTOOLS que
prueba `python2.2`, `python2.1`, `python2.0` —literalmente— y aborta al no hallarlos. Se
identificó por las flags del comando en el log (`--disable-mpeg --disable-full-suite`), que son
inconfundibles de **libsndfile**: una dep común a las cuatro.

Y declarar `python3` en `[deps]` NO ayuda —dos de las cuatro ya lo tenían—: el problema no es
que falte el intérprete, es que el script no reconoce ese NOMBRE. Autoconf respeta la variable
de entorno `PYTHON`, así que se le pasa `PYTHON=python3` y sella.

LA LECCIÓN, que hoy ya se repitió con `dbus-shared`: cuando varias recetas fallan con el MISMO
mensaje raro, el fallo está en una dep común — y **la forma de identificarla es mirar QUÉ
configure/meson.build lo emite**, no la receta que se estaba construyendo. Las flags del comando
y el número de línea del meson.build son la firma del paquete que realmente muere.

Aplicado a las tres copias (incoming-gnome, -cosmic, -kde), que dan el mismo hash. Y de paso
`cosmic-settings-daemon` sí necesitaba `python3` en deps, que no lo declaraba: dos causas
distintas bajo un mensaje idéntico.

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

0ac421b5169f6f162d1ad1da32684a8816ce1093 · por sergio · (hace 2 meses) · padre 1c33075d6 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

4 archivos · +69 −12

diff --git a/recipes/incoming-cosmic/cosmic-settings-daemon.toml b/recipes/incoming-cosmic/cosmic-settings-daemon.toml
index a95bfbb0..b14591eb 100644
--- a/recipes/incoming-cosmic/cosmic-settings-daemon.toml
+++ b/recipes/incoming-cosmic/cosmic-settings-daemon.toml
@@ -60,4 +60,7 @@ cp data/polkit-1/rules.d/cosmic-settings-daemon.rules /out/usr/share/polkit-1/ru
 # `openssl` NO lo pide el daemon: llega por `native-tls`, que llega por el crate `geonames` (la base
 # de husos horarios para el tema claro/oscuro por hora). El único de la suite que toca TLS, y por una
 # función que uno no asocia con la red. Su artefacto publica `openssl.pc`, así que alcanza declararlo.
-build = ["libxkbcommon", "pkgconf", "libudev-zero", "libinput", "pipewire", "openssl"]
+# `python3` OBLIGATORIO: meson es un SCRIPT de Python. Sin el intérprete la fase muere con
+# «no suitable Python interpreter found» / exit 127, que se lee como «meson no está» cuando meson SÍ
+# está y se hidrata bien. Misma causa que tenía muerta a `wlr-randr`.
+build = ["python3", "libxkbcommon", "pkgconf", "libudev-zero", "libinput", "pipewire", "openssl"]
diff --git a/recipes/incoming-cosmic/libsndfile.toml b/recipes/incoming-cosmic/libsndfile.toml
index 878f7e41..9c338b1a 100644
--- a/recipes/incoming-cosmic/libsndfile.toml
+++ b/recipes/incoming-cosmic/libsndfile.toml
@@ -30,7 +30,18 @@ link     = "dynamic"
 
 [build.phases]
 configure = '''
-./configure \
+# ── `PYTHON=python3`: su configure sólo busca python2.x y aborta ────────────────────────────────
+# El `AM_PATH_PYTHON` de este autoconf prueba python2.2, python2.1, python2.0 —literalmente— y al no
+# hallarlos muere con «configure: error: no suitable Python interpreter found». Declarar `python3` en
+# `[deps]` NO ayuda: el problema no es que falte el intérprete sino que el script no reconoce ese
+# NOMBRE. Autoconf respeta la variable de entorno `PYTHON`, así que se le pasa directamente.
+#
+# ⚠ Y el mensaje engaña doble: es un error de AUTOTOOLS, no de meson, y aparece en el log de las
+# recetas que dependen de ésta. El 2026-08-09 tumbó CUATRO —wireplumber, xdg-desktop-portal,
+# xdg-desktop-portal-cosmic y cosmic-settings-daemon— y en todas parecía un fallo propio. Cuando
+# varias recetas fallan con el mismo mensaje raro, mirar QUÉ configure lo emite: las flags del
+# comando lo identifican (aquí `--disable-mpeg --disable-full-suite` son inconfundibles de libsndfile).
+PYTHON=python3 ./configure \
 	--build=$CBUILD --host=$CHOST \
 	--prefix=/usr \
 	--enable-shared --disable-static \
diff --git a/recipes/incoming-gnome/libsndfile.toml b/recipes/incoming-gnome/libsndfile.toml
index 878f7e41..9c338b1a 100644
--- a/recipes/incoming-gnome/libsndfile.toml
+++ b/recipes/incoming-gnome/libsndfile.toml
@@ -30,7 +30,18 @@ link     = "dynamic"
 
 [build.phases]
 configure = '''
-./configure \
+# ── `PYTHON=python3`: su configure sólo busca python2.x y aborta ────────────────────────────────
+# El `AM_PATH_PYTHON` de este autoconf prueba python2.2, python2.1, python2.0 —literalmente— y al no
+# hallarlos muere con «configure: error: no suitable Python interpreter found». Declarar `python3` en
+# `[deps]` NO ayuda: el problema no es que falte el intérprete sino que el script no reconoce ese
+# NOMBRE. Autoconf respeta la variable de entorno `PYTHON`, así que se le pasa directamente.
+#
+# ⚠ Y el mensaje engaña doble: es un error de AUTOTOOLS, no de meson, y aparece en el log de las
+# recetas que dependen de ésta. El 2026-08-09 tumbó CUATRO —wireplumber, xdg-desktop-portal,
+# xdg-desktop-portal-cosmic y cosmic-settings-daemon— y en todas parecía un fallo propio. Cuando
+# varias recetas fallan con el mismo mensaje raro, mirar QUÉ configure lo emite: las flags del
+# comando lo identifican (aquí `--disable-mpeg --disable-full-suite` son inconfundibles de libsndfile).
+PYTHON=python3 ./configure \
 	--build=$CBUILD --host=$CHOST \
 	--prefix=/usr \
 	--enable-shared --disable-static \
diff --git a/recipes/incoming-kde/libsndfile.toml b/recipes/incoming-kde/libsndfile.toml
index 1bfe8680..9c338b1a 100644
--- a/recipes/incoming-kde/libsndfile.toml
+++ b/recipes/incoming-kde/libsndfile.toml
@@ -1,8 +1,20 @@
-# libsndfile 1.2.2 — lectura/escritura de audio (libsndfile.so). Campaña KDE (ADR 0011): PulseAudio lo
-# exige para cargar muestras/sonidos del sistema.
+# libsndfile 1.2.2 — lectura/escritura de ficheros de audio (WAV, AIFF, AU…). Entra al frente GNOME
+# por debajo de pulseaudio: `sndfile` es dep INCONDICIONAL de su meson.build:615 (top-level, sin
+# `required:` que la ablande), así que ni siquiera `-Ddaemon=false` la esquiva. Cadena de la cima:
+# gnome-shell → subprojects/gvc → libpulse → libsndfile.
 #
-# ENABLE_EXTERNAL_LIBS=OFF: apaga FLAC/Ogg/Vorbis/Opus (flac y opus no están sellados). Quedan WAV/AIFF/AU
-# nativos, que es lo que PulseAudio necesita para los sonidos del sistema. Evita la cadena flac+opus.
+# --disable-external-libs es lo que hace que esta receta sea UNA y no CINCO: por defecto libsndfile
+# enlaza FLAC, Ogg y Vorbis, ninguna en el corpus. Apagándolos queda una librería C autocontenida
+# que no depende de nada fuera de libc. Lo que se pierde es leer .flac/.ogg; lo que consume el
+# escritorio de acá son los sonidos de sistema en WAV, que es el formato nativo de libsndfile.
+# --disable-mpeg apaga LAME/mpg123 por lo mismo.
+#
+# --disable-alsa: ALSA sólo la usa el programa de ejemplo sndfile-play, no la librería.
+# --disable-sqlite: sólo la usa la utilidad sndfile-regtest.
+# --disable-full-suite: no instala los ~10 binarios de utilería (sndfile-info, sndfile-convert…);
+# lo que gvc necesita es libsndfile.so y su .pc.
+#
+# ISLA DINÁMICA: shared, porque libpulse y todo lo que cuelga de gnome-shell son .so.
 name    = "libsndfile"
 version = "1.2.2"
 license = "LGPL-2.1-or-later"
@@ -15,12 +27,32 @@ sha256  = "3799ca9924d3125038880367bf1468e53a1b7e3686a934f098b7e1d286cdb80e"
 compiler = "zig-cc"
 target   = "x86_64-linux-musl"
 link     = "dynamic"
-flags    = []
 
 [build.phases]
-configure = './configure --build=$CBUILD --host=$CHOST --prefix=/usr --enable-shared --disable-static --disable-external-libs --disable-mpeg --disable-alsa'
-compile   = 'make -j"$(nproc)"'
-install   = "make DESTDIR=/out install && find /out -name '*.la' -delete"
+configure = '''
+# ── `PYTHON=python3`: su configure sólo busca python2.x y aborta ────────────────────────────────
+# El `AM_PATH_PYTHON` de este autoconf prueba python2.2, python2.1, python2.0 —literalmente— y al no
+# hallarlos muere con «configure: error: no suitable Python interpreter found». Declarar `python3` en
+# `[deps]` NO ayuda: el problema no es que falte el intérprete sino que el script no reconoce ese
+# NOMBRE. Autoconf respeta la variable de entorno `PYTHON`, así que se le pasa directamente.
+#
+# ⚠ Y el mensaje engaña doble: es un error de AUTOTOOLS, no de meson, y aparece en el log de las
+# recetas que dependen de ésta. El 2026-08-09 tumbó CUATRO —wireplumber, xdg-desktop-portal,
+# xdg-desktop-portal-cosmic y cosmic-settings-daemon— y en todas parecía un fallo propio. Cuando
+# varias recetas fallan con el mismo mensaje raro, mirar QUÉ configure lo emite: las flags del
+# comando lo identifican (aquí `--disable-mpeg --disable-full-suite` son inconfundibles de libsndfile).
+PYTHON=python3 ./configure \
+	--build=$CBUILD --host=$CHOST \
+	--prefix=/usr \
+	--enable-shared --disable-static \
+	--disable-external-libs \
+	--disable-mpeg \
+	--disable-alsa \
+	--disable-sqlite \
+	--disable-full-suite
+'''
+compile = 'make -j"$(nproc)"'
+install = 'make DESTDIR=/out install'
 
 [deps]
-build = ["pkgconf", "python3"]
+build = ["make", "pkgconf"]