Files
takana/recipes/libelogind.toml
T
SergioandClaude Opus 5 4d77d232d3 la mudanza sin terceros: las fuentes de tawasuyu por HTTPS público, y el orden del cutover
Tres cosas, y las tres quitan vueltas.

1. NO HACE FALTA NINGUNA CREDENCIAL EN EL WORKER, Y TAMPOCO UN USUARIO NUEVO

`tawasuyu/tawasuyu` y `sergio/takana` son repos PÚBLICOS en el gitea. Las 23 recetas que apuntaban a
`gitea@git.tawasuyu.net` (SSH, que exige la clave que es el SSH de todo) pasan a
`https://git.tawasuyu.net/…`. La URL es locator y NO entra en `hash_inputs` (ADR 0013): hecho con
control antes/después, **ningún ArtifactHash se movió**. Medido en el worker: `git clone --mirror
--filter=blob:none` + `git archive` extrae el árbol (155 M) **sin una sola credencial**.

Un usuario propio en gitea sólo haría falta para un repo PRIVADO; hoy ninguna receta usa uno. Si
mañana hace falta, es una cuenta de máquina con acceso al repo que toque — nunca la clave personal.

De paso, tres recetas decían «HUB-ONLY: el worker secretless recibe Connection refused». Ya no es
cierto y el comentario decía lo contrario de lo que pasa: corregido en las tres.

2. LA COPIA FUERA LA DA LA MUDANZA, NO GITHUB (decisión del usuario)

El «paso 1: espejar los 26 repos» deja de ser el paso 1. En cuanto el gitea vive en la caja nueva,
esos repos dejan de existir sólo en la máquina que se borra — que es lo que el paso pedía. El
objetivo es dejar de pagar dos máquinas, no sumar una dependencia. `espejar-repos.sh` queda como
herramienta disponible.

3. EL §9 REESCRITO: qué está hecho, qué falta y en qué orden

Hecho y cerrado: la caja arranca takana puro · store/grafos/granja/respaldo · repo firmado · la
imagen del perfil servidor con gitea sirviendo 200 supervisado por arje · `arjectl` · y el ensayo con
los datos REALES de gioser corriendo sobre takana.

Falta, en orden: actualizar la caja a la imagen nueva (`upgrade`, no `dd`) → mudar los datos del
gitea (`.backup` + rsync, con el origen parado en el corte) → caddy con los 6 dominios vivos → DNS →
verificar desde fuera con un clone real → el resto de servicios del censo → borrar gioser con las 8
puertas en verde.

Bloqueantes con su tamaño: `git` sellado sin `remote-http` (afecta a clonar DESDE una caja takana,
no al gitea que sirve; re-sella una raíz de `base`) y la puerta 5, que no bloquea la mudanza.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Tf9T4vGzsMoT7eS8YzMFn
2026-09-14 18:59:31 +00:00

83 lines
5.3 KiB
TOML

# ══ 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/
'''