Arch Linux User Repository

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

@Nocifer ah thanks that put me in the right direction : I have a minimal (not complete, just the build/device management tools) Android SDK installed in /opt/android-sdk and have $ANDROID_HOME set to that. Unsetting $ANDROID_HOME made the build work - didn't think the presence of an external environment variable would enable additional build options!

@frnx No, the Android SDK is certainly not necessary for building the package, but until very recently a small fix was required in the PKGBUILD in order to successfully build when the Android SDK and/or NDK are not present on the system, but that was rendered obsolete by a recent upstream commit and was removed.

In your case though, if I understand the error log correctly, it seems that you do have the Android SDK installed at /opt/android-sdk, but apparently you have installed it by hand/outside the Android SDK Manager/whatever else, and so the build environment does detect it and tries to include it in the build but then somehow deems it as a "corrupt" installation (missing APIs) and subsequently fails.

If so, then that's a different issue altogether. If you haven't already solved it yourself (this is a very late reply after all) you could try forcing the build process to build without the Android SDK by adding unset ANDROID_HOME (and/or whatever other relevant env var may be pointing to your Android SDK installation) in the PKGBUILD, at the top of the build() function (i.e. before the build command), and see where that gets you.

I'm getting some errors:

Starting local Bazel server (9.0.2) and connecting to it...
INFO: Repo rules_android++android_sdk_repository_extension+androidsdk defined by rule _android_sdk_repository in @@rules_android+//rules/android_sdk_repository:rule.bzl
ERROR: /home/****/.cache/bazel/_bazel_****/e8fe8b673fb64bd3af47228261ba317a/external/rules_android+/rules/android_sdk_repository/rule.bzl:114:13: An error occurred during the fetch of repository 'rules_android++android_sdk_repository_extension+androidsdk':
   Traceback (most recent call last):
    File "/home/****/.cache/bazel/_bazel_fx/e8fe8b673fb64bd3af47228261ba317a/external/rules_android+/rules/android_sdk_repository/rule.bzl", line 114, column 13, in _android_sdk_repository_impl
        fail("No Android SDK apis found in the Android SDK at %s. Please install APIs from the Android SDK Manager." % android_sdk_path)
Error in fail: No Android SDK apis found in the Android SDK at /opt/android-sdk/. Please install APIs from the Android SDK Manager.
ERROR: Analysis of target '//gui/tool:mozc_tool' failed; build aborted: No Android SDK apis found in the Android SDK at /opt/android-sdk/. Please install APIs from the Android SDK Manager.
INFO: Elapsed time: 4.572s, Critical Path: 0.07s
INFO: 1 process: 1 internal.
ERROR: Build did NOT complete successfully

I tried deleting the Bazel cache but got the same error. Is the Android SDK actually necessary for building just the Linux package ?

Right, so these are the b2sums from the previous version of the PKGBUILD.

Are you perhaps trying to build the package without having cleared the $srcdir first? If that is the case, then what's probably happening is that makepkg finds the previous versions of the two zips already present in the $srcdir and, because they always have the same name regardless of version/date, it marks them as satisfied dependencies because it obviously can't know any better; that is, until it eventually checks them against the b2sums and proceeds to fail the build because it realizes they're not the correct files after all.

I was always afraid that something like this could happen at some point; that's why it's good practice to manually add version numbers to a PKGBUILD's sources, but for some reason I never got around to do that for these two zips until now. I've pushed a fix for it, so if it's indeed the cause of your issue, from now on things should always work as expected.

@Nocifer not the same person but I bumped into this issue as well. Here's the sums:

$ b2sum jigyosyo.zip
46cb54e9d9ee183031dbda9cecbbcf24a341488a0320286f264fb2f9e44638373f432463bbfd2fadaa65f64dba9afce9ca4ae01b8315f3853dcf6b8361e1339d  jigyosyo.zip

$ b2sum ken_all.zip
03879037406a9d95c33d14bbde6fdd33acae0e6fda328e960c9f10aad74f2f34353d8b03e98ea247659587821d839783be2f031c3e756eac292ec52094c7ede6  ken_all.zip

Manually removing the zip files and rebuilding seems to have fixed it. They were valid zip files, but the contained csv seemed to be slightly different. Maybe a due to Github blip?

I'm not seeing the issue on my end, both the b2sums in the PKGBUILD and the sha256sums in MODULE.bazel match the two downloaded zips.

What sums do you get if you run b2sum jigyosyo.zip and b2sum ken_all.zip in $srcdir?

The jigyosyo.zip and ken_all.zip sources are failing the b2sums. Should probably get that fixed.

@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.