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 1299Shell 91Rust 63Markdown 561634 Sutichaykuna

⎇ 84e3737e10e17927380ed3e232e50cebfdd39123 recipes/incoming-wlr/dunst.toml TOML · 143 siq'ikuna · 9.5 KB Ñawpa willay ch'uya

dunst: sway ya atiende las notificaciones, y hay un píxel que lo prueba 4f9ee5430 · Sergio ·

1# dunst 1.12.2 — el daemon de notificaciones que le faltaba a la imagen de sway.
2#
3# ── POR QUÉ EXISTE ESTA RECETA, Y POR QUÉ ACÁ ──────────────────────────────────────────────────
4# El SDD 26 §6.10 midió perfil por perfil quién ATIENDE `org.freedesktop.Notifications`, que es la
5# otra mitad de tener `libnotify`:
6#
7#     escritorio-kde      plasma-workspace        ✓ completa
8#     escritorio-gnome    gnome-shell             ✓ completa
9#     escritorio-cosmic   cosmic-notifications    ✓ completa
10#     escritorio-sway     —                       ✗ MEDIA: nadie atiende
11#
12# Con `libnotify` en la imagen y nadie del otro lado, una página que pide notificar no falla: el
13# navegador manda el mensaje al bus y no lo recoge nadie. Media función, cero errores — la forma que
14# este proyecto ya se cansó de pagar.
15#
16# ── POR QUÉ dunst Y NO mako, QUE ES EL DE LA CASA wlroots ──────────────────────────────────────
17# Por dos razones medidas, no por gusto:
18#
19# 1. **El nombre `mako` YA ESTÁ OCUPADO en el corpus** por el motor de plantillas de Python que usa
20#    Mesa para su codegen. Un `recipes/incoming-wlr/mako.toml` no lo pisaría en el disco —la
21#    resolución es sibling-first— pero el cierre del perfil incluye las herramientas de build, así
22#    que la imagen de sway terminaría con DOS artefactos llamados `mako` peleando por las mismas
23#    rutas al hidratar. Es exactamente la colisión de homónimos que la granja ya nos cobró una vez.
24# 2. mako habla D-Bus por `sd-bus`, que en musl significa una receta nueva (`basu`). dunst habla por
25#    **GDBus**, o sea `gio-2.0`, que ya está sellado. Cero recetas nuevas de dependencia.
26#
27# ── WAYLAND=1 X11=0, Y EL GUARDIÁN QUE LO EXIGE ───────────────────────────────────────────────
28# dunst compila los dos backends por defecto y el `config.mk` avisa de la trampa con todas las
29# letras: «Disable dependency on wayland. This will force dunst to use xwayland». O sea que un build
30# descuidado sella un binario que en esta distro —Wayland-only, sin GLX y sin Xwayland nativo— NO
31# PINTA NADA y tampoco falla al arrancar. Por eso el `X11=0` no alcanza como intención: la fase
32# `install` comprueba en el ELF que `libwayland-client` esté entre los NEEDED y que `libX11` NO
33# esté. La intención se declara en el flag; el hecho se lee en el binario.
34#
35# ── EL FICHERO DE SERVICIO D-BUS ES LA MITAD QUE IMPORTA ──────────────────────────────────────
36# Sin systemd (`SYSTEMD=0`, que es la postura de la distro) el daemon lo arranca **el bus**: el
37# `.service` declara `Name=org.freedesktop.Notifications` con su `Exec`, y cualquier app que pida ese
38# nombre lo levanta sola. Sin ese fichero habría que acordarse de lanzar dunst a mano en la config de
39# sway, que es justo el tipo de «lo instalé y no anda» que este proyecto trata de no dejar. Se le
40# quita la línea `SystemdService=`, que acá no puede significar nada, y la fase comprueba que el
41# nombre bien escrito quedó adentro.
42#
43# ── `DUNSTIFY=0`: EL EMISOR QUE TRAE dunst SEGFAULTEA, Y NO ES CULPA DE dunst ─────────────────
44# Entró primero con `DUNSTIFY=0` —parecía gratis, `libnotify` ya está en el corpus— y el binario
45# resultante **muere con SIGSEGV hasta en `dunstify --help`**, o sea antes de tocar el bus. Medido en
46# la jaula: rc=139 en las tres pruebas.
47#
48# La causa es el cuadro que este repo ya tiene escrito: **dos GLib en el mismo proceso**. Nuestro
49# `libnotify.so.4` es COMPARTIDO y arrastra `libgobject/libglib/libgio/libgdk_pixbuf` `.so`
50# (`readelf -d` lo dice), mientras que dunst y sus clientes de esta cola enlazan la GLib **estática**
51# del corpus. Un dunstify que mezcla las dos termina con dos copias del sistema de tipos de GObject y
52# se cae al arrancar. El daemon NO tiene el problema: no toca libnotify.
53#
54# Y no se pierde nada, que es lo que hace que ésta sea la salida correcta y no una rendición: el
55# emisor de la casa es **`notify-send`, que viene DENTRO del artefacto de `libnotify`** y ya está en
56# las cuatro imágenes, enlazado de forma consistente contra la cadena compartida. Un binario que
57# segfaultea shipeado en la imagen es peor que no shipearlo.
58#
59# ── EL BINARIO PESA 46 MB, Y LA PALANCA NO ESTÁ EN ESTA RECETA ───────────────────────────────
60# Anotado porque el reflejo se equivoca dos veces. `config.mk` hardcodea `-g`, así que uno prueba
61# `EXTRA_CFLAGS=-g0` esperando bajar decenas de megas: medido, 46.296.624 → 45.933.472 bytes, o sea
62# 0,8%. Y sin embargo la grasa SÍ es depuración — `strip --strip-debug` deja el binario en 7.627.464
63# bytes, los mismos con `-g0` y sin él. Son 38 MB de `.debug_*` que vienen de los `.a` de
64# glib/gio/pango/cairo/gdk-pixbuf, no de compilar dunst.
65# Por eso acá no se toca: strippear en el enlace sería inventar una política en UNA receta cuando el
66# corpus entero tiene la misma forma (swaybg 22 MB, fuzzel 10 MB) y ya hay un documento para eso, el
67# SDD 23. Lo que corresponde es medirlo y dejarlo escrito donde se ve.
68#
69# `VERSION` se pasa a mano: el Makefile la saca de `git describe` y cae a un literal si no hay `.git`.
70# Con el commit pineado las dos ramas son deterministas, pero cuál de las dos corre depende de si el
71# árbol de fuentes trae `.git` — un detalle del build system que no tiene por qué entrar al binario.
72name    = "dunst"
73version = "1.12.2"
74license = "BSD-3-Clause"
75
76[source]
77# Por commit y no por `/archive/<tag>.tar.gz`, misma razón que `fuzzel` y `foot`: el tarball lo
78# genera la forge al vuelo y su sha256 se muere solo cuando GitHub actualiza su git/gzip.
79# ⚠ El tag `v1.12.2` es anotado; éste es el commit desreferenciado (`v1.12.2^{}`).
80repo   = "https://github.com/dunst-project/dunst.git"
81commit = "fc78b9f11aa8b63f4d81c96466206a9b63a22f07"
82
83[build]
84compiler    = "zig-cc"
85target      = "x86_64-linux-musl"
86link        = "dynamic"
87zig_version = "0.13.0"
88
89[build.phases]
90configure = '''
91# ── EL `-lexpat` TIENE QUE IR AL FINAL, Y EL Makefile NO DEJA ────────────────────────────────
92# `libfontconfig.a` referencia XML_* y el expat estático hay que darlo DESPUÉS: el linker resuelve
93# de izquierda a derecha. En las recetas meson de esta cola eso se hace con `-Dc_link_args=-lexpat`,
94# pero acá manda un Makefile que arma la línea como `${LDFLAGS} = DEFAULT + <lo que pasás> + LIBS`,
95# o sea que cualquier `-lexpat` nuestro cae ANTES de fontconfig y no sirve de nada. Sobreescribir
96# `LIBS` significaría reproducir a mano toda la salida de pkg-config.
97# La salida es un wrapper de un solo token que agrega la librería al final de CADA invocación —el
98# mismo truco que usa `recipes/ffmpeg.toml` para sus `--cc/--ar`—. En las compilaciones `-c` el
99# `-lexpat` sobra y clang lo ignora con un aviso.
100ZW="$PWD/.zwrap"; mkdir -p "$ZW"
101printf '#!/bin/sh\nexec %s "$@" -lexpat\n' "$CC" > "$ZW/cc"
102chmod +x "$ZW/cc"
103'''
104compile   = '''
105make -j"$(nproc)" CC="$PWD/.zwrap/cc" WAYLAND=1 X11=0 SYSTEMD=0 DUNSTIFY=0 \
106     PREFIX=/usr SYSCONFDIR=/etc/xdg VERSION="1.12.2"
107'''
108install = '''
109make DESTDIR=/out CC="$PWD/.zwrap/cc" WAYLAND=1 X11=0 SYSTEMD=0 DUNSTIFY=0 \
110     PREFIX=/usr SYSCONFDIR=/etc/xdg VERSION="1.12.2" install
111
112# ── GUARDIÁN 1: ¿es el backend de wayland, o quedó el de X11? ────────────────────────────────
113# «Compilé con X11=0» es una intención; esto es el hecho. Un dunst con backend X11 en una distro
114# sin Xwayland arranca, toma el bus y no dibuja nunca.
115readelf -d /out/usr/bin/dunst | grep -q 'libwayland-client' || {
116  echo "guardián: dunst NO enlaza libwayland-client — el backend wayland no entró" >&2; exit 1; }
117if readelf -d /out/usr/bin/dunst | grep -q 'libX11'; then
118  echo "guardián: dunst enlaza libX11 — X11=0 no agarró" >&2; exit 1
119fi
120
121# ── GUARDIÁN 2: el nombre del bus, escrito en el fichero que lo activa ───────────────────────
122SVC=/out/usr/share/dbus-1/services/org.knopwob.dunst.service
123[ -f "$SVC" ] || { echo "guardián: no se instaló el .service de D-Bus — nadie lo activaría" >&2; exit 1; }
124grep -q '^Name=org.freedesktop.Notifications$' "$SVC" || {
125  echo "guardián: el .service no reclama org.freedesktop.Notifications" >&2; exit 1; }
126# Sin systemd esa línea no puede significar nada; se va para que el bus no la mire siquiera.
127sed -i '/^SystemdService=/d' "$SVC"
128
129test -x /out/usr/bin/dunstctl || { echo "guardián: falta dunstctl" >&2; exit 1; }
130# Y que NO se haya colado el emisor roto: si alguien vuelve a poner DUNSTIFY=1 sin leer el porqué
131# de arriba, esto lo frena acá y no en la pantalla de un usuario.
132if [ -e /out/usr/bin/dunstify ]; then
133  echo "guardián: se instaló dunstify — segfaultea por las dos GLib; el emisor es notify-send" >&2
134  exit 1
135fi
136echo "guardián: dunst wayland-only, y el bus lo puede activar por org.freedesktop.Notifications"
137'''
138
139[deps]
140build = ["pkgconf", "perl", "wayland", "wayland-protocols", "glib", "pango", "cairo",
141         "gdk-pixbuf", "libnotify", "pixman", "fontconfig", "freetype", "harfbuzz", "fribidi",
142         "libpng", "expat", "libffi", "pcre2", "zlib"]
143run   = ["wayland", "glib", "pango", "cairo", "gdk-pixbuf"]