Testing Japanese IMEs on virtual desktops with virt-japanese-desktop

Japanese input method editors (IMEs) such as Mozc are essential for typing Japanese (yes, skk, anthy and more, but it's out-of-scope in this article). Testing them is a surprisingly fiddly job: an IME behaves differently depending on the desktop environment (GNOME, KDE, Xfce, Budgie), the input framework (ibus, fcitx5, uim), and the Wayland or X11 session. Setting up a fresh VM for every combination from scratch is slow and repetitive, and breaking your host's environment while experimenting is no fun.

virt-japanese-desktop is a small set of toy scripts that solves exactly this problem. It builds ready-to-use virtual machines - each with a desktop environment and a Japanese IME already installed and configured - so you can start typing Japanese within a minute of booting, and throw the whole thing away without any impact on your host.

What it gives you

A single make command produces a qcow2 image that combines one of four desktops with one of three IMEs:

ibus-mozc fcitx5-mozc uim-mozc
GNOME ✓ ✓ ✓
KDE ✓ ✓ ✓
Xfce ✓ ✓ ✓
Budgie ✓ ✓ ✗

The one gap - uim on Budgie - is a real technical limitation, not an oversight: Budgie runs the labwc compositor, which implements zwp_input_method_v2, while uim-wayland only speaks the older zwp_input_method_v1 (KWin/Weston). On Budgie you use ibus-mozc or fcitx5-mozc instead.

All images come with the Japanese locale, fonts, and the Asia/Tokyo time zone pre-configured, plus the SSH key of your choice. Input switching is wired up out of the box: Ctrl + Space or Shift + Space for your IMEs to enable it.

The layered-image trick

The core idea is that the images are stacked qcow2 overlay layers, one on top of another:

debian-sid-nocloud-amd64-daily.qcow2     ... base image you download
└─ unstable-japanese-template.qcow2      ... locale, fonts, user, SSH
   └─ unstable-<DE>-template.qcow2       ... a desktop environment
      └─ unstable-<DE>-<IME>.qcow2       ... desktop + IME, configured
         └─ unstable-<DE>-<IME>.workspace.qcow2 ... the image you test in

This makes both building and resetting fast. The first build downloads and customizes the base image and takes a while, but every later step only adds a thin overlay. When a test breaks the VM, you do not rebuild anything - you simply delete the top workspace layer and recreate it. That is all it takes to return to a pristine state:

rm /tmp/unstable-gnome-ibus-mozc.workspace.qcow2
make gnome-ibus-mozc

The images reference their backing files by relative path, so you can move an entire stack anywhere you like as long as the images stay together.

A platform for experimenting with bleeding-edge IMEs

The base system is Debian unstable (sid), and the experimental repository is already added. That makes the project a convenient platform for testing not just the IME packages in sid but also the ones still being developed in experimental - exactly what the project was built for.

The keyboard layout of the VM follows the layout of your host (read from /etc/default/keyboard, with a fallback chain to localectl and finally us).

Quick start

# 1. Install the tools (Debian/Ubuntu example)
sudo apt install qemu-utils libguestfs-tools virt-install curl

# 2. Save your SSH public key
curl --location https://github.com/USERNAME.keys --output pubkey.pub

# 3. Download the base Debian sid image
make download

# 4. Build a desktop + IME (first build takes a while)
make gnome-ibus-mozc

# 5. Start it as a VM (needs the libvirt daemon, qemu:///system)
./scripts/make-virsh-image.sh virt-gnome-ibus-mozc /tmp/unstable-gnome-ibus-mozc.workspace.qcow2

Log in as debian (password debian) and press Ctrl + Space (Shift + Space) to start typing Japanese. The VM is registered in libvirt, so you can manage it with virsh or virt-manager - handy for opening the SPICE console or restarting the machine after a test.

Status

The project is still in the proof-of-concept phase, and it is developed mainly to test Mozc and other IMEs across desktops and input frameworks.

If you regularly test Japanese IMEs - give it a try.

My Free Software Activities in September 2026

9月のハイライト

9月はDebianのMozcをなんとか3.33にあげてunstableに投入するための準備をしていた。 大きな方針転換としてはuim-mozcをuim公式が提供するようになったことである。 これにより、src:mozcで抱えなければいけなかったパッチも不要になる。 uim公式では従来と実装も変わっていて、Mozcとは粗結合になっているようだ。 したがって、過去のMozc 3.33+uim-mozcのとりくみで発生していたような同一プロセス起因のSEGVなんてのも過去のものになったはず。

あとは、dh-bazelの開発をはじめた。詳細についてはどこかでまとめて発表しておきたい。

9月の活動記録

Building with dh-bazel, buildsystem support for debhelper experiment updates

Introduction

After bazel-bootstrap 7.7.1 was landed into Debian unstable, I'm working on packaging newer Mozc (Most famous Japanese input method editor) with Bazel.

Here is the blog entry initial efforts to build Mozc with Bazel at that time.

kenhys.hatenablog.jp

Then, I've shared implementing PoC dh-bazel experiment. See why dh-bazel is needed, and prototype about dh-bazel.

kenhys.hatenablog.jp

As a Bazel beginner, want to know what should pass to Bazel, what should not pass to Bazel.

What is improved in recent dh-bazel?

In the previous versions of dh-bazel, it supports only basic features to build with Bazel as a thin wrapper.

%:
        dh $@ --buildsystem=bazel

override_dh_auto_build:
        dh_auto_build -- //:hello

Now, with recent changes, it supports the following environment variables to resolve required system libraries in dynamically.

salsa.debian.org

  • DH_BAZEL_OVERRIDE_MODULE

It search the specified modules from bundled dummy modules in dh-bazel. It accept ',' separated paramesters. (e.g. DH_BAZEL_OVERRIDE_MODULE=zlib,zstd)

dh-bazel bundles abseil-cpp, apple_support, buildozer, lz4, openssl, protobuf, rules_android_ndk, rules_apple, rules_swift, zlib and zstd as dummy modules to linking system libraries.

Now you can use it in debian/rules like this:

#!/usr/bin/make -f
# -*- makefile -*-
#

export DH_BAZEL_OVERRIDE_MODULE=zlib
export DH_VERBOSE=1

%:
        dh $@ --buildsystem=bazel --without=single-binary

override_dh_auto_build:
        dh_auto_build -- //:hello

It is impossible to cover all of system libraries in Debian, so in that case, please consider to use the following DH_BAZEL_PKGCONF_MODULE.

  • DH_BAZEL_PKGCONF_MODULE

It search the specified modules with pkgconf. It is useful when there is no bundled modules in dh-bazel if you want. It accept ',' separated paramesters. (e.g. DH_BAZEL_PKGCONF_MODULE=gtk4-x11,gtk4-unix-print).

If DH_BAZEL_PKGCONF_MODULE could not match, then dh-bazel fallback to dig into Build-Depends: field in debian/control. Note that if it is not deterministic (e.g. -dev package provides multiple .pc files) dh-bazel gives up fallback with pkgconf.

Now you can use it in debian/rules like this:

#!/usr/bin/make -f
# -*- makefile -*-
#

export DH_BAZEL_PKGCONF_MODULE=gtk4-x11,gtk4-unix-print
export DH_VERBOSE=1

%:
        dh $@ --buildsystem=bazel --without=single-binary

override_dh_auto_build:
        dh_auto_build -- //:hello

Conclusion

dh-bazel is still in very early stage prototype, but it resolves some sort of packaging glitches a bit by bit.

I hope that it will help package maintainer using Bazel. (dh-bazel is not uploaded into debian/unstable yet, so stay tuned!)

Building Mozc with dh-bazel, buildsystem support for debhelper

Introduction

After bazel-bootstrap 7.7.1 was landed into Debian unstable, I'm working on packaging newer Mozc (Most famous Japanese input method editor) with Bazel.

Here is the blog entry initial efforts to build Mozc with Bazel at that time.

kenhys.hatenablog.jp

Why dh-bazel?

After that, newer Mozc packages are uploaded into experimental and moved to testing phase on experimental now.

mozc - Debian Package Tracker

When started packaging efforts for newer Mozc with Bazel, I'm a newbie to do it. Now I've got a knowledge to do it a bit, I want to know best practice on packaging X on Debian with Bazel furturmore.

Usually there are dh-X for buildsystem X on Debian, but it's not true for Bazel as far as I know. This is why I had started to write dh-bazel.

I've wrote initial dh-bazel prototype and post a mail to debian-bazel ML.

lists.debian.org

dh-bazel supports the following way:

%:
        dh $@ --buildsystem=bazel

override_dh_auto_build:
        dh_auto_build -- //:hello

If you want to build source under src, you could write d/rule like this:

%:
        dh $@

override_dh_auto_build:
        dh_auto_build --buildsystem=bazel --sourcedirectory=src -- //:hello

Conclusion

dh-bazel is in very early stage prototype, but I have succeeded to build newer Mozc with some modifications to Mozc debian/rules on experimental with dh-bazel locally!

dh-bazel is a thin wrapper for Bazel, so it does not reduce packaging glitches dramatically, but it helps some sort of packaging tasks IMHO.

There are some achievement with dh-bazel

  • It helps to do similar building way like other debhelper buildsystem
  • It sets comprehensive Bazel startup options
  • It sets comprehensive Bazel command options
  • If you want to set extra flags, just specify it as additional user options (--override_module=, and so on)

Note that it only simplify dh_auto_build stage, so you must manually install artifacts with .install or something correctly.

I hope that it will help package maintainer using Bazel in the future. (dh-bazel is not uploaded into debian/unstable yet, so stay tuned!)

My Free Software Activities in August 2026

8月のハイライト

8月はDebianのMozcをいかにより新しいバージョンに更新していくかについての発表をDebian勉強会で実施した。

Tokyo Debian Update Mozc - Kentaro Hayashi - Rabbit Slide Show

uim-mozcの問題が解決しなかったら、uim-mozcを廃止しようかと考えていたが、幸い修正できたので少なくとも forkyでは維持していきたい。Bazel移行ができたら次の3.34にあげられるのかどうかを検証してみたい。

DebianのLLMに関するGRは結論を急ぎすぎて分断を発生させてしまった気がしないでもない。

8月の活動記録

My Free Software Activities in July 2026

7月のハイライト

7月はDebian unstableで利用できるMozcをより新しいバージョンに追従しようとする作業をすすめていた。 Bazel 7.7.1がunstableで利用できるようになったからというのがその理由である。 しかし、ibus-mozcやfcitx5-mozcはよいのだが、uim-mozcは辞書ツールなどと併用するとクラッシュする既知の問題がある。 デストラクタが二重に呼び出されてクラッシュするからだが、そこはちょっと直すのに手間がかかりそうとみている。 そのため、mozc 3.33.6133+ds1-0.1~exp1としてexperimentalにアップロードしたままその後作業は進んでいない。 とはいえ、Mozcの更新の目処がたったということは成果ではあるといえる。

7月の活動記録

Try to build Mozc with Bazel 7.7.1

Introduction

Recently, I've got a chance to try building Mozc (Most famous Japanese input method editor) with Bazel.

As you know, recently newer Bazel related packages were landed into debian/unstable. Then now I'm planning to update Mozc from 2.29.5160.102 to 3.33.6133.

Background story about Mozc and Debian

The upstream of Mozc had released 3.34.6239, but on Debian, we stick to Mozc 2.29.5160.102.

Mozc requires newer Bazel but we only had Bazel 4.2.3 at that time on Debian, so even though the upstream of Mozc switched from GYP to Bazel, we had patched Mozc with GYP based package.

We even did make an effort to restore build options that had been already removed. :-( And needed to migrate from GTK2 renderer to GTK3 renderer.

That is why the version of Mozc is diverged from upstream on Debian.

  • 2.29.5160.102 (Now on Debian)
  • 2.29.5268.102
  • 2.29.5374.102
  • 2.29.5544.102
  • 2.30.5544.102
  • 2.31.5712.102
  • 2.31.5851.102
  • 2.32.5994.102
  • 3.33.6089
  • 3.33.6133 (Target to upgrade for)
  • 3.34.6239

How to switch from GYP to Bazel?

At first, we needed to decide what Mozc version to work with it.

Now latest version of Mozc is 3.34.x, but it requires Bazel 9.x. Please recall that Bazel 7.7.1 was introduced Debian/unstable. And more, newer dependency libraries are required.

You might feel that target version (3.33.6133) is too high from 2.29.5160.102, but if we upgrade to more older Mozc, it means that it requires to backport Mozc to older libabsl compatible codes and so on.

That is why Mozc 3.33.6133 was chosen.

Even once the target version has been decided, you can't let your guard down.

There are many technical tasks to solve.

  • Revisit patch sets to apply
  • Porting uim mozc patch and fix FTBFS
  • Porting fcitx5 mozc patch and fix FTBFS
  • Fix src/third_party vendoring
  • Switch from GYP to Bazel build systems
  • ...

At least, it will likely require several rounds of testing in the Debian experimental.

Conclusion

Currently, gbp buildpackge has succeeded finally on local machine, but need to tidy and cleanup stuffs.

I didn't know packaging with Bazel best practice yet, to remove many third party vendor/ bundles, I've found that it requires pile of patch to eliminate them.

In the current version of Debian, as a one of build system, further work — such as support from debhelper - will be needed.

I'll file working progress on #1085173