Package Details: mozc-ut 2.28.5029.102.20230305-1

Git Clone URL: (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:
Licenses: GPL2, custom, BSD, LGPL, MIT, Apache, CCPL
Conflicts: mozc
Provides: mozc
Submitter: naoina
Maintainer: Nocifer
Last Packager: Nocifer
Votes: 16
Popularity: 1.02
First Submitted: 2020-11-04 02:00 (UTC)
Last Updated: 2023-03-05 08:22 (UTC)

Required by (4)

Sources (10)

Pinned Comments

Nocifer commented on 2022-05-29 21:54 (UTC)

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/ [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/':
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.

Latest Comments

1 2 3 4 Next › Last »

Nocifer commented on 2023-01-27 14:57 (UTC)

@Phantasm Indeed, and it even says so on the tin (#!/bin/bash). Thanks for reporting it.

Phantasm commented on 2023-01-27 11:33 (UTC) (edited on 2023-01-27 11:35 (UTC) by Phantasm)

Package fails to build in prepare() when /bin/sh is not bash.

sh ./ needs to be changed to bash

==> Starting prepare()...
Cloning into '/tmp/mozc-test/src/mozc-ut-git/src/third_party/protobuf'...
Submodule path 'third_party/abseil-cpp': checked out '215105818dfde3174fe799600bb0f3cae233d0bf'
Submodule path 'third_party/breakpad': checked out '216cea7bca53fa441a3ee0d0f5fd339a3a894224'
Submodule path 'third_party/gtest': checked out '58d77fa8070e8cec2dc1ed015d66b454c8d78850'
Submodule path 'third_party/gyp': checked out '9ecf45e37677743503342ee4c6a76eaee80e4a7f'
Submodule path 'third_party/japanese_usage_dictionary': checked out 'e5b3425575734c323e1d947009dd74709437b684'
Submodule path 'third_party/jsoncpp': checked out '11086dd6a7eba04289944367ca82cea71299ed70'
Submodule path 'third_party/protobuf': checked out 'cc7b1b53234cd7a8f50d90ac3933b240dcf4cd97'
Submodule 'third_party/benchmark' ( registered for path 'third_party/protobuf/third_party/benchmark'
Submodule 'third_party/googletest' ( registered for path 'third_party/protobuf/third_party/googletest'
Cloning into '/tmp/mozc-test/src/mozc-ut-git/src/third_party/protobuf/third_party/benchmark'...
Cloning into '/tmp/mozc-test/src/mozc-ut-git/src/third_party/protobuf/third_party/googletest'...
Submodule path 'third_party/protobuf/third_party/benchmark': checked out '5b7683f49e1e9223cf9927b24f6fd3d6bd82e3f8'
Submodule path 'third_party/protobuf/third_party/googletest': checked out '5ec7f0c4a113e2f18ac2c6cc7df51ad6afc24081'
./ 17: [[: not found
./ 21: [[: not found
./ 25: [[: not found
./ 29: [[: not found
./ 33: [[: not found
./ 37: [[: not found
./ 41: [[: not found
./ 45: [[: not found
remove_duplicate_ut_entries.rb:24:in `initialize': No such file or directory @ rb_sysopen - mozcdic-ut.txt (Errno::ENOENT)
        from remove_duplicate_ut_entries.rb:24:in `new'
        from remove_duplicate_ut_entries.rb:24:in `<main>'
--2023-01-27 12:26:33--
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving (, 2620:0:861:2:208:80:154:142
Connecting to (||:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 13987893 (13M) [application/octet-stream]
Saving to: 'jawiki-latest-all-titles-in-ns0.gz'

jawiki-latest-all-titles-in-ns0.gz                                     100%[=========================================================================================================================================================================>]  13.34M  1.17MB/s    in 9.8s    

2023-01-27 12:26:43 (1.36 MB/s) - 'jawiki-latest-all-titles-in-ns0.gz' saved [13987893/13987893]

count_word_hits.rb:16:in `split': invalid byte sequence in US-ASCII (ArgumentError)
        from count_word_hits.rb:16:in `<main>'
apply_word_hits.rb:21:in `initialize': No such file or directory @ rb_sysopen - jawiki-latest-all-titles-in-ns0.hits (Errno::ENOENT)
        from apply_word_hits.rb:21:in `new'
        from apply_word_hits.rb:21:in `<main>'
cat: /tmp/mozc-test/src/merge-ut-dictionaries/src/mozcdic-ut.txt: No such file or directory
==> ERROR: A failure occurred in prepare().

soya_daizu commented on 2023-01-20 15:03 (UTC) (edited on 2023-01-21 08:47 (UTC) by soya_daizu)

The UT dictionary project has moved over to a new repository and this package probably needs to be updated.

The dictionary now consists of a several split pieces depending on its source. The word costs has to be calculated and the packages need to be merged into one on the user's side using this script:

There also seems to be an official PKGBUILD provided in the repository.

Sharparam commented on 2022-12-20 19:11 (UTC)

No longer builds with Bazel 6.0.0 (which seems to have arrived to Arch today). Downgrading Bazel to 5.3.2-1 makes it build again.

The output when trying to makepkg -c with Bazel 6.0.0 installed is:

==> Making package: mozc-ut 2.28.4950.102.20221022-1 (2022-12-20T20:02:04 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating mozc-ut-git git repo...
  -> Found mozcdic-ut-20221022.tar.bz2
==> Validating source files with sha256sums...
    mozc-ut-git ... Skipped
    mozcdic-ut-20221022.tar.bz2 ... Passed
==> Extracting sources...
  -> Creating working copy of mozc-ut-git git repo...
Reset branch 'makepkg'
  -> Extracting mozcdic-ut-20221022.tar.bz2 with bsdtar
==> Starting prepare()...
==> Removing existing $pkgdir/ directory...
==> Starting build()...
ERROR: /home/sharparam/.cache/bazel/_bazel_sharparam/21bca58cd528f6af63583eb61d975ee6/external/bazel_tools/platforms/BUILD:59:6: in alias rule @bazel_tools//platforms:osx: Constraints from @bazel_tools//platforms have been removed. Please use constraints from @platforms repository embedded in Bazel, or preferably declare dependency on See for details.
ERROR: /home/sharparam/.cache/bazel/_bazel_sharparam/21bca58cd528f6af63583eb61d975ee6/external/bazel_tools/platforms/BUILD:59:6: Analysis of target '@bazel_tools//platforms:osx' failed
ERROR: /home/sharparam/repos/ errors encountered resolving select() keys for //gui/tool:mozc_tool
ERROR: Analysis of target '//gui/tool:mozc_tool' failed; build aborted: 
INFO: Elapsed time: 0.049s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
==> ERROR: A failure occurred in build().

Possibly relevant issue?:

Nocifer commented on 2022-09-04 15:35 (UTC) (edited on 2022-09-04 15:53 (UTC) by Nocifer)

@Misaka13514 Alright, I found the problem: howdy's PKGBUILD author has opted to place the howdy binary in /lib/security/howdy/ and set the permissions for that folder to 600 (yes, 600, not even 700), and then symlink /usr/bin/howdy to that.

As a result, when Bazel tries to scan /usr/bin it tries to follow the symlink and fails to access /lib/security/howdy due to the extremely strict permissions. In fact, on my system, even trying to run howdy from the command line results in a permission denied error as well.

This is IMHO a glaring packaging issue, and the only reason no one has flagged it as such so far is because AFAIU howdy's post-install configuration includes enabling it to be used through PAM, so the problematic folder is actually accessed with elevated privileges.

But Bazel (for example; any other app or build tool that relies on scanning /usr/bin will experience the same issue) will break with such strict permissions, so it should definitely be fixed. I'll report this to howdy's AUR page.

Misaka13514 commented on 2022-09-04 15:00 (UTC) (edited on 2022-09-04 15:41 (UTC) by Misaka13514)

But it didn't get fixed, I had to do it every time when the package updates. I also solved it this way last time. Can you help me to try makepkg after installing howdy?

EDIT: Wow, great! Thank you very much!

Nocifer commented on 2022-09-04 14:56 (UTC) (edited on 2022-09-04 14:57 (UTC) by Nocifer)

@Misaka13514 See my edit of the previous comment. What's your echo $PATH output like? Also, perhaps try this: uninstall Howdy, and try to install Mozc. Afterwards re-install Howdy and check to see what goes on during setup.

EDIT: And that's what happens when you only read half the comment and immediately begin to reply back. Good for you that you solved your issue :)

Misaka13514 commented on 2022-09-04 14:51 (UTC) (edited on 2022-09-04 15:01 (UTC) by Misaka13514)

@Nocifer I tried sudo rm -rf /home/user/.cache/bazel/ but after that it still couldn't be built. I still got the same error. But I can successfully build by uninstalling howdy first. I was also able to successfully install howdy after this.

$ echo $PATH
/home/user/.local/bin /usr/bin/core_perl /usr/bin/vendor_perl /usr/bin/site_perl /usr/bin /usr/local/bin
$ yay -Ql howdy | grep bin
howdy /usr/bin/
howdy /usr/bin/howdy

Nocifer commented on 2022-09-04 14:41 (UTC) (edited on 2022-09-04 14:51 (UTC) by Nocifer)

@Misaka13514 Reading your log, it seems as though Bazel is trying to use some dependency from another package's cache folder, in this case howdy, but that folder has permission issues and so the setup fails.

This is due to either Bazel being able to cross-reference cached dependencies (doubtful) or Bazel's cache having become FUBARed for some reason or another.

I'd first try to chown -R 1000:1000 on /home/user/.cache/bazel/_bazel_user/8c334454d17c5bf9bb4b4282bb388c81 and run the setup again; if it's indeed just a permission issue, the setup should proceed normally. If not, then I'd delete /home/user/.cache/bazel/_bazel_user/8c334454d17c5bf9bb4b4282bb388c81 altogether, and that should almost certainly fix the issue.

EDIT: Hmm, I just realized that howdy doesn't even use Bazel. I think this tidbit here is the actual issue: error globbing [bin/*]. Have you perhaps tried to edit your $PATH or something like that?

Misaka13514 commented on 2022-09-04 12:23 (UTC)

I don't know why it doesn't build properly after I install howdy.

==> Starting build()...
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
ERROR: /home/user/.cache/yay/mozc-ut/src/mozc-ut-git/src/gui/tool/BUILD.bazel:96:18: no such package '@qt_linux//': error globbing [bin/*] op=FILES: /home/user/.cache/bazel/_bazel_user/8c334454d17c5bf9bb4b4282bb388c81/external/qt_linux/bin/howdy (Permission denied) and referenced by '//gui/tool:mozc_tool'
ERROR: Analysis of target '//gui/tool:mozc_tool' failed; build aborted: Analysis failed
INFO: Elapsed time: 12.069s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (38 packages loaded, 138 targets configured)
    Fetching @local_config_cc; fetching
==> ERROR: A failure occurred in build().