Arch Linux User Repository

Due to the recent GCC 12.1 update, if you try to update a Mozc package that was built with an older GCC version you will need to yet again delete your Bazel cache (~/.cache/bazel/... by default) in order to prevent the following error (or some such):

ERROR: /build/mozc/src/mozc-git/src/storage/louds/BUILD.bazel:167:16: Compiling storage/louds/bit_stream.cc [for host] failed: undeclared inclusion(s) in rule '//storage/louds:bit_stream':
this rule is missing dependency declarations for the following files included by 'storage/louds/bit_stream.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdint.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/syslimits.h'
INFO: Elapsed time: 5.362s, Critical Path: 1.28s
INFO: 36 processes: 13 internal, 23 linux-sandbox.
FAILED: Build did NOT complete successfully

It's more than likely that this error can also be prevented by removing one or more specific files within Bazel's cache instead of the whole lot of it, so in the future such toolchain updates may become much less painful; but for the time being, and unless otherwise noted, be aware that an updated toolchain will always mean that you need to delete Bazel's cache and suffer a full recompilation.

Due to the recent GCC 12.1 update, if you try to update a Mozc package that was built with an older GCC version you will need to yet again delete your Bazel cache (~/.cache/bazel/... by default) in order to prevent the following error (or some such):

ERROR: /build/mozc/src/mozc-git/src/storage/louds/BUILD.bazel:167:16: Compiling storage/louds/bit_stream.cc [for host] failed: undeclared inclusion(s) in rule '//storage/louds:bit_stream':
this rule is missing dependency declarations for the following files included by 'storage/louds/bit_stream.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include/stdint.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/include-fixed/syslimits.h'
INFO: Elapsed time: 5.362s, Critical Path: 1.28s
INFO: 36 processes: 13 internal, 23 linux-sandbox.
FAILED: Build did NOT complete successfully

It's more than likely that this error can also be prevented by removing one or more specific files within Bazel's cache instead of the whole lot of it, so in the future such toolchain updates may become much less painful; but for the time being, and unless otherwise noted, be aware that an updated toolchain will always mean that you need to delete Bazel's cache and suffer a full recompilation.

Nah, it's already a hard dependency of bazel so it's guaranteed to be present on the system.

export JAVA_HOME='/usr/lib/jvm/java-11-openjdk/'

Should the PKGBUILD have 'java-environment==11' in makedepends?

I just tried it one more time before trying one of your suggestions and it just happened to work :P Thanks anyway, I will try deleting the cache next time if it happens.

Hmm, I just tried it twice and the file downloaded without problem. Does the package build with makepkg itself? If so, it could be something to do with paru. Also, if you haven't already, you could try removing Bazel's cache; even though it sounds counterintuitive in regards to this particular issue, Bazel is known for producing such weird quirks from time to time.

Is anyone else having trouble during install with Bazel failing to download the files from the japan post site (works fine in browser though...)?

