Arch Linux User Repository

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

This no longer compiles with Bazel 7.0. Most likely fixed in mozc upstream already, via https://github.com/google/mozc/commit/ee558c249144ff0a7afaa248dba2f56f5c7409b5.

        deps_cfg = apple_common.multi_arch_split,
Error: 'apple_common' value has no field or method 'multi_arch_split'
INFO: Repository build_bazel_apple_support instantiated at:
  /home/aku/.cache/yay/fcitx5-mozc-ut/src/fcitx5-mozc-ut-git/src/WORKSPACE.bazel:73:25: in <toplevel>

Please follow RFC16 use 'BSD-3-Clause AND CC0-1.0'

@Nocifer Thanks for the explanation! Another thing: how does fcitx communicate with mozc? Does it expect mozc_server and mozc_tool to be available in a certain path?

@dough.mean The packages are split so that mozc/mozc-ut provide Mozc itself and the ibus-mozc/fcitx5/-mozc-ut/emacs-mozc packages provide the respective GUI plus the required "glue" to make it all work.

The idea behind this is that some people may need to run multiple user accounts on the same machine but with different DEs (e.g. on a family or student laptop), so in such a case the different GUI packages should be possible to be installed in parallel in whatever combination, without the file conflicts that would occur if the three GUI packages also included the Mozc engine files, which would be common (and redundant) between them.

Another way to go about it would have been to provide a full package with all the required files for the Mozc engine as well as all the different GUIs (IBus, Fcitx & Emacs currently, but there used to be more, e.g. UIM), but back when I created the packages the trend was to provide a single package for each frontend, so I ended up with the current solution.

If you don't care about all that, then there is no need to split the packages.

I'm trying to port this package for another distro, and I have a question. Why does this package depends on mozc/mozc-ut? Doesn't the fcitx/mozc repro already includes mozc itself? Can anyone explain the relationship between these packages?

@Nocifer Thanks for the comment, it got me thinking in the right direction. I should have mentioned that I was building with paru's chroot option. Looks like it was an issue that has been patched already within paru, because switching to paru-git fixed the issue.

@ginnokami If you're not doing it this way already, you need to provide the mozc package manually as a dependency with the -I switch, i.e. makechrootpkg -I /path/to/mozc-2.28.5105.102-1-any.pkg.tar.zst ...

Don't forget, it's supposed to be a "clean" chroot, so whatever you have installed (either on your system or in the chroot itself) is irrelevant as long as it's not part of the base system, because the chroot gets "cleaned" before every operation.

Is anyone else having an issue building 2.28.5105.102-1 in a clean chroot? I have mozc-ut 2.28.5105.102.20230524-1 built and installed, but pacman keeps complaining about missing dependencies:

=> Making package: fcitx5-mozc-ut 2.28.5105.102-1 (Sat May 27 18:32:56 2023)
==> Checking runtime dependencies...
==> Installing missing dependencies...
error: target not found: mozc>=2.28.5105.102
==> ERROR: 'pacman' failed to install missing dependencies.
==> Missing dependencies:
  -> fcitx5
  -> mozc>=2.28.5105.102
==> Checking buildtime dependencies...
==> Installing missing dependencies...

In version 2.28.5008.102 the build process has been changed, from using Google's Mozc repository as a base and patching in the Fcitx5 target provided by Fcitx's forked Mozc repository, to directly fetching the latter and doing away with all the unnecessary patch juggling.

The downside is that you'll need to cleanly build the package in order to update it, i.e. you'll need to delete the fcitx5-mozc-ut-git folder (if you keep it around for using it in subsequent builds).

@Ayaka Going by your log it seems you were actually trying to install fcitx5-mozc-ut-full which is a different package, and it failed because it's outdated.