Package Details: mupdf-git 20210319.33e4e2a3d-1

Git Clone URL: (read-only, click to copy)
Package Base: mupdf-git
Description: Lightweight PDF, XPS, and E-book viewer
Upstream URL:
Licenses: AGPL3
Conflicts: mupdf, mupdf-gl, mupdf-tools
Provides: mupdf, mupdf-gl, mupdf-tools
Submitter: None
Maintainer: vesath
Last Packager: vesath
Votes: 14
Popularity: 0.000000
First Submitted: 2011-03-07 21:49
Last Updated: 2021-03-24 18:31

Required by (21)

Sources (5)

Latest Comments

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

Anonymous comment on 2013-05-27 17:15

Awesome, thanks for the info!

vesath commented on 2013-05-27 16:44

Army: You only need to embed openjpeg (not all thirdparty libraries) since mupdf switched to the openjp2 interface. See:

Anonymous comment on 2013-05-27 12:45

Looks like this package doesn't build right now, if we use freetype2, jbig2dec, libjpeg and openjpeg from the repos. So I added a prepare function, which loads the latest version of the third party tools. If you use the prepare function, please use the commented depends line.

Anonymous comment on 2013-04-08 09:57

Thanks for your comment.

I know that those entries aren't necessary, but I want to be consistent with my packages and the way it is written now makes it easier for me, because the packages are created from a prototype PKGBUILD, where I then only have to include _pkgname. Since there are no official guidelines, I had to come up with a solution that's practical for me, and this is how I created this and my other git packages.

TrialnError commented on 2013-04-07 21:25

Two minor notices. The git+git is not necessary. Just the git:// url is enough.
The git+/svn+/etc is only necessary if you have a http:// url for a repo

And the mupdf:: is also not necessary. As the cloned repo will have the name mupdf
Would be necessary if it would download to muPDF, or so

TrialnError commented on 2013-04-07 20:56

One minor notice. The git+git is not necessary. Just the git:// url is enough.
The git+/svn+/etc is only necessary if you have a http:// url for a repo

Anonymous comment on 2013-04-05 22:34

So, I've updated the PKGBUILD according to pacman 4.1's changes. Please test it and tell me if anything is wrong.

Anonymous comment on 2012-04-16 19:07

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

Anonymous comment on 2012-03-25 16:09

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.

Anonymous comment on 2012-03-24 20:19

@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.