Files
takana/recipes/dbus.toml
T
Sergio e852f48491 takana etapa 5a: los comentarios de las 741 recetas
Barrido de TEXTO puro: 1427 líneas de comentario TOML. Cero ArtifactHash
movidos, y eso está MEDIDO, no deducido: hasheé las 741 antes y después y los
ficheros de hashes son idénticos byte a byte (723 con hash real + 18 que ya no
hasheaban de antes).

El guardián valió la pena: el primer barrido, filtrando por 'la línea empieza
con #', movió el hash de helix, lsof y steam-runtime-sniper. La causa es que una
fase se escribe como compile = <triple> ... <triple> y sus comentarios de SHELL
también empiezan con #, pero viven dentro del VALOR — y las fases sí entran en
hash_inputs. El barrido ahora calcula los rangos de las cadenas multilínea de
TOML y no entra ahí.

Quedan intactos a propósito: .hammer-zig-cc y .hammer-cargo-vendor (literales
dentro de fases), hammerd, hammer-recover y toda ruta que empiece por /
2026-09-09 19:23:26 +00:00

50 lines
2.9 KiB
TOML

# dbus 1.16.2 — bus de IPC de escritorio. Import de Alpine (trae parches musl). Adaptado al
# lab takana: deps sólo del catálogo canónico (dbus real sólo necesita expat; libsm/libx11/
# glib/xmlto eran de session-mgmt X11 + docs, opcionales). Build meson estático musl.
name = "dbus"
version = "1.16.2"
license = "AFL-2.1 OR GPL-2.0-or-later"
[source]
tarball = "https://dbus.freedesktop.org/releases/dbus/dbus-1.16.2.tar.xz"
sha256 = "0ba2a1a4b16afe7bceb2c07e9ce99a8c2c3508e5dec290dbb643384bd6beb7e2"
[build]
compiler = "zig-cc"
target = "x86_64-linux-musl"
link = "static"
flags = []
[build.phases]
# ── `--wrap-mode=nodownload`: sin esto meson SALE A INTERNET dentro del sandbox hermético ───────
# dbus declara subproyectos con `.wrap`, y meson intenta descargarlos. En el sandbox no hay red y
# python no trae ssl, así que el error que sale no menciona la red por ningún lado:
# <urlopen error unknown url type: https>
# WARNING: failed to download with error: name 'ssl' is not defined
# meson.build:372:11: ERROR: Unhandled python exception
# «Unhandled python exception» se lee como un bug de meson y es simplemente que no hay salida a
# internet — y no debe haberla: el build es hermético a propósito. `nodownload` obliga a usar las
# deps del sistema (nuestros artefactos, vía pkg-config) y deja los wraps inertes.
# Mismo caso que `wl-clipboard`. Este fallo bloqueaba TRES perfiles a la vez (base, cli y
# escritorio-sway), que es mucho daño para una flag ausente.
# meson estático (patrón glib): systemd/x11-autolaunch/tests/docs off (deps ausentes en el lab).
#
# NO lleva `-all-static` (2026-07-17, frente link-static-mentira-libtool): dbus construye con MESON,
# no con autotools/libtool ⇒ no existe el agujero de libtool (que lee el `LDFLAGS=-static` del lab
# como "preferí mis .a" en vez de pasarlo al linker). Acá `--prefer-static -Ddefault_library=static`
# ya hacen el trabajo: el artefacto trae `libdbus-1.a` (cero .so) y todo binario sale sin NEEDED.
# El `✗ dbus dice static, es DINÁMICO → libdbus-1.so.3 libc.so` del audit era un artefacto VIEJO del
# store (5cc4b104), anterior a estos flags: `ls -dt` agarra el más reciente, no el vigente (lo avisa
# el propio script). Re-sellar bastó — verificado levantando un bus real con dbus-run-session.
configure = "PYTHONPATH=/usr/lib/python3.12/site-packages meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload --prefer-static -Ddefault_library=static -Dsystemd=disabled -Dx11_autolaunch=disabled -Ddoxygen_docs=disabled -Dxml_docs=disabled -Dtools=true -Dsystem_pid_file=/run/dbus/dbus.pid"
compile = "PYTHONPATH=/usr/lib/python3.12/site-packages ninja -C output"
install = '''
set -e
PYTHONPATH=/usr/lib/python3.12/site-packages DESTDIR=/out meson install --no-rebuild -C output
# can't install tmpfs
rm -rf /out/run
'''
[deps]
build = ["meson", "samurai", "python3", "pkgconf", "expat"]