/home/user/.cache/paru/clone/mozc/src/mozc-git/src/WORKSPACE.bazel:170:13: fetching http_archive rule //external:zip_code_jigyosyo: Traceback (most recent call last):
    File "/home/user/.cache/bazel/_bazel_user/4c479eee4713cbfd37f7dd3576dee827/external/bazel_tools/tools/build_defs/repo/http.bzl", line 111, column 45, in _http_archive_impl
        download_info = ctx.download_and_extract(
Error in download_and_extract: java.io.IOException: Error downloading [https://www.post.japanpost.jp/zipcode/dl/jigyosyo/zip/jigyosyo.zip] to /home/user/.cache/bazel/_bazel_user/4c479eee4713cbfd37f7dd3576dee827/external/zip_code_jigyosyo/temp14725772222497573027/jigyosyo.zip: Unknown host: www.post.japanpost.jp

Due to a mistake I made in the previous release, newer versions of this package may fail to gracefully update over a preexisting 2.26.4596.102 setup (installing fresh won't be an issue) with the following error (or something similar):

error: failed to prepare transaction (could not satisfy dependencies)
:: installing mozc (2.26.4610.102-1) breaks dependency 'mozc=2.26.4596.102' required by fcitx5-mozc-ut

The TL;DR version of it is that you will need to do one of the following:

1) Uninstall this package and then reinstall it; or

2) Edit the file /var/lib/pacman/local/fcitx5-mozc-ut-2.26.4596.102-1/desc and replace

%DEPENDS%
fcitx5
mozc=2.26.4596.20211205

with

%DEPENDS%
fcitx5
mozc>=2.26.4596.20211205

and then proceed to update as per usual.

(In other words, the mozc version dependency should be a lax >= instead of a strict =; which AFAIR is also standard PKGBUILD practice, but somehow I completely forgot about it.)

Hopefully this is now fixed, but I'll wait for your input (if any) before I can be certain. Sorry for the inconvenience.

@lionslancer Yup, I'd say you've summed it up pretty nicely. The naming/packaging situation is a bit of a mess right now, but contacting the maintainers of fcitx5-mozc and mozc-ut in order to try and find a proper solution is already on my to-do list. Hopefully things won't prove to be too confusing for the users in the meantime.

Hi! I recently ran into an issue where I had to reinstall this package because the new release depends on mozc, which mozc-ut-common didn't provide pre-update, causing it do attempt to install the mozc package which conflicts with the former.

From looking at various PKBUILDs, it looks like you've become the maintainer of mozc and this change is to make the various framework module packages compatible with both mozc and mozc-ut-common. Am I then correct in assuming that the relevant packages going forward are the following?

• mozc and mozc-ut-common for the engine
• fcitx5-mozc-ut, ibus-mozc, and emacs-mozc for the modules

If I've understood correctly, there's no longer anything UT-specific about this package, and the names fcitx5-mozc and mozc-ut would have been used if not for the naming conflict with existing packages. Is this accurate?

(edit: I accidentally deleted my comment while initially trying to edit the formatting, sorry if you received multiple notifications.)

Thank you for your patience. I completely understand it now.

No such thing as a stupid question.

If you've managed to install this package then that means you are indeed using Mozc with the UT dictionary, as the latter is compiled into the Mozc binary during build time and used by default. AFAIK the only way to check for sure would be to compare the word candidates that this Mozc gives you with the candidates a non-UT Mozc would give you, but I don't really think that is necessary.

As to the second question: some time around 2016 the UT dictionary was deprecated by its creator in favor of two new dictionaries, UT2 and Neologd. They were supposed to replace UT, but in 2020 they were instead merged back into UT, and thus UT again became the de facto "UT dictionary" for Mozc. fcitx-mozc-ut-unified makes use of this latest UT dictionary, hence the "unified" part, which I assume was only added because there was already a package called fcitx-mozc-ut in the AUR (which was unmaintained at the time and was stuck using the old, pre-unification UT dictionary - this is no longer the case).

This package also uses the exact same UT dictionary, but because there weren't any Fcitx5 packages already in the AUR, I saw fit to just call it fcitx5-mozc-ut for consistency's sake (because from today's point of view, there is only a single UT dictionary). The only real difference between fcitx-mozc-ut-unified and fcitx5-mozc-ut is that the former is based on Fcitx, while the latter is based on Fcitx5, which is the Qt5-based successor of Fcitx. Do keep in mind though that Fcitx is still widely in use, as some language modules do not yet support Fcitx5 (e.g. the Baidu IME for Chinese).

Any *-ut2 packages can safely be considered as deprecated.

Sorry for my stupid questions cause I just learned about UT this week.

First, I installed this package using yay. However, there seems no differences in mozc. Do I need some config to enable UT dictionary? Or is there any methods to check if I'm using mozc with UT dictionary?

Second, there's seem to be multiple version of UT dictionary, such as fcitx-mozc-ut, fcitx-mozc-ut2, and fcitx-mozc-ut-unified in fcitx. I only find this package in fcitx5. I guess it's the same version as fcitx-mozc-ut-unified?

Apologies again for my stupid question.

@YEK

To be fair, utuhiro's PKGBUILD does have at least one advantage, namely, the fact that it doesn't rely on Fcitx's mirrored Mozc repo. I got bitten by this just now when, trying to update my mozc packages to their latest versions, I realized that while Mozc has been updated to version 2.26.4237 since 29/12/2020, the Fcitx mirror is still at version 2.26.4220.

This would normally mean that either I'd need to postpone updating this particular package (the ibus and emacs packages were already properly updated) and wait for the Fcitx developers to update their mirrored Mozc repo, or I'd need to update this package to only 2.26.4220 instead of the latest 2.26.4237 like the rest of the packages.

Enter utuhiro who, on top of providing UT in the first place, he also provides a patch for adding the needed Fcitx5 support directly to the upstream Mozc repo, without having to rely on the Fcitx devs to update their Mozc mirror. This patch literally saved the day.

So in fact I've now decided to modify my PKGBUILD to more closely resemble utuhiro's, by pulling directly from the official Mozc repo and using utuhiro's patch, along with the Fcitx5 iconset zip that he also provides on his website, in order to add Fcitx5 support on top of that.

I still think that the rest of the flaws I described, even though they're mostly minor, should really be addressed; but at least now we're even closer to convergence.

By the way, I'd welcome any suggestions you might have, now or in the future, for making this PKGBUILD better. We can always make the first step in fixing this non user-friendly AUR situation by cooperating ourselves :)

Thank you for the detailed explanation.

After deep consideration, I decided not to make an official PKGBUILD version and leave it to you.

Actually, I feel that the official PKGBUILD has a lot of changes and a lot of room for improvement. The variety of packages in Mozc is not user-friendly, and I think the idea is a very good one.

Thank you very much.

Hello @YEK,

Unfortunately, my choice to use a PKGBUILD different than the one provided by utuhiro is based on the fact that, as far as I can tell, there are a few flaws with it:

1. It doesn't pull the source files from either the official Mozc repo or the Fcitx projects's modified Mozc repo, instead opting to provide them via a separate download.
2. It contains outdated (e.g. pkg-config which has been replaced by pkgconf since 2018 or so), redundant (e.g. bzip2 which is a requirement of base and curl which is a requirement of pacman, both of which are installed by default on an Arch system) and/or missing dependencies (python-six).
3. It opts to depend on a system-wide gyp package, instead of making use of the included submodule.
4. In the same way, it doesn't use the included submodules for abseil, googletest, protobuf, or even the default Mozc dictionary itself, but instead provides them as separate downloads.
5. It builds and bundles all the Mozc binaries instead of only bundling the ones needed by Fcitx5 itself and depending on a separate package for the rest, and thus creates conflicts with other Mozc packages (e.g., one cannot install the Mozc package for Emacs if they have already installed the package for Fcitx5).

As such, at this time I think I prefer my own PKGBUILD instead of utuhiro's. I'm very open to the idea of collaboration between us and the rest of the various Mozc packagers in the AUR, and even with utuhiro, in order to create one common PKGBUILD template and use it to provide the whole gamut of Mozc packages (which would come with the added benefit that new users looking to install Mozc won't feel confused by the many different choices), but for the time being feel free to create a separate fcitx5-mozc-ut-unified package and I'll make sure to add it as an option in the ArchWiki's Mozc page (or you can also do it yourself, of course).

Thanks for contacting me, I appreciate it.

Hi, I'm maintainer of fcitx-mozc-ut-unified package. Now UT's upstream (utuhiro's project) supports fcitx5 officially with fcitx-mozc-ut-*-PKGBUILD.txt.

Will you follow it in this package? (If you won't, I will create fcitx5-mozc-ut-unified package.)