Package Details: anki 24.06.3-2

Git Clone URL: https://aur.archlinux.org/anki.git (read-only, click to copy)
Package Base: anki
Description: Helps you remember facts (like words/phrases in a foreign language) efficiently
Upstream URL: https://apps.ankiweb.net/
Keywords: anki languages learning vocabulary
Licenses: AGPL3
Conflicts: anki-bin, anki-git, anki-qt5
Submitter: demize
Maintainer: AlexBocken
Last Packager: AlexBocken
Votes: 175
Popularity: 7.51
First Submitted: 2021-09-17 22:31 (UTC)
Last Updated: 2024-08-02 10:08 (UTC)

Latest Comments

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 30 Next › Last »

Munzu commented on 2022-04-27 15:25 (UTC)

Is this package supposed to build Anki with Qt6? I'm seeing Qt5 dependencies listed but when I install this package and go to Anki's "About", it says

Version ⁨2.1.51 (11b89b2f)⁩ Python 3.10.4 Qt 6.3.0 PyQt 6.3.0

MarcoDiFrancesco commented on 2022-04-27 11:09 (UTC)

@AlexBocken Rebuilding twice fixed the problem. Thanks!

AlexBocken commented on 2022-04-26 10:41 (UTC)

@MarcoDiFrancesco Have you tried building twice? (without deleting) I came across this error myself as well but it always went away on the second run.

MarcoDiFrancesco commented on 2022-04-26 10:38 (UTC) (edited on 2022-04-26 10:39 (UTC) by MarcoDiFrancesco)

Error when building sqlite3, is this problem related to the github issue?

Before building I deleted the ~/.cache/bazel directory. 

INFO: From Running Cargo build script libsqlite3_sys:
Build Script Warning: sqlite3/sqlite3.c: In function 'sqlite3Fts5IndexQuery':
Build Script Warning: sqlite3/sqlite3.c:228444:18: warning: 'memcpy' specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=]
Build Script Warning: 228444 |     if( nToken ) memcpy(&buf.p[1], pToken, nToken);
Build Script Warning:        |                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ERROR: /home/marco/.cache/yay/anki/src/anki-2.1.51/ts/editor/BUILD.bazel:35:15: Compiling Svelte ts/editor:svelte failed: Worker process did not return a WorkResponse:

E3LDDfrK commented on 2022-04-23 07:01 (UTC)

That one was messy. The tip to rebuild seems to work. Thanks.

AlexBocken commented on 2022-04-22 10:59 (UTC)

Creating an anki-qt6 seems like not a bad idea!

Nocifer commented on 2022-04-22 09:58 (UTC) (edited on 2022-04-22 10:05 (UTC) by Nocifer)

I consider breaking "quite a few addons" an absolute no-go, so if I were you I'd create a separate anki-qt6 (or some such) package and make sure it also provides anki, so that when a new user attempts to install anki via an AUR helper they'll be given the option of also installing (and thus become aware of the existence of) the more modern anki-qt6.

And in the future, when Qt6 becomes more prevalent and compatibility is no longer an issue, you switch this package to Qt6 by default, create (if needed, again for compatibility reasons) a separate anki-qt5 package, and kill anki-qt6 (i.e. merge it into this one to preserve comments/votes/etc).

EDIT: Or you can just go ahead and make the Qt6 switch in this package right now, and just create a new anki-qt5 package. It all depends on which add-ons will break - e.g. in my case I only really use AnkiConnect, so if that one is compatible I really don't care about making the switch. But my use case is not everybody's use case. And also keep in mind that Qt6 has theming issues in Qt5 environments, like e.g. the very prevalent KDE.

AlexBocken commented on 2022-04-22 09:27 (UTC)

I'm considering moving the package to using qt6 but this would break quite a few add-ons. Add-on compatibility has always been an issue with updating anki so I'm not quite sure how to proceed. Post your thoughts about moving from qt5 to qt6 here, I'm always open for other people's view on the matter.

AlexBocken commented on 2022-04-20 21:06 (UTC)

2.1.50 is out!

As always, the build process can throw some errors. Try to install a second time and/or clean ~/.cache/bazel and your AUR manager cache. This is a known issue of anki itself, not of this package.

@Nocifer, thanks for the help. Yes, .bazel/ was the solution. RTFM really can do wonders.

Nocifer commented on 2022-04-20 20:03 (UTC)

Hmm, I was under the impression that these bazel-* symlinks inside the source root are always created by default. Anyway, skimming through the commits that affect BUILD.bazel I found this one: "updates to the build process and binary bundles", which includes the following info:

All platforms:

- wheel outputs and binary bundles now go into .bazel/out/dist. While
not technically Bazel build products, doing it this way ensures they get
cleaned up when 'bazel clean' is run, and it keeps them out of the source
folder.

I'd say this .bazel/out/dist dir sounds like an interesting place to look for compiled wheels :P

If this turns out to be unhelpful, then I'd need to try and build 2.1.50 myself and use the output to look for a solution. Which means I'd appreciate it if you pointed me towards an updated PKGBUILD and updated patches (especially the latter).

« First ‹ Previous 1 .. 15 16 17 18 19 20 21 22 23 24 25 .. 30 Next › Last »