sergio/takana

La receta hacía `b2 … stage` y copiaba cabeceras y la .a con cp, así que boost
NO se podía encontrar en modo CONFIG: `stage` sólo deja binarios en stage/lib y
no genera el paquete cmake. Nunca se notó porque el único consumidor existente,
kactivitymanagerd, lo busca en modo MÓDULO (el FindBoost de cmake, que trabaja
por cabeceras y bibliotecas sueltas).

libime lo pide con CONFIG EXPLÍCITO (CMakeLists:45), y con eso cmake no usa
FindBoost nunca:

    Could not find a package configuration file provided by "Boost"
      (requested) BoostConfig.cmake / boost-config.cmake

`b2 install` sí lo genera — comprobado en upstream que boost_install trae
BoostConfig.cmake en el tag 1.86.0 — y el guardián EXIGE las dos piezas, no una:
BoostConfig.cmake y boost_iostreams-config.cmake, porque el config puede existir
sin que `COMPONENTS iostreams` resuelva y eso sellaría un artefacto que falla
dentro del consumidor.

`--prefix=/out/usr` y no DESTDIR: b2 no honra DESTDIR, es su propio sistema de
build. Los configs calculan sus rutas relativas a sí mismos, así que no se
quedan con /out pegado.

Radio medido antes de tocarlo: 3 consumidores, y dos son recetas nuevas sin
construir ⇒ el coste real es un rebuild de kactivitymanagerd.

Verificado: sella con Boost-1.86.0/BoostConfig.cmake.

Y de paso una cifra que afirmé mal: dije «fcitx5 tiene 20 addons, eran 17 en
5.1.14» y los dos tienen 20 — el 17 era de antes de ENABLE_TESTING_ADDONS=On.
El conjunto de addons no cambia con el salto. Un comentario no entra en el
ArtifactHash (comprobado en los dos sentidos), así que la corrección no rehace
nada.

diff --git a/recipes/boost.toml b/recipes/boost.toml
index b5ef4cb0..d0a9129e 100644
--- a/recipes/boost.toml
+++ b/recipes/boost.toml
@@ -56,20 +56,47 @@ set -e
 '''
 install = '''
 set -e
-mkdir -p /out/usr/include /out/usr/lib
-cp -r boost /out/usr/include/
-# La `.a` de iostreams es la razón de esta receta, así que el guardián es duro.
+# ⚠ **`b2 install`, NO un `cp` a mano — y la diferencia es `BoostConfig.cmake`.**
+#
+# Esta receta copiaba las cabeceras y la `.a` con `cp` tras un `b2 stage`, y así **boost no se podía
+# encontrar en modo CONFIG**: `stage` sólo deja los binarios en `stage/lib`, no genera el paquete
+# cmake. Eso no se notó mientras el único consumidor fue `kactivitymanagerd`, que lo busca en modo
+# MÓDULO (el `FindBoost.cmake` de cmake, que trabaja por cabeceras y bibliotecas sueltas).
+#
+# `libime` lo pide así, y el `CONFIG` es EXPLÍCITO:
+#
+#     find_package(Boost 1.61 CONFIG REQUIRED COMPONENTS iostreams)    ← CMakeLists:45
+#
+# Con `CONFIG`, cmake **no usa `FindBoost` nunca**: exige un `BoostConfig.cmake`. El fallo era
+#
+#     Could not find a package configuration file provided by "Boost"
+#       (requested) BoostConfig.cmake / boost-config.cmake
+#
+# ⇒ `b2 install` sí lo genera (lo hace `tools/boost_install` desde boost 1.70). **No se asume: el
+# guardián de abajo lo exige**, porque si upstream lo cambiara el artefacto se sellaría igual y el
+# fallo saldría dentro de libime, culpando a libime de algo que es de acá.
+#
+# `--prefix=/out/usr` en vez de `DESTDIR`: b2 **no honra `DESTDIR`** (es su propio sistema de build,
+# no make). Los configs que genera calculan sus rutas relativas a sí mismos, así que son
+# reubicables y no se quedan con `/out` pegado.
+./tools/build/src/engine/b2 -j"$(nproc)" toolset=clang --with-iostreams \
+  link=static runtime-link=static -sNO_BZIP2=1 -sNO_LZMA=1 -sNO_ZSTD=1 --prefix=/out/usr install
+
 n=0
-for f in stage/lib/libboost_iostreams*.a; do
-  [ -f "$f" ] || continue
-  cp "$f" /out/usr/lib/; n=$((n+1))
-done
+for f in /out/usr/lib/libboost_iostreams*.a; do [ -f "$f" ] && n=$((n+1)); done
 if [ "$n" -eq 0 ]; then
-  echo "boost: b2 no produjo libboost_iostreams*.a — esta receta existe para eso, NO sello" >&2
-  ls -R stage 2>/dev/null | head -20 >&2
+  echo "boost: b2 no instaló libboost_iostreams*.a — esta receta existe para eso, NO sello" >&2
+  ls -R /out/usr/lib 2>/dev/null | head -20 >&2
   exit 1
 fi
-echo "boost: cabeceras + $n lib(s) de iostreams"
+[ -f /out/usr/include/boost/version.hpp ] || { echo "boost: faltan las cabeceras (include/boost/version.hpp)" >&2; exit 1; }
+# El guardián nuevo, y el motivo de este cambio: el paquete cmake.
+cfg=$(find /out/usr/lib/cmake -name 'BoostConfig.cmake' 2>/dev/null | head -1)
+[ -n "$cfg" ] || { echo "boost: no quedó ningún BoostConfig.cmake — un consumidor con find_package(Boost CONFIG) no lo encontraría (es lo que pide libime)" >&2; find /out/usr/lib -maxdepth 2 -type d 2>/dev/null | head -20 >&2; exit 1; }
+# Y el componente: el config puede existir sin que `COMPONENTS iostreams` resuelva.
+comp=$(find /out/usr/lib/cmake -name 'boost_iostreams-config.cmake' 2>/dev/null | head -1)
+[ -n "$comp" ] || { echo "boost: hay BoostConfig.cmake pero no boost_iostreams-config.cmake — find_package(... COMPONENTS iostreams) fallaría" >&2; ls -R /out/usr/lib/cmake 2>/dev/null | head -30 >&2; exit 1; }
+echo "boost: cabeceras + $n lib(s) de iostreams + $(basename "$(dirname "$cfg")")/BoostConfig.cmake"
 '''
 
 [deps]
diff --git a/recipes/fcitx5-anthy.toml b/recipes/fcitx5-anthy.toml
index 3afdb1f4..034ffad9 100644
--- a/recipes/fcitx5-anthy.toml
+++ b/recipes/fcitx5-anthy.toml
@@ -18,7 +18,7 @@
 # `fcitx5-qt-dev` de Alpine será de algún subpaquete suyo; acá no hace falta. ⇒ japonés = 1 receta.
 #
 # `Fcitx5Module COMPONENTS Clipboard TestFrontend`: las dos las publica nuestro `fcitx5` —
-# `libclipboard.so` está entre sus 17 addons, y `TestFrontend` existe porque el 20-oct hubo que
+# `libclipboard.so` está entre sus 20 addons, y `TestFrontend` existe porque el 20-oct hubo que
 # poner `ENABLE_TESTING_ADDONS=On` (una perilla que parecía de test y publicaba interfaz).
 #
 # ⚠ `link = "dynamic"` obligatorio, como todo addon de fcitx5: es un `.so` que el daemon carga con