Arch Linux User Repository

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.

Yeah, as I mentioned, the fact that almost all distros carry a very old version of Anki makes it seem highly suspect that something is very wrong with it. In fact that's what prompted me to try and build it manually, out of curiosity to see what kind of convoluted build process its devs have managed to create... only to find out that it's really as simple as I described in my previous comment: download the source, run a single Bazel command, done.

Reading @demize's last comment, I too got the impression that there's some bad blood here, and that they're actually more fed up with Anki's devs attitude and their changing the build process "yet again", rather than with the build process itself. It also doesn't help that as far as I can tell by skimming through the source files, the previous build process was convoluted as hell. The sad thing is that you've probably guessed correctly: switching to Bazel seems like an attempt on the devs' part to simplify the build process. Case in point, the 5 patches you mentioned are no longer needed and the sources now come in a single tarball. But they've definitely failed to get the message across :(

Anyway, I don't think me adopting this package would be any good, because there's already anki-release-source which does the job more than adequately. A better option would probably be to merge these two packages, i.e. remove anki-release-source and have its maintainer adopt this one instead and update it to the latest version.

Heya. Are we absolutely certain that this needs Bazel 4.0.0 to be built? Because I just removed the file .bazelversion from the project's root and proceeded to compile normally with Bazel 4.2.0, and I encountered no issues at all. Could it be that the devs only meant to pin 4.x.x as opposed to the previously used 3.x.x branch, and have simply neglected to account for the minor version updates? Whatever the case, I'd venture that here in Arch-land we could probably safely depend on the official, up-to-date Bazel.

EDIT: And another thing, the anki package has just been moved into the AUR and orphaned by its maintainer, so @AlexBocken I think you should consider adopting anki and bringing it up to date by merging it with this package.

Congratulations to your building Anki successfully.

I'll admit I haven't any time or will to try and build anki, considering all the "social proof", etc. As I said, I'm staying on the last official pkg for now. I figured it must be worth opening a discussion on GH, since almost all distros are leaving anki out-of-date for years. In Arch we don't do that, so the pkg was dropped to AUR.

@Nocifer, perhaps you can adopt this pkg? and work with the maintainers of the other anki pkgs in AUR to bring this up to date?

A few more points. Whether bazel is good or bad I don't know; it doesn't seem simple or easy to use. I think the thing is 1) anki hasn't been easy to build. Look at anki 2.1.35-3: there are 5 patches and 3 additional source tarballs. demize must have put much effort into it. (@Nocifer, if you or anyone else adopts this pkg, make sure to check if the patches are no longer needed.) 2) anki upstream has changed their build system multiple times, each time requiring packagers to rewrite their build scripts. Why did they switch to bazel, for example? If perchance they were also trying to make it easier to package anki, well, packagers haven't got the message!