Package Details: mupdf-git 20240805.fac9da1c7-1

Git Clone URL: https://aur.archlinux.org/mupdf-git.git (read-only, click to copy)
Package Base: mupdf-git
Description: Lightweight PDF, XPS, and E-book viewer
Upstream URL: https://mupdf.com/
Licenses: AGPL3
Conflicts: mupdf, mupdf-gl, mupdf-tools
Provides: mupdf, mupdf-gl, mupdf-tools
Submitter: None
Maintainer: vesath
Last Packager: vesath
Votes: 17
Popularity: 0.000000
First Submitted: 2011-03-07 21:49 (UTC)
Last Updated: 2024-08-15 09:56 (UTC)

Required by (18)

Sources (5)

Latest Comments

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

<deleted-account> commented on 2012-04-16 19:07 (UTC)

Ok, openjpeg 1.5.0 is in [extra] now. Runs fine here :)

<deleted-account> commented on 2012-03-25 16:09 (UTC)

Thanks for your comment harryNID! I intend to remove the third party libraries as soon as the right version of openjpeg is in the repos! I don't like this workaround, so I'll remove it as soon as possible. But I think I'll keep the lines for the thirdparty stuff in the PKGBUILD, but commented of course, so it's easier for people to find this workaround.

<deleted-account> commented on 2012-03-24 20:19 (UTC)

@Army and danilo Just a note here. The problem here is not "a new libjpeg dependency that is apparently not provided in Arch" but rather one that is not updated yet. Mupdf is using version 1.5.0 of openjpeg and the Arch devs haven't updated it yet (they're still on 1.4-1, I think). I just fixed the the openjpeg PKGBUILD and compiled the new version for myself and mupdf is now back to building like a charm the old way. While danilo is correct in saying that it is an "easy and future-proof workaround" in case this happens again, I (that is myself) would prefer using our own libraries instead of "third-party" libraries which Arch already provides. Since Arch carries mupdf in their Repositories one would assume that they would also carry all the necessary dependencies as well. Where using the "third-party" technique would really prove useful is in a case such as we have now (a package is out-of-date) or possibly in the future if mupdf started needing a new dependency from a git version which Arch hasn't implemented yet. As soon as the dependency is either updated or resolved then I would switch back to using our own libraries. The above is just an opinion as it would be easy to "roll-your-own" version how you like. I just thought I would add my two-cents worth.

<deleted-account> commented on 2012-03-20 18:27 (UTC)

Awesome, thanks danilo! I'll update it in a minute.

dbrgn commented on 2012-03-20 16:48 (UTC)

The build currently fails, because there is a new libjpeg dependency that is apparently not provided in Arch. The easy and future-proof workaround is to download and include mupdf-thirdparty.zip into the build directory. I updated the PKGBUILD accordingly: http://pastebin.com/knTTXpmV. I left libxext in the dependencies, as I'm not sure what it's for, possibly it can also be removed.

<deleted-account> commented on 2012-01-29 11:10 (UTC)

Bug report is filed here http://bugs.ghostscript.com/show_bug.cgi?id=692821 I hope I got all informations that are required. Sorry for a new PKGBUILD update, the make process in the build function is completely not required, up till now we compiled mupdf twice... And nobody told me!!! ;)

<deleted-account> commented on 2012-01-29 10:33 (UTC)

Well, there is a memento.h in the sources, but copying it to /usr/include caused terrible compilation errors with e.g. fbpdf-git. I think this is a bug, since memento.h is sourced in the fitz.h header file, so it has to go there by the build process, but apparently it's not. I'll file a bug report, thanks for reminding me.

misc commented on 2012-01-28 22:10 (UTC)

memento.h isn't copied to /usr/include for me either, not even with the community version.

xmw commented on 2012-01-28 21:41 (UTC)

Don't you need memento.h for llpp? /usr/include/fitz.h refers to it.

<deleted-account> commented on 2012-01-28 11:07 (UTC)

BOY those are heavy changes :) Thanks for reporting, update comes in a minute.

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