gagath’s debian devlog

Kanata available in Debian, and next steps

Kanata is finally packaged and available in testing (Debian forky). This is the result of a long effort of bringing its dependencies in the archive as well as some necessary patching. Let’s look what it took and what will be the next steps.

Patches accepted upstream!

Debian has a long tradition of sending its patches upstream, and my contributions are no exception to this rule. Sometimes upstream will ignore them, but it was not the case with kanata, as all pull-requests have been accepted on Github:

These patches seem to be available in kanata v1.10.0-prerelease-1 on crates.io, but since this is a prerelease it will not be imported in Debian just yet. When the full version is released, the patches will be dropped from Debian as they will now be integrated in upstream directly.

It works on Ubuntu, too

I am successfully using this package on Ubuntu machines as well. To install it, I am installing kanata.deb from Debian directly. Since Rust binaries are statically linked to their crates, this happen to just work on Ubuntu, although I know it is not recommended to install packages this way. Indeed, to get (security?) updates, one needs to manually check and install new releases.

The ideal way would be to have some PPAs to distribute kanata to the matching alive Ubuntu releases, but this PPA would need to contain all the Rust dependencies as well to allow the PPA to build the crate from source. This is a lot of work for little benefit, as the built package would probably be very similar to the one in Debian because of the final static linking. So for purists, one would have to wait the next Ubuntu release which should contain kanata in universe automagically.

The same would be needed to backport kanata to Debian trixie, as kanata did not make it into this stable Debian release and is currently available only in testing and unstable. Backporting these dependencies is not small feat. There is also the issue that the Debian Rust Team, which I am a part of, currently has no clear path to follow to backport Rust software to Debian stable releases. I have been told that some branching scheme was under draft for the salsa debcargo-conf git monorepo, but is not ready yet.

Towards /dev/uinput in Debian?

Kanata needs to access /dev/uinput in order to create its virtual keyboard device. However, on Debian, this node is not available by default. I had to create the following udev rule:

# /usr/lib/udev/rules.d/50-kanata-uinput.rules
KERNEL=="uinput", MODE="0660", GROUP="input", OPTIONS+="static_node=uinput"

Kanata is not the only package that needs to access the /dev/uinput node, and we can use codesearch.debian.net to find other packages using it:

https://codesearch.debian.net/search?q=static_node%3Duinput&literal=1

We can see that some packages install a rule that allows all users to access /dev/uinput, while this rule is a bit more conservative and only allows users in the input group. I first wanted to allow the uinput group like upstream suggests, but this would have needed to create this group in the postinst script as it does not exist on the system. I do not think that creating this uinput group from the Kanata package is a clean thing to do, as I would expect such group to be part of the base system instead.

I think that we could have a common /dev/uinput by default in Debian, with a uinput group separate from the input group that I settled with, so that all of these custom rules in packages can be dropped and users, just like for the input group, can be added to the uinput group to allow them to access the node.

This would require to create the rule in the Debian package that installs the default rules, but I forgot its name and I am not sure that there are enough packages using it to consider creating the node on each and every Debian system in the world.

That’s all folks, happy typing.

gagath’s debian devlog

Other articles

ITP: kanata

qmk available in unstable

Other articles

social