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

Following up on my previous post, I am releasing debvulns-exporter, a Prometheus exporter for tracking Debian system vulnerabilities. The underlying vulnerability analysis logic remains identical to the previously released MCP server and CLI utility.

At May First, we recently received (all within a single week) three different complaints about domain names that previously worked fine suddenly not resolving to our servers.

While that isn’t terribly uncommon, we discovered that in each case, the domain name’s authoritative name servers were pointing to our mail servers (a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org) instead of our name servers (a.ns.mayfirst.org, b.ns.mayfirst.org and c.ns.mayfirst.org). The weird part: this mistaken configuration was happening at the registrar level, protected by each member’s own credentials that we don’t have access to.

Each affected member fixed their records to resolve the problem but also made very clear that they had not logged into their registrar in years, sugggesting that the DNS authoritative records in their registrar accounts spontaneously changed on their own. The first time was weird, the second time could possibly be a coincidence? But by the third time this happened, we started to panic. How could registrar records spontaneously change? All three domain names were registered with different companies - so it couldn’t be a single registrar problem? Are we going to get a flood of these complaints? What is going on!?!?

We did an inventory to see if this was happening with other domain names in use by our membership and that’s when we discovered just how hard it is for our mostly non-technical users to set a domain’s authoritative name servers. The error rate was less than 1% but still that was a lot of domain names with typos:

• raise your fist in the air with a.ns.mayfist.org!
• or just plain give up and hit the floor with a.ns.matfirst.org
• Or more commonly people added our name servers, but also left the default name servers in place.
• Also, one person added as their authoritative name servers: a.ns.mayfirst.org, b.ns.mayfirst.org, c.ns.mayfirst.org, a.mx.mayfirst.org, b.mx.mayfirst.org, c.mx.mayfirst.org, and even a.webproxy.mayfirst.org - in other words, all the domain names we tell you do to anything with.
• And lastly, I did find two more domains just pointing to a.mx.mayfirst.org, b.mx.mayfirst.org and c.mx.mayfirst.org.

That’s when it occurred to me: for years we have maintained an offsite server that provides both c.ns.mayfirst.org and c.mx.mayfirst.org. It hangs out in case something terrible happens to our main colo. The week before we started receiving these complaints, I separated these services, moving c.mx.mayfirst.org to a dedicated MX server. As a result, these two domain names stopped pointing to the same IP address. And that’s when the complaints started rolling in. In other words: the affected members set the incorrect name servers years ago, but because just one of the name servers resolved to an IP that happened to provide the correct authoritative lookup services, it went undeteced all this time.

So… mystery solved. Nobody’s authoritative registrar records “suddenly” changed. They were mis-configured for years but thanks to the amazing resilience of the DNS system, nobody noticed because just one working DNS server is all you need.