Empaquetando Mozc con Bazel en Debian: Guía para Sysadmins Linux

septiembre 19, 2026 Alfonso Moreno | Sysadmin Senior 31 Visitas 7 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos para instalación, 1-2 horas para upgrade in-place.
Requisitos: Backup de /home, conexión a internet, 20+ GB libres.
Resultado: Sistema actualizado con soporte extendido, drivers funcionando.
Troubleshooting: dnf distro-sync, akmods para NVIDIA, journalctl -p err.

Por qué Mozc importa en Debian

Mozc es el editor de método de entrada japonés más usado en Linux. Lo mantiene Google, está escrito en C++, y desde hace años migró su sistema de build de GYP a Bazel. Ese cambio dejó a Debian en un limbo técnico: hasta julio de 2026 seguía empaquetando la versión 2.29.5160.102, mientras upstream iba por 3.34.6239.

El problema no era solo “actualizar versiones”. Cambiar de GYP a Bazel en un paquete Debian requiere reescribir parches, portar bindings GTK2 a GTK3, restaurar opciones de build eliminadas, y reescribir las reglas de debian/rules. Cualquier mantenedor que haya pasado por esto sabe que es un proyecto de meses, no de días.

El trabajo de Kentaro Hayashi

Kentaro Hayashi, mantenedor Debian de Mozc, publicó el 17 de septiembre de 2026 el artículo Building Mozc with dh-bazel anunciando un prototipo funcional. El contexto previo lo había detallado en julio: tras aterrizar bazel-bootstrap 7.7.1 en Debian unstable, eligió Mozc 3.33.6133 como versión objetivo — no la última 3.34.x porque requiere Bazel 9.x que aún no está en Debian.

El trabajo técnico documentado incluye:

Migración completa de GYP a Bazel usando el wrapper dh_auto_build --buildsystem=bazel.
Revisión del patch set aplicado sobre upstream (los parches que mantienen compat con Debian).
Porting de los parches de uim-mozc y fcitx5-mozc para resolver FTBFS (Fail To Build From Source).
Limpieza del src/third_party vendoreado, que arrastraba bibliotecas obsoletas.

Qué es dh-bazel y por qué hace falta

Debian tiene un patrón establecido para sistemas de build: dh-make-golang, dh-cargo, dh-rust, dh-python3. Todos extienden debhelper con reglas específicas del build system. Bazel no tenía un equivalente. Esa ausencia es exactamente lo que dh-bazel viene a llenar.

El patrón de uso es directo:

%:
	dh $@ --buildsystem=bazel
override_dh_auto_build:
	dh_auto_build -- //:hello

Si quieres compilar desde un subdirectorio src/:

%:
	dh $@
override_dh_auto_build:
	dh_auto_build --buildsystem=bazel --sourcedirectory=src -- //:hello

El cambio más visible es que la fase de build ya no invoca make, cmake o gyp, sino Bazel con opciones consistentes que dh-bazel centraliza. Eso evita que cada mantenedor invente su propio conjuro de flags.

Cómo verificar que Mozc nuevo está en tu sistema

Antes de meterte en el build, conviene saber qué versión tienes hoy y qué hay disponible. La página oficial del paquete en el tracker de Debian es tracker.debian.org/pkg/mozc y muestra el estado por release.

Para ver tu versión instalada:

apt-cache policy mozc-utils-gui
mozc --version 2>/dev/null || echo "mozc no tiene flag --version estable"

Si tu sistema muestra 2.29.5160.102 en stable y ves 3.x en experimental, es el cambio que comenta Hayashi. Para pinear experimental:

echo "deb http://deb.debian.org/debian experimental main" > /etc/apt/sources.list.d/experimental.list
apt -t experimental install mozc-utils-gui fcitx5-mozc

El -t experimental le dice a apt que solo esos paquetes vienen de ahí — tu sistema base sigue en stable. Esta es la forma estándar de probar paquetes sin tocar el resto del árbol.

Troubleshooting común

Si después del upgrade Mozc no aparece en tu sesión gráfica, lo más probable es que el daemon de input no se haya enterado del cambio. Forzá el reinicio del servicio:

# fcitx5 lee su config al arrancar
fcitx5 -r
# verifica que el módulo mozc esté disponible
fcitx5-diagnose 2>&1 | grep -A2 mozc
# Si usas ibus en lugar de fcitx5
ibus restart
ibus list-engine | grep mozc

