Package Details: mozc-ut 3.33.6089.20260213-1

Git Clone URL: https://aur.archlinux.org/mozc-ut.git (read-only, click to copy)
Package Base: mozc-ut
Description: The Open Source edition of Google Japanese Input bundled with the UT dictionary
Upstream URL: https://github.com/google/mozc
Licenses: Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND CC0-1.0 AND CC-BY-2.5 AND CC-BY-SA-3.0 AND CC-BY-SA-4.0 AND GFDL-1.3-only AND GPL-2.0-only AND GPL-2.0-or-later AND MIT AND NAIST-2003 AND Unicode-3.0 AND LicenseRef-Okinawa-Dictionary
Provides: mozc
Submitter: naoina
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 28
Popularity: 0.82
First Submitted: 2020-11-04 02:00 (UTC)
Last Updated: 2026-02-13 12:54 (UTC)

Dependencies (7)

Required by (5)

Sources (41)

Pinned Comments

Nocifer commented on 2022-05-29 21:54 (UTC) (edited on 2023-08-22 09:33 (UTC) by Nocifer)

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

Latest Comments

1 2 3 4 5 6 7 Next › Last »

Nocifer commented on 2026-01-21 09:28 (UTC) (edited on 2026-01-21 09:29 (UTC) by Nocifer)

@hype-vhs I see that Bazel was just yesterday updated to version 9.0.0, so the issue is almost certainly that Mozc's build process is incompatible with the new Bazel version.

I've been long overdue in switching the PKGBUILD to using bazelisk instead of bazel anyway (as is upstream's explicit recommendation) so I've done that now.

Although bazelisk is supposed to be a drop-in replacement for bazel there is still a chance that I may have overseen something in this transition, so if any new issues arise please report them here so I can fix them asap.

hype-vhs commented on 2026-01-21 05:01 (UTC)

mozc-ut 3.33.6079.102.20260116-1 fails to build in a clean chroot.

