Package Details: python2-pymupdf 1.16.10-1

Git Clone URL: https://aur.archlinux.org/python2-pymupdf.git (read-only, click to copy)
Package Base: python2-pymupdf
Description: Python bindings for MuPDF
Upstream URL: https://github.com/pymupdf/PyMuPDF
Licenses: AGPL3
Submitter: nabla
Maintainer: None
Last Packager: cges30901
Votes: 6
Popularity: 0.016636
First Submitted: 2015-12-07 14:49
Last Updated: 2019-12-26 14:55

Latest Comments

1 2 Next › Last »

cges30901 commented on 2019-11-20 14:16

@rien333 This sounds similar to FS#64154. Please try removing /home/rw/.cache/yay/python2-pymupdf/ and rebuilding. I can also make a PKGBUILD to install from Python wheel when I have time (EDIT: done).

rien333 commented on 2019-11-18 13:40

Not sure if anything can be done (and whether this is known already), but this now fails with:

==> Starting check()...
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/rw/.cache/yay/python2-pymupdf/src/PyMuPDF-1.16.7/build/lib.linux-x86_64-2.7/fitz/__init__.py", line 3, in <module>
    from fitz.fitz import *
  File "/home/rw/.cache/yay/python2-pymupdf/src/PyMuPDF-1.16.7/build/lib.linux-x86_64-2.7/fitz/fitz.py", line 18, in <module>
    from . import _fitz
ImportError: /usr/lib/libmupdf.so: undefined symbol: jbig2_ctx_new
==> ERROR: A failure occurred in check().

alium commented on 2019-10-29 19:24

thank you!

cges30901 commented on 2019-10-29 15:10

@akobel @alium Now I am the new maintainer of this package, and I have changed it to build from source.

cges30901 commented on 2019-10-06 09:20

@alium: There was a package called python-mupdf that built PyMuPDF from source tarball, but now it is deleted.

@akobel: Your PKGBUILD doesn't work for me.

EDIT: For the build error for python2, see Issue #320. SWIG is needed if you download source from Github, but it's not needed if you download source from PyPI, so this error is not present.

akobel commented on 2019-09-22 17:29

@alium: The reason was that upstream used to only provide releases as wheels, not as source tarballs.

That's not a reason anymore. The default procedure works, but as far as I can see, only for Python3 (with python2 setup.py, there's a TypeError: super() taking at least 1 argument). In short, this package (as python2-pymupdf is the base) seems outdated beyond quick fixes, unless anyone wants to whack it until it works, i.e., backport via the PKGBUILD.

pkgname=python-pymupdf

pkgver=1.16.2

pkgrel=1

pkgdesc='Python bindings for MuPDF'

arch=('x86_64')

url='<https://github.com/pymupdf/PyMuPDF>'

license=('AGPL3')

depends=('python')

makedepends=('swig')

source=("${url}/archive/${pkgver}.tar.gz")

sha256sums=('5070304b1b391d070fea0e2f731ee85dd858cab556fb949762ed0e05c888b97c')

package() {

cd "${srcdir}/${_pkgname}-${pkgver}"

python setup.py build

python setup.py install --root="$pkgdir" --optimize 1

}

(minus those angle brackets in the URL) works.

@nabla: Do you still want to maintain this package? What's your stance on @alium's proposal, and do you think Python2 compatibility can be achieved easily?

alium commented on 2019-09-10 08:30

stupid question: why you can not use normally

python setup.py build

python setup.py install --root="$pkgdir" --optimize=1

as others python packages is [extra/community]??

akobel commented on 2019-01-22 12:19

@wenbushi: What matters IMHO is that two files are downloaded, but only one is necessary if the user only needs either Python 2 or 3. Nitpicking: The package name is not misleading, as there are two distinct package names for the two distinct packages that are built from the common package base. And it seems to be customary to use one of the package names as the name for the base, too, for those python packages (which might not necessarily be a good idea).

Anyway, let's leave that up to @nabla - unlike the missing --ignore-installed, it doesn't affect the usability of the package, so it's not a huge concern to me.

wenbushi commented on 2019-01-21 11:36

@akobel: Yeah, perhaps I didn't make myself clear. What only matters is that the package name may cause a little confusion.

akobel commented on 2019-01-20 14:07

@wenbushi: Ah, now I see your point; I though you refered to the build problem mentioned by marlemion.

True: For the user who only needs one package, separate PKGBUILDs have the benefit that you only download one wheel. That wasn't the case for "real" builds from source, where you base both packages on the same source. From a maintenance point of view, one common PKGBUILD is slightly more convenient, I guess.

So, no strong opinion from my side (but then, I currently have both versions installed).