Arch Linux User Repository

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

@Nocifer ah, you're right. don't know how that happened: must've gotten lost messing around with my linux containers. thank you!

@BudgieUser Yeah that's annoying when it happens, it's probably due to network congestion that makes the connection time out and prevents a big repo from fully downloading in one go. Thankfully you can restart the build and the repo will continue downloading from the point it failed, and after it downloads once you can just keep it around for future rebuilds.

@Calimero But can SSH even be used on GitHub without adding an SSH key to your account?

@7cff pkgconf is not a dependency of this package because it's already a dependency of base-devel, which is a prerequisite for building AUR packages. If it fails to run then it's probably an issue of you not having installed base-devel.

this should have pkgconf as a build dependency. otherwise, the build fails when bazel attempts to access the qt_linux repository, as it'll fail to run pkgconf.

Related to BudgieUser's comment, I would like to suggest using SSH for github-hosted git repositories. HTTPS is an absolute pain as soon as there's a bit of latency or the connection isn't fast, and worse still you have to start all over again. It's as simple as replacing any https://github.com/author/repo URLs by ssh://git@github.com/author/repo.

Seems like latest update doesn't work for me:

remote: Compressing objects: 100% (293/293), done.
error: 7200 bytes of body are still expected2 MiB | 942.00 KiB/s 
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
==> ERROR: Failure while downloading mozc git repo
    Aborting...

EDIT: it's working now.

@Calimero AFAIU this would need me to check and verify which specific submodule commits are being used each time Mozc releases a new tagged version and update not only the PKGBUILD but also Bazel's scripts, which would be kind of a big amount of work, and for what? If you don't keep the submodules around in your $srcdir (which is the only reason why you'd need to re-clone them all the time) you'd still need to re-clone them all over again anyway, only the cloning would happen behind the scenes, by makepkg calling git as part of fetching the PKGBUILD's sources, instead of git doing it explicitly as part of prepare(). And this doesn't even take into account the fact that the already fragile Bazel would quite possibly go bonkers due to making it use external dependencies and would invalidate its cache which would increase the build times tenfold. Granted, that's not a 100% given, but knowing Bazel and its quirky nature it could very well happen.

In short, I don't really see a compelling need for changing the way the submodules are handled. Also, using dynamic linking via globally installed packages is unfortunately not supported either by Mozc (it explicitly only supports static linking) or by Bazel (it would require me to rewrite many of upstream's setup scripts).

EDIT: To clarify, my main issue is with Bazel, not with using git submodules as PKGBUILD sources. But to put my money where my mouth is, I'll experiment with such a setup in the next few days and verify firsthand whether Bazel will behave nicely or not.

EDIT 2: So after deliberating on it a bit more I realized I was talking nonsense. The submodules are updated via git independently of Bazel anyway, so keeping local copies of them around and copying them into $srcdir instead of fetching them into it from upstream should look exactly the same to Bazel and its cache system. Also, fetching just the latest changes of the submodules instead of cloning them from scratch every time is obviously an actual improvement because it's faster and it saves on bandwidth (I mean, it's almost like git was built to work like this in the first place...).

So, yeah. I'm just going to blame it on the heatwave that's been scrambling my brain for the past month. Thanks for the suggestion :)

Request for improvement: in order to not re-clone all the submodules all the time, here is how to handle them properly with makepkg: https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules

Or better yet, would it be possible to use archlinux packages for protobuf etc?

Sorry for the fsck up, I don't even know how I managed to do that. Package permissions have (hopefully) been fixed.

mozc_server and mozc_tool are installed with 6-- instead of 7--. Please revert the relevant changes in the pkgbuild

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.