Arch Linux User Repository

If you're getting compilation errors, please delete your Bazel cache (~/.cache/bazel by default).

@Calimero AFAIU this would need me to check and verify which specific submodule commits are being used each time Mozc releases a new tagged version and update not only the PKGBUILD but also Bazel's scripts, which would be kind of a big amount of work, and for what? If you don't keep the submodules around in your $srcdir (which is the only reason why you'd need to re-clone them all the time) you'd still need to re-clone them all over again anyway, only the cloning would happen behind the scenes, by makepkg calling git as part of fetching the PKGBUILD's sources, instead of git doing it explicitly as part of prepare(). And this doesn't even take into account the fact that the already fragile Bazel would quite possibly go bonkers due to making it use external dependencies and would invalidate its cache which would increase the build times tenfold. Granted, that's not a 100% given, but knowing Bazel and its quirky nature it could very well happen.

In short, I don't really see a compelling need for changing the way the submodules are handled. Also, using dynamic linking via globally installed packages is unfortunately not supported either by Mozc (it explicitly only supports static linking) or by Bazel (it would require me to rewrite many of upstream's setup scripts).

EDIT: To clarify, my main issue is with Bazel, not with using git submodules as PKGBUILD sources. But to put my money where my mouth is, I'll experiment with such a setup in the next few days and verify firsthand whether Bazel will behave nicely or not.

EDIT 2: So after deliberating on it a bit more I realized I was talking nonsense. The submodules are updated via git independently of Bazel anyway, so keeping local copies of them around and copying them into $srcdir instead of fetching them into it from upstream should look exactly the same to Bazel and its cache system. Also, fetching just the latest changes of the submodules instead of cloning them from scratch every time is obviously an actual improvement because it's faster and it saves on bandwidth (I mean, it's almost like git was built to work like this in the first place...).

So, yeah. I'm just going to blame it on the heatwave that's been scrambling my brain for the past month. Thanks for the suggestion :)

Request for improvement: in order to not re-clone all the submodules all the time, here is how to handle them properly with makepkg: https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules

Or better yet, would it be possible to use archlinux packages for protobuf etc?

Sorry for the fsck up, I don't even know how I managed to do that. Package permissions have (hopefully) been fixed.

mozc_server and mozc_tool are installed with 6-- instead of 7--. Please revert the relevant changes in the pkgbuild

The issue I experienced earlier was caused by a re-exported PATH which included rye's python shims:

  (cd /home/loqusion/.cache/bazel/_bazel_loqusion/1740d625a2d23b8100ac375e0bfd1640/sandbox/linux-sandbox/10/execroot/mozc && \
  exec env - \
    PATH=/home/loqusion/.rye/shims:redacted \
  /bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; bazel-out/k8-opt-exec-ST-13d3ddad9198/bin/dictionary/gen_pos_matcher_code --id_file=data/dictionary_oss/id.def --special_pos_file=data/rules/special_pos.def --pos_matcher_rule_file=data/rules/pos_matcher_rule.def --output_pos_matcher_data=bazel-out/k8-opt/bin/data_manager/oss/pos_matcher.data')

(I found this by running env PATH=... makepkg with various PATHs until I identified the culprit.)

This seems to have been fixed in a recent version of rye.

@Nocifer Maybe it's worth creating an issue in https://gitlab.archlinux.org/archlinux/packaging/packages/fcitx-mozc/-/issues now that everything is on GitLab, perhaps it can get more eyes on your request and something will change

Unfortunately, Bazel's default log output is not exactly helpful. You can try replacing bazel build server:mozc_server gui/tool:mozc_tool --config oss_linux --compilation_mode opt in the PKGBUILD with bazel build --verbose_failures server:mozc_server gui/tool:mozc_tool --config oss_linux --compilation_mode opt and then rebuilding the package, that --verbose_failures flag will hopefully provide some good info on the specific commands that fail.

Running extra-x86_64-build (from devtools) builds successfully, so you're probably right that there's some anomaly on my system that prevents it from building properly. Are there any likely candidates you know of?

I strongly suspect it's something to do with your system configuration; it may have been lurking and only brought to the spotlight by the recently-released Babel 7.0 update, which already produced one new issue for Mozc that had to be fixed. Can you check if the package builds in a clean chroot?

Regarding fcitx-mozc-ut and its dependencies, all three frontend packages (fcitx-mozc-ut, ibus-mozc and emacs-mozc) are UT-agnostic and can be used with either mozc (the upstream version) or mozc-ut (the UT version). This is why they depend only on "mozc", which is provided by both mozc and mozc-ut.

fcitx-mozc-ut should really be called fcitx-mozc, without the '-ut' suffix, just like the other two frontend packages. Unfortunately, there is already a conflicting fcitx-mozc package in the extra repository, the maintainer of which neglects to properly maintain it (last real update was almost 3 years ago) and at the same time refuses (or at least ignores my request) to relinquish control of it and release it in the AUR so it can be replaced by this package. Until that happens, this package must confusingly remain as fcitx-mozc-ut.

Yeah, I had fcitx5-mozc-ut (which depends on mozc and not mozc-ut for some reason) working for months and then recently the mozc build started failing on system upgrades. Removing $srcdir also doesn't fix it unfortunately.