sergioandClaude Opus 5
50b080d258
Con esto el frente de WMs ligeros pasa de «hay un compositor» a «se puede usar»: fondo de escritorio, apagado por inactividad, bloqueo de pantalla y captura por región. Sumado a sway y wlroots, el frente tiene hoy 7 recetas y 9 binarios (sway swaybar swaymsg swaynag swaybg swayidle swaylock grim slurp), todos sin X11 y sin systemd. CADA FALLO FUE DE UNA CLASE DISTINTA, y ninguno del paquete que estaba escribiendo: · swayidle — pasé `-Dsd-bus-provider=none` porque es la opción que tiene SWAY. En swayidle 1.9.0 no existe: la suya se llama `logind`. **Las perillas no se heredan entre proyectos hermanos aunque resuelvan lo mismo**; hay que leer el meson_options.txt de CADA uno. Tercera vez hoy que una opción inventada mata un build (gnome-session, y ahora ésta). · grim — `undefined symbol: crc32`, o sea zlib. No lo usa grim: lo usa `libpng`, cuyo `.pc` declara zlib en `Requires.private`, la línea que pkg-config sólo expande en resolución estática. Es la MISMA causa que el `-lexpat` de sway (allí vía fontconfig), sobre otra biblioteca. Ya van dos casos ⇒ es un patrón del corpus, no un accidente: enlazar contra una lib estática cuyo .pc tiene Requires.private exige añadir esas libs a mano. · slurp — le faltaba `libxkbcommon` en deps, sin más. DOS COSAS QUE VALE GUARDAR: 1. EL TARBALL DE slurp CASI ENVENENA LA RECETA. La URL de releases de GitLab devolvió **HTTP 200 con una página HTML** en vez del archivo, así que `curl -f` no falló y el sha256sum que saqué era el de un documento HTML. Pinearlo habría dado una receta que descarga «algo» con hash correcto y no construye jamás, con un error incomprensible. Se cazó verificando el FORMATO (`tar tzf`), no el código de salida — misma lección que el `rm` que devuelve 0 sin borrar y el proceso vivo que no avanza. El sha256 correcto es el del tarball de GitHub. 2. PAM NO ESTABA BLOQUEADO. «PAM» figura entre las tres deudas aparcadas del frente GNOME, así que lo natural era dar swaylock por imposible. Pero en swaylock PAM es una OPCIÓN (cae a `crypt` si falta) y sobre todo **`linux-pam` SÍ está en el corpus**: lo aparcado era la integración de PAM del stack GNOME, no la biblioteca. ⇒ Una deuda «aparcada» nombra un frente concreto, no una palabra; conviene verificar antes de heredar el veto. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
44 lines
2.5 KiB
TOML
44 lines
2.5 KiB
TOML
# swaylock 1.8.0 — el bloqueo de pantalla. Junto a swayidle cierra el ciclo «me levanto de la
|
|
# máquina y queda protegida», que es requisito para usar la distro en serio, no sólo demostrarla.
|
|
#
|
|
# ── PAM SÍ SE PUEDE, Y CONVIENE MIRARLO DOS VECES ──────────────────────────────────────────────
|
|
# «PAM» figura entre las tres deudas aparcadas del frente GNOME, así que la reacción natural es
|
|
# darlo por bloqueado. Pero acá no lo está, por dos razones comprobadas:
|
|
# · en swaylock PAM es una OPCIÓN, no un requisito:
|
|
# libpam = cc.find_library('pam', required: get_option('pam'))
|
|
# crypt = cc.find_library('crypt', required: not libpam.found())
|
|
# o sea que sin PAM cae a `crypt`, que valida contra /etc/shadow.
|
|
# · y además **`linux-pam` SÍ está en el corpus** — lo que estaba aparcado era la integración de
|
|
# PAM del stack GNOME, no la biblioteca.
|
|
# ⇒ Se activa PAM, que es la vía correcta para autenticar en un sistema real. La lección: una deuda
|
|
# «aparcada» nombra un frente concreto, no una palabra; conviene verificar antes de heredar el veto.
|
|
name = "swaylock"
|
|
version = "1.8.0"
|
|
license = "MIT"
|
|
|
|
[source]
|
|
tarball = "https://github.com/swaywm/swaylock/releases/download/v1.8.0/swaylock-1.8.0.tar.gz"
|
|
sha256 = "6a1175442380b87b2d2868c4a5366ee3592163158d02e3a7fbf3a0bfe07d8b00"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "dynamic"
|
|
zig_version = "0.13.0"
|
|
|
|
[build.phases]
|
|
configure = "meson setup output --prefix=/usr --buildtype=release --wrap-mode=nodownload -Dwerror=false -Dman-pages=disabled -Dpam=enabled -Dgdk-pixbuf=enabled -Dc_link_args=-lexpat"
|
|
compile = "ninja -C output"
|
|
install = "DESTDIR=/out ninja -C output install"
|
|
|
|
[deps]
|
|
build = ["meson", "samurai", "python3", "pkgconf", "wayland", "wayland-protocols", "libxkbcommon",
|
|
"cairo", "gdk-pixbuf", "pixman", "glib", "fontconfig", "freetype", "libpng",
|
|
"libjpeg-turbo", "libtiff", "expat", "libffi", "pcre2", "zlib", "harfbuzz", "fribidi",
|
|
"linux-pam"]
|
|
# `xkeyboard-config` NO va acá aunque parezca: la propia receta de libxkbcommon lo dice en su
|
|
# cabecera — «en runtime usa los datos de xkeyboard-config; no es dep de build». Y además sólo
|
|
# existe en las colas de escritorio, no en el corpus. Lo apunto porque para que el teclado tenga
|
|
# distribución correcta en una imagen real hará falta incluirlo por el lado del perfil, no de aquí.
|
|
run = ["wayland", "cairo", "libxkbcommon", "linux-pam"]
|