main
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  sergioandClaude Opus 5
|
427ca1dd01 |
wl-clipboard 2.2.1 SELLADA — cierra el entorno mínimo del frente wlr
`wl-copy` y `wl-paste`. En Wayland no hay forma de copiar o pegar desde un script sin esto, y
varios flujos que ya sellamos lo necesitan para ser útiles: capturar con grim, seleccionar
región con slurp, y poder pegar el resultado en algún lado.
UNA DIFERENCIA CON LAS ANTERIORES QUE CONVIENE NOTAR. Va por commit (ADR 0006, GitHub genera
sus archive/refs/tags al vuelo igual que codeberg), pero este tag es **LIGERO**: `git ls-remote`
devuelve UN solo sha y ése ES el commit. En fuzzel, yambar y foot los tags son ANOTADOS y
aparecen dos, donde el bueno es el `^{}`. Comprobar el tipo de tag antes de copiar evita pinear
el objeto del tag en vez del commit — un error silencioso, porque la receta valida y sólo falla
después, al no encontrar el árbol.
TRAE `subprojects/` CON WRAPS QUE BAJAN DE LA RED (expat, libffi, wayland, wayland-protocols).
`--wrap-mode=nodownload` es lo que lo impide y lo obliga a usar las del sistema, o sea nuestros
artefactos vía pkg-config. Sin esa flag el build intentaría salir a internet DENTRO del sandbox
hermético y moriría; con ella los wraps quedan inertes. Por eso las cuatro van en deps.
Estado del frente wlr: 10 recetas, 12 binarios — wlroots, sway (+swaybar/swaymsg/swaynag),
swaybg, swayidle, swaylock, grim, slurp, fuzzel, yambar, wl-copy/wl-paste. Con `foot` (ya en el
corpus) como terminal, el perfil «escritorio-sway» es armable: compositor, barra, lanzador,
fondo, bloqueo, inactividad, captura y portapapeles. Todo sin X11 y sin systemd.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
3545ea77fa |
fuzzel + yambar SELLADAS — y waybar queda fuera POR MEDICIÓN, no por gusto
Lanzador y barra de estado: las dos piezas que faltaban para que un WM ligero se use de
verdad y no sólo arranque. El frente wlr suma 9 recetas y 11 binarios.
WAYBAR NO ENTRA, Y CONVIENE QUE CONSTE POR QUÉ. Medidas sus dependencias reales (0.12.0):
pide `gtkmm-3.0` — o sea GTK**3** *y además* sus bindings de C++ — más gtk-layer-shell,
jsoncpp, fmt, spdlog, sigc++, date y libnl. Es el mismo muro de GTK3 que el frente GNOME
aparcó a propósito, con ocho recetas nuevas encima. `yambar` es C puro, del mismo autor que
foot/fcft/fuzzel, y **sus dependencias ya estaban selladas**: es el bar estándar de esa
familia, no un sustituto pobre. Si algún día entra GTK3, waybar vuelve a estar sobre la mesa.
FUENTE GIT POR COMMIT, no el archive de codeberg (ADR 0006). Es el criterio que ya usan foot y
fcft, con la razón medida allí: el `/archive/<tag>.tar.gz` lo genera la forge AL VUELO, así que
sus bytes dependen de la versión de git/gzip del servidor y el sha256 pineado se muere solo
cuando codeberg actualiza su tooling. ⚠ Y los tags son ANOTADOS: el sha de `refs/tags/1.12.0`
NO es el commit; hay que pinear el `^{}` desreferenciado. Lo verifiqué con `git ls-remote`
antes de escribir, porque los dos shas aparecen juntos y es fácil copiar el equivocado.
DOS DEPS DE BUILD-TIME QUE NO SE VEN EN EL BINARIO Y MATAN EL BUILD:
· `scdoc` (las dos) — generan sus man pages con él y, a diferencia de sway/swaybg/grim, NO
ofrecen `-Dman-pages` para saltárselo. Estaba en el corpus: la vía correcta es declararlo,
no buscar cómo evitarlo.
· `flex` + `bison` (yambar) — generan el parser de su lenguaje de partículas. Invisibles en el
resultado, y del tipo que se olvida hasta que el build muere con «Program 'flex' not found».
`-Dbackend-x11=disabled` en yambar evita SIETE dependencias de X11 (xcb-aux, xcb-cursor,
xcb-errors, xcb-event, xcb-ewmh, xcb-randr, xcb-render) para un backend que en una distro
Wayland pura no se usa nunca. Y en fuzzel, `-Dsvg-backend=nanosvg` (el default, vendorizado)
evita librsvg, que arrastraría la cadena de GNOME/Rust por unos iconos.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
50b080d258 |
accesorios wlroots: swaybg, swayidle, swaylock, grim y slurp — 5 selladas
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> |
||
|
sergioandClaude Opus 5
|
f7aafc9d26 |
sway 1.10 SELLADA — primer compositor Wayland ligero del catálogo
b3:ae10753a5467f3642464aaad0b1b41135b8c51972091042baf0d09134af46c7e · sway, swaybar,
swaymsg y swaynag. Construido en el worker sobre el wlroots 0.18.2 sellado hace un rato
(sway 1.10 pide `wlroots-0.18` explícitamente: no es una versión cualquiera, es LA que casa).
XWAYLAND SE HEREDA, NO SE PASA. sway no tiene perilla propia: lee las variables del .pc de
wlroots (`xcb = wlroots_features['xwayland'] ? dependency('xcb') : null_dep`). Como nuestro
wlroots se selló con have_xwayland=false, sway se salta xcb y xcb-icccm solo. Para eso servía
haber inspeccionado esas variables al verificar el artefacto anterior. Si algún día se quiere
Xwayland, se cambia en wlroots, no acá.
TRES COSAS QUE SALIERON AL CONSTRUIR, y ninguna estaba en sway:
1. `json-c` NO DECLARABA NADA y sellaba igual — porque el rootfs del laptop trae cmake y make
y el sandbox los tomaba «de prestado». En el worker muere con `cmake: not found` (exit 127,
el mismo código que engaña con meson). Una receta que sólo construye en la máquina del autor
es una bomba de relojería. Declarados cmake+make+pkgconf; el arreglo es declarar, NUNCA
engordar el rootfs del worker. Re-hashea json-c y su único dependiente, que es sway: gratis.
Salió a la luz construyendo sway, o sea que el fallo estaba a tres niveles de donde miraba.
2. 45 SÍMBOLOS INDEFINIDOS AL ENLAZAR, todos `XML_*` — expat, y sólo expat (clasificada la
lista completa, no adivinado por el primero). sway no usa expat: lo usa `fontconfig`, que en
el corpus es estático, y su `.a` trae las llamadas sin resolver. `fontconfig.pc` lo declara
en `Requires.private`, que es la línea que pkg-config sólo expande en resolución ESTÁTICA, y
meson llama a dependency('cairo') en modo normal. No es un fallo de fontconfig ni de cairo:
es donde el modelo de pkg-config y el enlace estático no encajan. Resuelto con
`-Dc_link_args=-lexpat`; como los indefinidos eran de UN solo prefijo, se sabe que no falta
nada más.
3. `-Dtray=disabled` esquiva la única dep que nos falta de verdad. La bandeja habla sd-bus y
sway ofrece tres proveedores (libsystemd | libelogind | basu): no hay systemd por decisión,
`basu` no está en el catálogo, y el `libelogind` que sí tenemos NO sirve — es la
reimplementación propia de la C-ABI sd-login de arje-compat, no un sd-bus. Misma trampa del
nombre que ya mordió con `knighttime`. Traer basu es un ticket aparte y pequeño.
Con esto el frente de WMs ligeros deja de ser un hueco: había 0 compositores y ahora hay uno
que arranca desde wlroots propio, sin X11 y sin systemd.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
sergioandClaude Opus 5
|
c13d25f02b |
wlroots 0.18.2 SELLADA — el desbloqueo del frente de WMs Wayland ligeros
Primera receta del frente nuevo. wlroots es la biblioteca de la que cuelgan casi todos los
compositores ligeros (sway, labwc, river, hyprland): sin ella no hay ninguno, y con ella los
compositores salen baratos porque no traen torre de C debajo. Hasta hoy el catálogo tenía de
toda esa familia sólo `foot` y `mako`.
b3:9b56bac0d00977524072cf393ecc9f0b847fcc1a0bfba9d9c4d57fd9a4a74b44 · 13 MB · construida en
el worker (cadena GUI: no se rebuildea en el laptop por el zig-skew).
COLA AISLADA `incoming-wlr/`, porque otro agente comparte el repo. Como la resolución de deps
es hermano→padre, una receta de acá ve el corpus pero NO ve `incoming-gnome/`, donde viven
`libdisplay-info` y `hwdata` ⇒ se copian como hermanas. No duplica trabajo: los ficheros son
idénticos, el ArtifactHash es el mismo y el build hace cache-hit. Verificado antes de
construir: ambas dan el mismo b3: que su original.
LAS OPCIONES, VERIFICADAS CONTRA EL meson_options.txt DEL TARBALL, no de memoria — porque una
opción `-D` inventada NO se ignora: meson aborta en la primera desconocida. Es exactamente lo
que tenía muerta a gnome-session con su `-Dsystemd=false`. El `.pc` resultante confirma que
salió lo pedido: have_drm_backend=true, have_libinput_backend=true, have_gles2_renderer=true,
have_gbm_allocator=true, have_session=true, y have_x11_backend / have_xwayland en FALSE —
la distro es Wayland pura y X11 es deuda aparcada por diseño; no entra por la puerta de atrás.
DOS COSAS QUE COSTARON UNA ITERACIÓN CADA UNA:
· `-Dwerror=false` no es pereza, es DIFERENCIA DE TOOLCHAIN. wlroots compila con -Werror y
upstream lo valida con gcc; nuestro `zig cc` es clang y avisa de lo que gcc calla. Murió en
`types/wlr_shm.c:503` por `-Wunused-but-set-variable` sobre has_argb8888/has_xrgb8888 —
código correcto que sólo clang señala. Tratar los avisos de OTRO compilador como errores del
proyecto es un fallo de método, no un hallazgo de calidad.
· `libffi`, `expat` y `zlib` en deps aunque wlroots no los use: los exigen los `.pc` de wayland
y mesa en su `Requires`, y pkgconf resuelve el grafo de .pc completo antes de dar un cflag.
Misma lección que wlr-randr esta mañana.
El artefacto trae `libwlroots-0.18.{a,so}`, su .pc y 111 cabeceras bajo
`usr/include/wlroots-0.18/wlr/`. Listo para que sway enlace contra él.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|