ERROR: Traceback (most recent call last):
        File "/build/.cache/bazel/_bazel_builduser/9b5f81099b6a0eb268b7c9c659566f23/external/rules_cc+/cc/private/rules_impl/cc_import.bzl", line 184, column 17, in <toplevel>
                cc_import = rule(
Error in rule: at index 0 of provides, got element of type NoneType, want Provider

Nocifer commented on 2025-10-06 12:36 (UTC) (edited on 2025-10-06 12:36 (UTC) by Nocifer)

@Ducky Fixed. Upstream Mozc has been unusually overdue with its updates, and jawiki keeps old source archives available for a period of only 4 months, so on October 1st the jawiki-20250601 source archive that was listed in the PKGBUILD was removed.

Ducky commented on 2025-10-06 09:44 (UTC)

I'm getting an error while building:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (22) The requested URL returned error: 404
==> ERROR: Failure while downloading https://dumps.wikimedia.org/jawiki/20250601/jawiki-20250601-pages-articles-multistream-index.txt.bz2
    Aborting...

it seems that URL goes to a 404.

CapnAndyman commented on 2025-03-09 04:59 (UTC) (edited on 2025-03-09 05:10 (UTC) by CapnAndyman)

Looks like jigyosyo.zip has been updated and fails to pass checksum.

Error in download_and_extract: java.io.IOException: Error downloading [https://github.com/hiroyuki-komatsu/japanpost_zipcode/raw/refs/heads/main/jigyosyo.zip] to /home/andy/.cache/bazel/_bazel_andy/5efbefd536fe8968db20e02d6bb1ef4e/external/+_repo_rules7+zip_code_jigyosyo/temp8942015348367456745/jigyosyo.zip: Checksum was 1c56e79ff4c7f709778e0bf4dfbffdf939efd170845feccae986d22cf4373988 but wanted 0e62af72f56a3039409dc105057051df0e374c2e373a2a068172daaaa1a9af13

Nocifer commented on 2025-01-24 22:26 (UTC)

@raum_dellamorte Everything builds fine on my end as of a few minutes ago, and anyway Mozc doesn't/shouldn't use either Appimage or fuse for its build process.

Something is wrongly configured on your end, but I can't figure out what by reading this error log. I'm guessing that something you have installed is interfering with the build process and forcing it to call fusermount, which then fails for some unknown reason.

Are you trying to build via an AUR helper or manually? Or perhaps inside a container or VM or some such? Or perhaps you use some kind of tmpfs partition?

As an aside, if you had to create the polkitd user manually then something is very wrong with how you've installed/configured things, as that user and the accompanying polkitd group should have been created for you automatically by systemd. Perhaps this is a hint for some underlying issue that's also preventing you to build Mozc.

Lastly: try to build the package in a clean chroot. If nothing else, this will allow you to at least install and use it even if for the time being you can't find the error.

raum_dellamorte commented on 2025-01-24 11:00 (UTC)

I keep getting "fusermount: mount failed: Operation not permitted"

I installed fuse2 and can run AppImages, I did sudo rm -Rf ~/.cache/bazel. A comment suggested gcc13 was needed so I also tried installing that and making the related changes to PKGBUILD to use gcc13. Always the fusermount error. I couldn't get Flatpak to work until I manually added 'polkitd' as a system user, could it be something like that?

==> Starting build()...
Extracting Bazel installation...
Starting local Bazel server (8.0.1) and connecting to it...
DEBUG: /home/raum/.cache/bazel/_bazel_raum/9e7bc8e49e64b583f6fe2bd8adb482da/external/rules_android_ndk+/rules.bzl:28:14: Either the ANDROID_NDK_HOME environment variable or the path attribute of android_ndk_repository must be set.
INFO: Analyzed 2 targets (193 packages loaded, 11787 targets configured).
ERROR: /home/raum/dl/mozc-ut/src/mozc/src/data_manager/oss/BUILD.bazel:54:13: Executing genrule //data_manager/oss:mozc_dataset_for_oss@version failed: (Exit 127): bash failed: error executing Genrule command (from target //data_manager/oss:mozc_dataset_for_oss@version) /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
fusermount: mount failed: Operation not permitted
open dir error: No such file or directory

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
ERROR: /home/raum/dl/mozc-ut/src/mozc/src/data_manager/oss/BUILD.bazel:54:13: Executing genrule //data_manager/oss:mozc_dataset_for_oss@pos_matcher failed: (Exit 127): bash failed: error executing Genrule command (from target //data_manager/oss:mozc_dataset_for_oss@pos_matcher) /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
fusermount: mount failed: Operation not permitted
open dir error: No such file or directory

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
ERROR: /home/raum/dl/mozc-ut/src/mozc/src/data_manager/oss/BUILD.bazel:54:13: Executing genrule //data_manager/oss:mozc_dataset_for_oss@user_pos failed: (Exit 127): 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
fusermount: mount failed: Operation not permitted
open dir error: No such file or directory

Cannot mount AppImage, please check your FUSE setup.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 15.874s, Critical Path: 2.08s
INFO: 588 processes: 495 internal, 93 linux-sandbox.
ERROR: Build did NOT complete successfully
==> ERROR: A failure occurred in build().
    Aborting...

Nocifer commented on 2025-01-04 15:59 (UTC)

No, as far as I know Mozc will build just fine with Clang. This is an oversight of mine: back when I added the flag I didn't know that it isn't supported by LLVM, and when after a while I was informed about it I just figured that it probably wouldn't be long before I removed it anyway (I never expected that this bug would stay open for ~6 months), and the default system compiler is GCC, so there shouldn't be any real issues. Case in point, you're the first user in almost 6 months that has stumbled upon this (or at least, the first user who has reported it).

So as I said, please bear with this minor inconvenience until the next update, and in the meantime just change the flag and do the build normally.

tokisuno commented on 2025-01-04 12:21 (UTC)

@Nocifer should i be building with gcc then?

Nocifer commented on 2025-01-04 10:59 (UTC)

@tokisuno That's because you're trying to build with Clang, which does not support the -Wno-maybe-uninitialized compiler flag. For the time being you can just do what the error prompt says and change the flag to -Wno-uninitialized.

Upstream Mozc has already merged a proper fix for the issue that this flag was used as a stopgap for, so with the next update the flag will be removed from the PKGBUILD altogether.