Arch Linux User Repository

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

@asday This package normally receives an update once a month, i.e. when the UT dictionary puts out a new version, and along with UT it pulls in the latest monthly updates to Mozc. These last couple of months have been an exception to the rule, with 2 or 3 updates per month, some of them because of Mozc changes that introduced incompatibilities and/or build failures and required an update to address them, and some of them because for whatever reason there were multiple versions of UT released within a single month.

The problem is that, even when only the UT dictionary is updated, the package still requires recompilation because the way things currently work, the dictionary file is not loaded externally by Mozc but must rather be compiled into the Mozc binary itself - i.e. it's not a matter of simply updating the dictionary file and calling it a day.

As for the recompilation of the dependencies, which is mainly about protobuf: as far as I can tell by looking into it just now, it has long been kind of a pain for Bazel users (see e.g. here). You're right that it shouldn't be recompiling on each and every update of Mozc (I hadn't noticed it myself because on my system the whole process takes less than a couple of minutes to finish, so it never bothered me enough to make me look into what exactly it's doing when compiling) but to be completely honest with you, I have no idea why it does so. Maybe it's the way Bazel is set up and called from within the PKGBUILD, or maybe the build rules provided by Mozc are not written properly, or maybe it's some weird quirk of Bazel that needs to be identified and dealt with, or maybe it's something else entirely.

I'll try to look for a solution in the next few days, but I can't make any promises because Bazel is a terribly convoluted tool and I doubt I'll have much luck without seriously investing myself into learning its ins and outs. So for the time being, as tiring as it is for you and your laptop, you'll unfortunately have to bear with these huge updates :/

Good morning.

I regularly receive updates for this package, and installing them involves compiling for maybe a half hour and completely kneecapping my laptop while compiling. This makes it highly inopportune to update my laptop as I'm generally noticing there are updates available while I'm using it.

I notice that while it's compiling, it's compiling things such as protobuf, which I believe to be some library that is highly reuseable, and quite stable, thus unlikely to require recompilation every few days.

It would be nice if I didn't have to recompile the universe every couple of days. Is there some way to cache the built objects? Is there a reason they require building every time instead of being shared objects? Why does this package require updating so often - is it simply a dictionary update? If so, why is that not a simple data file change rather than something requiring recompilation? Am I even asking any of this in the right place?

Please do note that I am very very stupid, so I may have trouble understanding replies that assume my knowledge of a compiler toolchain or bazel or what have you.

Thank you.

That's because of the newly updated GCC toolchain. Just delete your Bazel cache folder and it should work.

~~~ Cannot build package ~~~

ERROR: /home/atri/.cache/bazel/_bazel_atri/e1bccde7c1bd24c3c95cbf2d98859651/external/com_google_protobuf/BUILD:155:11: Compiling src/google/protobuf/io/zero_copy_stream.cc [for host] failed: undeclared inclusion(s) in rule '@com_google_protobuf//:protobuf_lite':
this rule is missing dependency declarations for the following files included by 'src/google/protobuf/io/zero_copy_stream.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdint.h'
INFO: Elapsed time: 9.264s, Critical Path: 2.43s
INFO: 11 processes: 10 internal, 1 linux-sandbox.
FAILED: Build did NOT complete successfully
==> ERROR: A failure occurred in build().

Thanks @Nocifer, the package builds successfully.

@evgfilim1 Believe it or not, for the last couple of hours or so I've been unsuccessfully trying to incorporate these two --sandbox parameters you mentioned.

For one, if the specified paths do not already exist (or in other words, for this particular case, if the .ccache folder is missing because ccache isn't installed or hasn't already been used at least once) bazel will complain and fail the build.

Furthermore, even when the paths do exist and I can build successfully on my normal system, I can't for the life of me seem to build inside a chroot - no matter what I've tried, bazel will always complain about not having rw access to one path or another and proceed to fail the build.

I'm not sure if it's my incompetence or if bazel was simply not built to work with a tool like makechrootpkg, but the fact is that I need to be able to build Mozc inside a chroot, and I need to be able to do that in an automated and deterministic way (i.e. no removing these parameters from the PKGBUILD just for test-building in the chroot and re-adding them before I publish the package).

So with that in mind, and also because ccache is rarely worth the effort IMHO (and hence all this trouble), for the time being I will not add these parameters to the PKGBUILD. If and when I manage to find a working solution for using them alongside makechrootpkg (or if someone else provides me with one) I will add them in a future update.

Cannot compile package with ccache enabled. I've used this workaround:

diff --git a/PKGBUILD b/PKGBUILD
index 8538e3c..4ea512b 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -45,7 +45,7 @@ prepare() {
 build() {
     cd ${pkgname}-git/src

-    env PATH="/usr/lib/jvm/java-11-openjdk/bin/:$PATH" bazel build server:mozc_server gui/tool:mozc_tool --config oss_linux --compilation_mode opt
+    env PATH="/usr/lib/jvm/java-11-openjdk/bin/:$PATH" bazel build server:mozc_server gui/tool:mozc_tool --config oss_linux --compilation_mode opt --sandbox_writable_path "/run/user/$(id -u)" --sandbox_writable_path ~/.ccache
 }

 package() {

Please update to the latest BUILD=4479 The 4472 and lower have serious rendering issues:

https://github.com/google/mozc/issues/514

I changed my makepkg.conf to:

DLAGENTS=('file::/usr/bin/curl -gqC - -o %o %u'
          'ftp::/usr/bin/aria2c -UWget %u -o %o'
          'http::/usr/bin/aria2c -UWget %u -o %o'
          'https::/usr/bin/aria2c -UWget %u -o %o'
#         'ftp::/usr/bin/curl -gqfC - --ftp-pasv --retry 3 --retry-delay 3 -o %o %u'
#         'http::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
#         'https::/usr/bin/curl -gqb "" -fLC - --retry 3 --retry-delay 3 -o %o %u'
          'rsync::/usr/bin/rsync --no-motd -z %u %o'
          'scp::/usr/bin/scp -C %u %o')

And then using aria2c to download the link will only get a index.html

Using raw aria2c link is fine, though. Aria2c will get redirected several times and finally download the right file.

@escape0707 Why do you have to do that though? Does the link in the PKGBUILD not work for you?

I have to manually download and replace mozcdic-ut-20210822.tar.bz2 with this: https://ftp.halifax.rwth-aachen.de/osdn/users/32/32837/mozcdic-ut-20210822.tar.bz2