Arch Linux User Repository

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

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.

Hmm, I see some errors in there that plain don't make sense: error: could not determine home folder and FAILED: Fetching https://www.post.japanpost.jp/zipcode/dl/kogaki/zip/ken_all.zip; 1.0 MiB (63.4%).

These errors indicate to me that something is majorly messed up. You could try cleaning your cached $srcdir as well and redownloading the sources. Perhaps there are file conflicts in there that won't show up. Otherwise, I really don't know what to make of this log.

By the way, judging by the fact that you had an existing ~/.cache/bazel that you needed to delete, I assume that you've previously managed to successfully build this package, right? And it's only with the latest update that you get this issue?

DEBUG: Rule 'zip_code_jigyosyo' indicated that a canonical reproducible form can be obtained by modifying arguments integrity = "sha256-8AEhfa3WhIQcMbHspq6gXuyRjxR6VIcQRD0I/4LCjIo="
DEBUG: Repository zip_code_jigyosyo instantiated at:
  /home/loqusion/mozc/src/mozc-git/src/WORKSPACE.bazel:241:13: in <toplevel>
Repository rule http_archive defined at:
  /home/loqusion/.cache/bazel/_bazel_loqusion/1740d625a2d23b8100ac375e0bfd1640/external/bazel_tools/tools/build_defs/repo/http.bzl:381:31: in <toplevel>
ERROR: /home/loqusion/mozc/src/mozc-git/src/data_manager/oss/BUILD.bazel:45:13: Executing genrule //data_manager/oss:mozc_dataset_for_oss@user_pos failed: (Exit 1): bash failed: error executing Genrule command (from target //data_manager/oss:mozc_dataset_for_oss@user_pos) /bin/bash -c ... (remaining 1 argument skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
error: could not determine home folder
INFO: Repository zip_code_ken_all instantiated at:
  /home/loqusion/mozc/src/mozc-git/src/WORKSPACE.bazel:235:13: in <toplevel>
Repository rule http_archive defined at:
  /home/loqusion/.cache/bazel/_bazel_loqusion/1740d625a2d23b8100ac375e0bfd1640/external/bazel_tools/tools/build_defs/repo/http.bzl:381:31: in <toplevel>
Target //gui/tool:mozc_tool failed to build
Use --verbose_failures to see the command lines of failed build steps.
ERROR: /home/loqusion/mozc/src/mozc-git/src/data_manager/oss/BUILD.bazel:45:13 Executing genrule //data_manager/oss:mozc_dataset_for_oss@pos_list_header failed: (Exit 1): bash failed: error executing Genrule command (from target //data_manager/oss:mozc_dataset_for_oss@user_pos) /bin/bash -c ... (remaining 1 argument skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
INFO: Elapsed time: 9.932s, Critical Path: 2.20s
INFO: 476 processes: 374 internal, 102 linux-sandbox.
ERROR: Build did NOT complete successfully
FAILED: 
    Fetching https://www.post.japanpost.jp/zipcode/dl/kogaki/zip/ken_all.zip; 1.0 MiB (63.4%)

I disabled ccache/distcc and deleted ~/.cache/bazel.

@Nocifer I tried your suggestions, but it must be some kind of misconfiguration that I am not aware of, as you thought. I ended up fresh install the Arch (since I couldn't solve the issue with anything I could think of), and as you might guess, no problem with installing on a fresh Arch. I may delete the post (including this one) later, since the cause is all on me. Thank you very much for you time.

@arix It looks like Bazel is not able to find the Python interpreter, even though it should have been installed as a build dependency. I can't think of any reason you should be getting such an error unless there is some kind of misconfiguration.

You could try to a) edit the bazel build command in the PKGBUILD (line 38) and add --sandbox_debug at the end, as your error log suggests, and then see where that gets you; or b) install Python manually beforehand and see if the script will work that way (I doubt it, but you never know).