Arch Linux User Repository

The checksum for ankitects-anki-core-i18n-aefd745.tar.gz is not correct.

Other checksums are either correct or skipped (for git and patches), which should be the right way to do things judging by a quick websearch of mine.

After correcting the checksum, I successfully built and installed Anki.

Oh man, I was working through this update (problem with git config and cargo), pre- checksum change. Finally expected it work and it didn't because I'd downloaded the new, broken PKGBUILD by accident. Thought I was going crazy.

Looks like the new maintainer just changed the version numbers and didn't touch any of the build instructions or even try to build it before releasing...

currently getting an error when updating anki through yay:

==> Validating source files with sha256sums...
    anki ... Skipped
    ankitects-anki-core-i18n-aefd745.tar.gz ... FAILED
    ankitects-anki-desktop-ftl-51320cd.tar.gz ... Passed
    ankitects-anki-desktop-i18n-67b07d5.tar.gz ... Passed
    0001-Move-aqt_data-to-sys.prefix-share.patch ... Skipped
    0002-Remove-bad-build-steps-from-makefiles.patch ... Skipped
    0003-Compile-.py-s-before-building-wheel.patch ... Skipped
    0004-Disable-auto-updates.patch ... Skipped
    0005-Make-pyenv-target-just-create-venv.patch ... Skipped
==> ERROR: One or more files did not pass the validity check!
error downloading sources: anki

Thanks for the catch!

Just a heads-up, there is already an unintended consequence. I should have warned you about it since I've already been bitten by it with another package.

Bazel requires Java 11 to work, but if the system's default Java is a different version (e.g. Java 16 as per the default Arch 'jre-openjdk' package), then even if Java 11 is installed as a make dependency, it won't be present in the PATH and thus Bazel will fail with this error (or at least it does so on my system):

==> Starting build()...
Extracting Bazel installation...
FATAL: Could not find system javabase. Ensure JAVA_HOME is set, or javac is on your PATH.
==> ERROR: A failure occurred in build().
    Aborting...

This can be solved in the PKGBUILD by modifying either JAVA_HOME or the system's PATH before running Bazel, e.g. in the latter case:

env PATH="/usr/lib/jvm/java-11-openjdk/bin/:$PATH" bazel build -c opt dist

For whatever reason, when I built this package the other day with babel40-bin I didn't have this issue, that's why I forgot all about it.

Thanks for all the discussion on this. Personally I had issues previously with compiling with bazel 4.2.0 for some reason.

This issue seems to have been on my side as a reinstall has cleared all issues. I would definitely be in favour of using bazel 4.2.0 instead of adding another package to the AUR with bazel40-bin which is not really necessary.

An update to the PKGBUILD is coming right up.

If we were talking about anything else other than the build system (e.g. a required library dependency or the compiler used) I'd be 101% for doing exactly what Anki's devs have ordained for us to do, in order to avoid headaches down the road.

But a build system has nothing to do with binary compatibility, it's just a glorified secretary used by the devs to orchestrate all the various build tools into an automated whole. And though I understand that arbitrary changes to even just the build system may still introduce unintended consequences if the project's instructions happen to be written for a specific version, IMHO it doesn't appear to be so in this case, since as you say it's not only me who has anecdotally managed to build with 4.2.0 but also anki-git's users (and I presume other people as well). And we already have a headache in the form of needing to maintain a separate AUR package (bazel40-bin) just for building this one.

Anyway, this all is just for discussion's sake. I have no vested interest in one or the other option, it's just that I thought this could maybe lessen the burden on the maintainer. After all, at the end of the day the build system used hardly matters as long as the project can be built successfully, so there's no "correct" choice here. But asking the devs about it would be a good idea.

anki-git does rm .bazelversion too to build with bazel. Someone more knowledgeable about bazel should contact upstream about this.

Now that anki is given to the community to figure out how to build, and I think there are quite some anki users, I'm sure we'll come to some working solution, including resolving potentially hidden issues.

IF indeed with bazel now anki is actually easier to build, then it's a problem of upstream messaging (which the GitHub issue would help to address), plus a collective wait-and-see attitude among packagers: one distro must move ahead first, and prove to others it's doable before the rest will follow.

I say this as an outside observer without any expertise in packaging. I know precisely zero about bazel. I only find this case curious, and hope as a user things become easier for packagers and therefore users too.