Package Details: calibre-git 7.2.0.r2.g96211be30e-1

Git Clone URL: https://aur.archlinux.org/calibre-git.git (read-only, click to copy)
Package Base: calibre-git
Description: Ebook management application
Upstream URL: https://calibre-ebook.com
Licenses: GPL3
Conflicts: calibre, calibre-common, calibre-python3
Provides: calibre
Replaces: calibre-common-git, calibre-python3-git
Submitter: eschwartz
Maintainer: alerque (eschwartz)
Last Packager: alerque
Votes: 18
Popularity: 0.78
First Submitted: 2015-08-09 15:02 (UTC)
Last Updated: 2024-03-26 08:43 (UTC)

Dependencies (56)

Required by (13)

Sources (3)

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

eschwartz commented on 2019-10-30 03:07 (UTC)

@doctorguapo, I have no idea why that would happen. Does it build in a clean chroot? Does pacman -Qkk qt5-base report any issues? Can you double-check in the output of pacman -Qi qt5-base that you're using the package from the official repos?

For some reason, it would seem you're missing some formats in the output of:

python -c "from PyQt5.QtGui import QImageReader; print([f.data().decode('utf-8') for f in QImageReader.supportedImageFormats()])"

c-reeder commented on 2019-10-25 22:04 (UTC)

For whatever reason, everything compiles fine for me, but when I get to the check() phase, several tests fail with the same error:

ValueError: Failed to export image as JPEG with error: Unsupported image format

Then at the end, it gives me:

AssertionError: Items in the second set but not the first: 'jpg' 'gif' 'svg' 'ico' : Qt doesn't seem to be able to load some of its image plugins. Available plugins: {'xpm', 'xbm', 'pgm', 'ppm', 'png', 'bmp', 'pbm'}

This seems very strange to me given that according to https://doc.qt.io/qt-5/qtimageformats-index.html jpg is one of the file types supported by default.

eschwartz commented on 2019-04-24 19:03 (UTC)

Given recent efforts to port calibre to python3, which are finally reaching an interesting stage, I have turned this into a split package providing a python3 component. Some things work, some things don't, so I strongly expect you'll want to have the python2 version available at a minimum... so they will share many files and the python3 version will depend on the python2 version.

I provide prebuilt packages in my custom repository, signed by my TU packaging key: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#eschwartz

See https://github.com/kovidgoyal/calibre/pull/870 for more discussion on the port.

eschwartz commented on 2019-01-28 13:42 (UTC)

I don't understand your meaning at all. For one, neither of those two are dependencies at all -- one is a makedepends and the other is a checkdepends. On top of that, why would sip have anything to do with Wayland vs. xorg? At least xorg-server-xvfb is genuinely an xorg-related package, if only it weren't merely a checkdepends.

soloturn commented on 2019-01-28 09:45 (UTC)

on wayland the dependency xorg-server-xvfb-1.20.3-1-x86_64, and sip seems surprising?

tmrd commented on 2018-07-23 18:27 (UTC) (edited on 2018-07-23 18:28 (UTC) by tmrd)

@evamvid I've tried adding the -git suffix to rapydscript-ng but to no avail, makepkg still outputs

==> ERROR: 'pacman' failed to install missing dependencies.
==> WARNING: Failed to remove installed dependencies.

evamvid commented on 2018-06-27 00:27 (UTC)

to get this to build, replace rapydscript-ng in the PKGBUILD with rapydscript-ng-git

aspirogrammer commented on 2018-06-10 04:38 (UTC)

It seems that rapydscript-ng does not exist.

arethis commented on 2018-01-30 01:31 (UTC) (edited on 2018-01-30 01:32 (UTC) by arethis)

I got the following error after installing and running the package:

Traceback (most recent call last): File "/usr/bin/calibre", line 20, in <module> sys.exit(calibre()) File "/usr/lib/calibre/calibre/gui_launch.py", line 71, in calibre init_dbus() File "/usr/lib/calibre/calibre/gui_launch.py", line 43, in init_dbus from dbus.mainloop.glib import DBusGMainLoop, threads_init File "/usr/lib/python2.7/site-packages/dbus/mainloop/glib.py", line 29, in <module> from _dbus_glib_bindings import DBusGMainLoop, gthreads_init ImportError: libdbus-glib-1.so.2: cannot open shared object file: No such file or directory</module></module>

Installed lib32-dbus-glib, and it works fine, but it's apparently not a dependency...

Running x86_64 Linux 4.14.15-1-ARCH

eschwartz commented on 2017-12-07 16:22 (UTC) (edited on 2017-12-07 16:24 (UTC) by eschwartz)

No, that won't work. It's a silly stackexchange question to begin with.

There is a reason that despite numerous requests, this was never implemented in makepkg already. The reason is because the pkgver() function depends on having the full git history, or at least the history since the latest tag, available. Your suggestion breaks cherry-picking and non-default branches and pinned commits, none of which this package uses but which other packages do use, and it also breaks git describe which this package does use.

It is a one-time expense, and you can save the clone for future builds by setting $SRCDEST in your makepkg.conf