sergio/takana

1# ══ PROMOVIDA AL CORPUS DESDE LAS COLAS (2026-09-08) ═══════════════════════════════════════════
2# Existía IDÉNTICA byte a byte en 2 colas de escritorio (cosmic,gnome), con el MISMO
3# ArtifactHash en todas — verificado con `takana hash` antes de mover, no deducido del nombre.
4# Sube al corpus por la razón que ya escribió `xkeyboard-config`: una receta resuelve sibling-first
5# y después el catálogo PADRE, nunca una cola hermana, así que **lo que comparten varias imágenes
6# tiene que vivir acá o no lo alcanzan**. Aquí lo comparten 2.
7#
8# A diferencia de aquella, las copias de las colas SÍ se barren en el mismo movimiento: sin copia en
9# el corpus no había dónde caer, y dejarlas sería mantener 2 ficheros que son el mismo hash.
10# Cero rebuilds: el hash no se mueve, sólo cambia de dónde lo resuelve cada consumidor.
11# libelogind — la C-ABI `sd-login` que le faltaba a la distro, implementada en arje-compat.
12#
13# QUÉ RESUELVE: mutter (y polkit, gcr, at-spi2-core) exigen un proveedor de logind por pkg-config —
14# `libsystemd` o `libelogind`— para llamar la API C sd-login. Esa API NO es un cliente D-Bus: lee
15# `/run/systemd/{sessions,users,seats}`. Los otros tres tienen perilla para esquivarla y se
16# construyeron por su camino degradado; **mutter no tiene**, porque `-Dudev=false` exige
17# `-Dlogind=false` (mutter/meson.build:257) y sin udev+logind no hay backend nativo KMS: no hay
18# compositor de verdad, sólo anidado.
19#
20# POR QUÉ NO ES elogind NI UN STUB: `arje-logind-compat` ya escribe ese estado en /run/systemd (ver
21# `arje_compat::login_state`). Lo único que faltaba era una librería que lo LEYERA y lo ofreciera en
22# C. `arje-sdlogin-compat` hace exactamente eso — no inventa datos ni levanta un daemon paralelo.
23# Empaquetar elogind sería traer un logind entero a competirle al que arje ya tiene.
24#
25# Corrige de paso lo que afirma el comentario de recipes/arje-logind-compat.toml («no hace falta la
26# C-ABI sd-login… los escritorios consultan login1 en RUNTIME por D-Bus»): es cierto para los
27# clientes D-Bus y FALSO para mutter, que la enlaza.
28#
29# HUB-ONLY, como toda receta de fuente tawasuyu: la gitea escucha en :2345 y el worker efímero es
30# secretless ⇒ recibe Connection refused en :22. Se muele en el hub.
31name    = "libelogind"
32version = "0.0.1"
33license = "MIT"
34
35[source]
36# El `commit` es el identificador inmutable; la URL es sólo locator y NO entra al ArtifactHash.
37# Rama `selfhost/arje-zero-attest-lockfile`, igual que arje-logind-compat, porque es la única que
38# versiona el `Cargo.lock` de la raíz: sin él, el vendoreo `--locked` del fetch no es reproducible
39# (el monorepo lo gitignora en main).
40repo   = "gitea@git.tawasuyu.net:tawasuyu/tawasuyu.git"
41commit = "749edfe41766e098d3eb18561c6a396610c5cd8e"
42# El monorepo COMMITEA su propio `vendor/` (`[patch.crates-io] smithay = { path = "vendor/smithay" }`,
43# la copia parcheada que mirada necesita para el tearing) y el `cargo vendor` de takana escribe ahí
44# por defecto, pisándolo: el build muere con `failed to read /src/vendor/smithay/.cargo-checksum.json`
45# al resolver la dep git de taffy. Se vendorea a un subdir aparte, igual que arje-logind-compat.
46# Apareció recién ahora porque el `vendor/` entró a esta rama con el merge de main, no antes.
47# Ver [[takana-cargo-vendor-clobbers-project-vendor]].
48cargo_vendor_dir = ".hammer-cargo-vendor"
49
50[build]
51compiler = "zig-cc"
52target   = "x86_64-linux-musl"
53# dynamic, no static: el producto ES una librería compartida (cdylib). Con `link = "static"` el lab
54# exporta -static y no hay .so que valga.
55link     = "dynamic"
56flags    = ["-p", "arje-sdlogin-compat"]
57
58[build.phases]
59# Sólo se sobrescribe `install`: el `compile` por defecto del lab (cargo build --release, offline y
60# vendoreado) es el correcto. El default de Cargo copia EJECUTABLES a /usr/bin, y acá no hay ninguno:
61# hay una .so, una cabecera y un .pc.
62#
63# El SONAME (libelogind.so.0) lo fija el build.rs del crate, no esta receta, para que un `cargo build`
64# a mano también produzca algo enlazable. Por eso el fichero se instala directamente con ese nombre y
65# el `libelogind.so` es el symlink de desarrollo que busca el linker.
66#
67# La cabecera va a /usr/include/elogind/systemd/ y el .pc trae `-I${includedir}/elogind`: así el
68# `#include <systemd/sd-login.h>` de mutter resuelve sin que mutter sepa que somos nosotros. Es el
69# mismo arreglo de elogind upstream.
70install = '''
71set -e
72mkdir -p /out/usr/lib/pkgconfig /out/usr/include/elogind/systemd
73cp target/release/libelogind.so /out/usr/lib/libelogind.so.0
74ln -s libelogind.so.0 /out/usr/lib/libelogind.so
75cp 03_ukupacha/arje/arje-sdlogin-compat/include/systemd/sd-login.h /out/usr/include/elogind/systemd/
76# sd-daemon.h va aparte porque en systemd también son dos cabeceras y quien la usa la pide por su
77# nombre: gdm hace `#include <systemd/sd-daemon.h>` en common/gdm-log.c para `sd_booted()`.
78cp 03_ukupacha/arje/arje-sdlogin-compat/include/systemd/sd-daemon.h /out/usr/include/elogind/systemd/
79cp 03_ukupacha/arje/arje-sdlogin-compat/pkgconfig/libelogind.pc /out/usr/lib/pkgconfig/
80'''