Arch Linux User Repository

Please don't flag this package as out-of-date, unless it's at least a couple days behind the current version. The AutoUpdateBot checks for updates once per 24h and updates automatically. Flagging it out-of-date before this automatic update only adds more noise to my inbox. Thank you.

@un_pogaz thanks, now we're checking candidates bidirectionally in the latest change. Though I agree it's unlikely, better handle it for completeness' sake.

@alllexx88 Thanks, and it inded more reliable than my quick naive idea.

Hmm, I suggest to also add a step when if we don't found a python-sphinx site-packages newer than the calibre interpreter, also browse the one's older and pick the most recent.

Since python packages can take time to be dump, it's not impossible (although highly unlikely) than calibre use a interpreter newest than the one available on the system. But it quiet pedantic at this point.

@ardency @un_pogaz thank you for your ideas and patches to make man building more reliable. I just pushed a change based on your input. Please see comments in PKGBUILD for details and tell me what you think.

@ardency Hello, not the maintainer of the package, but I know calibre that your patch will raise issue in the future.

Currently, calibre use python 3.14 wich is also the last released and the one in core/python, but it not alway the case! calibre may running on a version of python different than core/python, and since we run _build_man.py in calibre with it own buildit interpreter, the patch could target a folder that not exists.

So the patch handle this error but not correctly, my point is:
It garanted at some point that calibre python version and core/python version will different and so the building will fail. Is not a IF, is a WHEN.

My recomendation is to simply reverse the sort ordre so that the recent tree take the highest precedence.

 # Add system sphinx to path
-for p in sorted(__import__('glob').glob('/usr/lib/python3.*/site-packages')):
+for p in sorted(__import__('glob').glob('/usr/lib/python3.*/site-packages'), reverse=True):
     sys.path.insert(0, p)

EDIT: And as for possible incompatibilities between python versions, the language's permissiveness means their will mostly exception than rule, and so we can handle them on a case-by-case basis if they arise.

Been running into an issue building this for many moons now, and finally got around to triage and fix:

_build_man.py prepends every /usr/lib/python3.*/site-packages onto sys.path. The glob is sorted lexically, so 'python3.14' sorts before 'python3.4' .. 'python3.9'. Because each entry is inserted at index 0, iteration order is reversed and the oldest trees end up with the highest precedence. This results in a Python version other than the one calibre-debug is running being used to build the docs, causing it fail with:

sphinx.errors.ExtensionError: Could not import extension
  sphinx.builders.linkcheck (exception: No module named 'cgi')

In my case, Python 3.9 was selected. sphinx imports requests, and requests.utils does import cgi, which was removed from the stdlib in Python 3.13.

This patch to PKGBUILD relies on sys.version_info and appends to the list of versions instead, fixing the system version ordering such that the newest system path is selected: https://hastebin.dev/raw/ozukuxiton

It nice to see that the extras/calibre is now up to date. However I will not use it, and personaly I don't recomend it because is not the recomended way by the developper (that why aur/calibre-bin is great, it just a wrapper of the official intaller).

So I understand the criticism that the official installer does not embody the Linux spirit to making a extensive use of external dependencies like extras/calibre do, however this approach has been documented as causing errors and instability. From the official site:

The up-to-date list of dependencies that the official calibre binaries are bundled with, can be seen in sources.json. While calibre might work with versions of dependencies other than those listed there, it is not tested/supported. In addition to those dependencies various build time requirements such as pkg-config, a C/C++ compiler, etc are needed.

btw, a other warning, even if it related to source install but surely still relevant:

WARNING: calibre is a highly complex piece of software with lots of very finicky dependencies. If you install from source, you are on your own. Please do not open bug reports or expect any form of support. You have been warned.

So, such instability are marginal but I will not taking that risk for my most used sofware.

@kseistrup thanks for pointing it out. Had a look and 9.11.0-2 made onnxruntime an optional dependency, which is why I didn't spot it when I installed calibre.

https://gitlab.archlinux.org/archlinux/packaging/packages/calibre/-/commit/18357d333e427c248f567fd6f8f9947a75bcef07

@nomad2k I believe the extras/calibre package recently decided to pull in a huge hard dependency that was needed for [the optional] AI stuff in Calibre. So there was a reason to use aur/calibre-bin. I haven't followed extras/calibre, and perhaps said dependency has been removed even more recently.

calibre in the extras repo has been getting more regular updates since June/July and is currently on 9.12.

https://archlinux.org/packages/?q=calibre

Here is the original lockdown message: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/YPJ3FQYJTJXXY3RUXCYLMHUKHLIUNVFF/

You may be able to follow the situation by watching the list: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/

Stay vigilant. :)