From 0ac421b5169f6f162d1ad1da32684a8816ce1093 Mon Sep 17 00:00:00 2001 From: sergio Date: Sun, 9 Aug 2026 01:17:01 -0400 Subject: [PATCH] =?UTF-8?q?libsndfile:=20su=20configure=20s=C3=B3lo=20busc?= =?UTF-8?q?a=20python2.x=20=E2=80=94=20tumbaba=20CUATRO=20recetas=20y=20pa?= =?UTF-8?q?rec=C3=ADa=20fallo=20de=20cada=20una?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- .../cosmic-settings-daemon.toml | 5 +- recipes/incoming-cosmic/libsndfile.toml | 13 ++++- recipes/incoming-gnome/libsndfile.toml | 13 ++++- recipes/incoming-kde/libsndfile.toml | 50 +++++++++++++++---- 4 files changed, 69 insertions(+), 12 deletions(-) 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"]