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# YA NO ES HUB-ONLY (2026-09-14): la fuente pasó a `https://git.tawasuyu.net/…`, que el gitea sirve
30# PÚBLICO y sin credencial. Antes apuntaba al SSH de la gitea (puerto 2345) y el worker —que no
31# tiene ni debe tener esa clave— no podía construirla. La URL es locator y NO entra en
32# `hash_inputs` (ADR 0013): se cambió con control y NINGÚN ArtifactHash se movió.
33name    = "libelogind"
34version = "0.0.1"
35license = "MIT"
36
37[source]
38# El `commit` es el identificador inmutable; la URL es sólo locator y NO entra al ArtifactHash.
39# Rama `selfhost/arje-zero-attest-lockfile`, igual que arje-logind-compat, porque es la única que
40# versiona el `Cargo.lock` de la raíz: sin él, el vendoreo `--locked` del fetch no es reproducible
41# (el monorepo lo gitignora en main).
42repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
43commit = "619431cac9753cd55d0f9e2d99ff8efe7fab651b"
44# El monorepo COMMITEA su propio `vendor/` (`[patch.crates-io] smithay = { path = "vendor/smithay" }`,
45# la copia parcheada que mirada necesita para el tearing) y el `cargo vendor` de takana escribe ahí
46# por defecto, pisándolo: el build muere con `failed to read /src/vendor/smithay/.cargo-checksum.json`
47# al resolver la dep git de taffy. Se vendorea a un subdir aparte, igual que arje-logind-compat.
48# Apareció recién ahora porque el `vendor/` entró a esta rama con el merge de main, no antes.
49# Ver [[takana-cargo-vendor-clobbers-project-vendor]].
50cargo_vendor_dir = ".hammer-cargo-vendor"
51
52[build]
53compiler = "zig-cc"
54target   = "x86_64-linux-musl"
55# dynamic, no static: el producto ES una librería compartida (cdylib). Con `link = "static"` el lab
56# exporta -static y no hay .so que valga.
57link     = "dynamic"
58flags    = ["-p", "arje-sdlogin-compat"]
59
60[build.phases]
61# Sólo se sobrescribe `install`: el `compile` por defecto del lab (cargo build --release, offline y
62# vendoreado) es el correcto. El default de Cargo copia EJECUTABLES a /usr/bin, y acá no hay ninguno:
63# hay una .so, una cabecera y un .pc.
64#
65# El SONAME (libelogind.so.0) lo fija el build.rs del crate, no esta receta, para que un `cargo build`
66# a mano también produzca algo enlazable. Por eso el fichero se instala directamente con ese nombre y
67# el `libelogind.so` es el symlink de desarrollo que busca el linker.
68#
69# La cabecera va a /usr/include/elogind/systemd/ y el .pc trae `-I${includedir}/elogind`: así el
70# `#include <systemd/sd-login.h>` de mutter resuelve sin que mutter sepa que somos nosotros. Es el
71# mismo arreglo de elogind upstream.
72install = '''
73set -e
74mkdir -p /out/usr/lib/pkgconfig /out/usr/include/elogind/systemd
75cp target/release/libelogind.so /out/usr/lib/libelogind.so.0
76ln -s libelogind.so.0 /out/usr/lib/libelogind.so
77cp 03_ukupacha/arje/arje-sdlogin-compat/include/systemd/sd-login.h /out/usr/include/elogind/systemd/
78# sd-daemon.h va aparte porque en systemd también son dos cabeceras y quien la usa la pide por su
79# nombre: gdm hace `#include <systemd/sd-daemon.h>` en common/gdm-log.c para `sd_booted()`.
80cp 03_ukupacha/arje/arje-sdlogin-compat/include/systemd/sd-daemon.h /out/usr/include/elogind/systemd/
81cp 03_ukupacha/arje/arje-sdlogin-compat/pkgconfig/libelogind.pc /out/usr/lib/pkgconfig/
82'''