Si el binario compila pero los diccionarios no cargan, suele faltar el paquete mozc-data como dependencia separada. Asegurate de instalarlo junto con el frontend:

apt -t experimental install mozc-data mozc-server fcitx5-mozc

Y un detalle típico: Mozc lee su diccionario del path que el binario trae hardcodeado. Si tu $HOME tiene permisos raros o estás en un home encriptado con btrfs, vas a ver el input entrar pero no producir candidatos. La señal clara: el cursor se mueve pero no aparece la barra de sugerencias. Solución habitual es exportar XDG_DATA_HOME explícito o usar un home temporal para descartar.

El estado real del empaquetado

Hayashi aclara algo importante: dh-bazel está en fase prototipo y todavía no está en Debian unstable. Su plan es:

Iterar el prototipo hasta tener feedback de otros mantenedores.
Coordinar vía la lista de correo [email protected].
Subir el paquete a Debian cuando esté maduro.

Mientras tanto, los paquetes nuevos de Mozc viven en experimental y están en fase de testing antes de moverse a testing. Eso significa que todavía no son candidatos para stable — si dependés de Mozc en producción, mantenete en 2.29.5160.102 hasta que el ciclo termine.

Para entender dónde está cada release en el ciclo de Debian:

curl -s "https://tracker.debian.org/pkg/mozc" | grep -oE 'testing|stable|experimental' | sort -u

Limitaciones que Hayashi documenta

El propio mantenedor aclara tres puntos débiles en su prototipo:

Solo simplifica dh_auto_build: la instalación de artefactos sigue requiriendo reglas manuales en .install o debian/rules. No es magia que cubre todo el pipeline.
Es un wrapper, no un reductor de fricción mágica: no elimina los parches de vendoring ni los problemas de compilación que ya tienes. Lo que hace es estandarizar cómo se invoca Bazel.
Flags extra van inline: si necesitas opciones específicas de Bazel como --override_module=, las pasás directamente. No hay abstracción que oculte la complejidad de Bazel.

Para paquetes simples — un único target //:hello — dh-bazel es casi plug-and-play. Para Mozc, con su árbol de fuentes complejo, parches históricos y bindings múltiples (uim, fcitx5, GTK), sigue requiriendo intervención manual.

Cuándo te conviene involucrarte

Este cambio no es para usuarios finales. Te interesa si:

Mantienes paquetes Debian que usan Bazel y quieres un debhelper estándar.
usas Mozc en japonés y quieres entender por qué tu distro quedó atrás en versiones.
administras un servidor con usuarios que necesitan input japonés estable.
Te interesa el ciclo de empaquetado Debian moderno — GYP es histórico, Bazel es el presente.

Si solo necesitas escribir en japonés y tu IME actual funciona, no hay urgencia. La versión 2.29 sigue siendo perfectamente funcional para uso diario.

Cómo seguir el progreso

Si quieres seguir el avance técnico, los lugares oficiales son:

El tracker de Debian para mozc — estado por release, bugs abiertos, parches en cola.
El bug 1085173 — donde Hayashi documenta el progreso de empaquetado.
La lista [email protected] — discusión de mantenedores sobre el wrapper.
El blog de Hayashi — entradas mensuales de actividades como mantenedor.

Cuando dh-bazel entre a unstable, va a simplificar el empaquetado de cualquier proyecto Bazel en Debian. Eso incluye herramientas como TensorFlow, otros proyectos de Google, y cualquier software que haya migrado del autotools a Bazel en los últimos años.

Conclusión

El trabajo de Kentaro Hayashi resuelve un problema estructural de Debian: la falta de un debhelper estándar para Bazel. Es trabajo de infraestructura — invisible para el usuario final, crítico para mantenedores que empaquetan software moderno.

Si administras sistemas Debian con paquetes que dependen de Bazel, este avance va a hacer tu vida más fácil en los próximos meses. Si solo usas Linux como escritorio y necesitas IME japonés, quedáte con lo que tienes hasta que Mozc 3.x llegue por los canales oficiales.

Preguntas frecuentes

¿Por qué Empaquetando Mozc con Bazel en Debian: Guía para Sysadmins Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Empaquetando Mozc con Bazel en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Empaquetando Mozc con Bazel en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Empaquetando Mozc con Bazel en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Empaquetando Mozc con Bazel en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.