# ══ PROMOVIDA AL CORPUS DESDE LAS COLAS (2026-09-08) ═══════════════════════════════════════════
# Existía IDÉNTICA byte a byte en 2 colas de escritorio (cosmic,gnome), con el MISMO
# ArtifactHash en todas — verificado con `takana hash` antes de mover, no deducido del nombre.
# Sube al corpus por la razón que ya escribió `xkeyboard-config`: una receta resuelve sibling-first
# y después el catálogo PADRE, nunca una cola hermana, así que **lo que comparten varias imágenes
# tiene que vivir acá o no lo alcanzan**. Aquí lo comparten 2.
#
# A diferencia de aquella, las copias de las colas SÍ se barren en el mismo movimiento: sin copia en
# el corpus no había dónde caer, y dejarlas sería mantener 2 ficheros que son el mismo hash.
# Cero rebuilds: el hash no se mueve, sólo cambia de dónde lo resuelve cada consumidor.
# libelogind — la C-ABI `sd-login` que le faltaba a la distro, implementada en arje-compat.
#
# QUÉ RESUELVE: mutter (y polkit, gcr, at-spi2-core) exigen un proveedor de logind por pkg-config —
# `libsystemd` o `libelogind`— para llamar la API C sd-login. Esa API NO es un cliente D-Bus: lee
# `/run/systemd/{sessions,users,seats}`. Los otros tres tienen perilla para esquivarla y se
# construyeron por su camino degradado; **mutter no tiene**, porque `-Dudev=false` exige
# `-Dlogind=false` (mutter/meson.build:257) y sin udev+logind no hay backend nativo KMS: no hay
# compositor de verdad, sólo anidado.
#
# POR QUÉ NO ES elogind NI UN STUB: `arje-logind-compat` ya escribe ese estado en /run/systemd (ver
# `arje_compat::login_state`). Lo único que faltaba era una librería que lo LEYERA y lo ofreciera en
# C. `arje-sdlogin-compat` hace exactamente eso — no inventa datos ni levanta un daemon paralelo.
# Empaquetar elogind sería traer un logind entero a competirle al que arje ya tiene.
#
# Corrige de paso lo que afirma el comentario de recipes/arje-logind-compat.toml («no hace falta la
# C-ABI sd-login… los escritorios consultan login1 en RUNTIME por D-Bus»): es cierto para los
# clientes D-Bus y FALSO para mutter, que la enlaza.
#
# YA NO ES HUB-ONLY (2026-09-14): la fuente pasó a `https://git.tawasuyu.net/…`, que el gitea sirve
# PÚBLICO y sin credencial. Antes apuntaba al SSH de la gitea (puerto 2345) y el worker —que no
# tiene ni debe tener esa clave— no podía construirla. La URL es locator y NO entra en
# `hash_inputs` (ADR 0013): se cambió con control y NINGÚN ArtifactHash se movió.
name    = "libelogind"
version = "0.0.1"
license = "MIT"

[source]
# El `commit` es el identificador inmutable; la URL es sólo locator y NO entra al ArtifactHash.
# Rama `selfhost/arje-zero-attest-lockfile`, igual que arje-logind-compat, porque es la única que
# versiona el `Cargo.lock` de la raíz: sin él, el vendoreo `--locked` del fetch no es reproducible
# (el monorepo lo gitignora en main).
repo   = "https://git.tawasuyu.net/tawasuyu/tawasuyu.git"
commit = "749edfe41766e098d3eb18561c6a396610c5cd8e"
# El monorepo COMMITEA su propio `vendor/` (`[patch.crates-io] smithay = { path = "vendor/smithay" }`,
# la copia parcheada que mirada necesita para el tearing) y el `cargo vendor` de takana escribe ahí
# por defecto, pisándolo: el build muere con `failed to read /src/vendor/smithay/.cargo-checksum.json`
# al resolver la dep git de taffy. Se vendorea a un subdir aparte, igual que arje-logind-compat.
# Apareció recién ahora porque el `vendor/` entró a esta rama con el merge de main, no antes.
# Ver [[takana-cargo-vendor-clobbers-project-vendor]].
cargo_vendor_dir = ".hammer-cargo-vendor"

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
# dynamic, no static: el producto ES una librería compartida (cdylib). Con `link = "static"` el lab
# exporta -static y no hay .so que valga.
link     = "dynamic"
flags    = ["-p", "arje-sdlogin-compat"]

[build.phases]
# Sólo se sobrescribe `install`: el `compile` por defecto del lab (cargo build --release, offline y
# vendoreado) es el correcto. El default de Cargo copia EJECUTABLES a /usr/bin, y acá no hay ninguno:
# hay una .so, una cabecera y un .pc.
#
# El SONAME (libelogind.so.0) lo fija el build.rs del crate, no esta receta, para que un `cargo build`
# a mano también produzca algo enlazable. Por eso el fichero se instala directamente con ese nombre y
# el `libelogind.so` es el symlink de desarrollo que busca el linker.
#
# La cabecera va a /usr/include/elogind/systemd/ y el .pc trae `-I${includedir}/elogind`: así el
# `#include <systemd/sd-login.h>` de mutter resuelve sin que mutter sepa que somos nosotros. Es el
# mismo arreglo de elogind upstream.
install = '''
set -e
mkdir -p /out/usr/lib/pkgconfig /out/usr/include/elogind/systemd
cp target/release/libelogind.so /out/usr/lib/libelogind.so.0
ln -s libelogind.so.0 /out/usr/lib/libelogind.so
cp 03_ukupacha/arje/arje-sdlogin-compat/include/systemd/sd-login.h /out/usr/include/elogind/systemd/
# sd-daemon.h va aparte porque en systemd también son dos cabeceras y quien la usa la pide por su
# nombre: gdm hace `#include <systemd/sd-daemon.h>` en common/gdm-log.c para `sd_booted()`.
cp 03_ukupacha/arje/arje-sdlogin-compat/include/systemd/sd-daemon.h /out/usr/include/elogind/systemd/
cp 03_ukupacha/arje/arje-sdlogin-compat/pkgconfig/libelogind.pc /out/usr/lib/pkgconfig/
'''