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!)

Nheko is my current favourite client for the Matrix IM system, which is my favourite IM system.

Matrix is an open system with end to end encryption and Nheko is free software and runs well on Linux desktops and phones.

The Nheko client allows interaction with dbus which could be good for automating things, EG you could change the status message when unlocking the screen. I’m documenting the most useful ones here because they don’t seem to be documented anywhere else. I have filed a Debian bug about the activate room option not working. The qdbus6 program is the QT6 version of the dbus command-line query program, there are a range of other programs which work in much the same way.

# list all interfaces
qdbus6 im.nheko.Nheko / 
# get the version of Nheko
qdbus6 im.nheko.Nheko / im.nheko.Nheko.nhekoVersion
# list rooms in a dump of the data structures (pity it's not json or something)
qdbus6 --literal im.nheko.Nheko / im.nheko.Nheko.rooms|less
# join a room
qdbus6 im.nheko.Nheko / im.nheko.Nheko.joinRoom "#flounder-random:luv.asn.au"
# supposed to activate a room but doesn't
qdbus6 im.nheko.Nheko / im.nheko.Nheko.activateRoom "#flounder-random:luv.asn.au"
# set the status
qdbus6 im.nheko.Nheko / im.nheko.Nheko.setStatusMessage "whatever"
# get the status
qdbus6 im.nheko.Nheko / im.nheko.Nheko.statusMessage

Here are a couple of examples of using other dbus clients to get similar results. Note that the difference between the Debian version of Nheko (and maybe other recent versions) and what LLMs return for usage examples is that Debian has “/” as the path while the examples have “/im/nheko/Nheko”.

# list rooms via gdbus
gdbus call --session --dest im.nheko.Nheko --object-path / --method im.nheko.Nheko.rooms
# get status via dbus-send
dbus-send --session --print-reply --type=method_call --dest=im.nheko.Nheko / im.nheko.Nheko.statusMessage