AUR (en) - mupdf-git

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: mupdf-git 20220124.c285dd695-1

Package Actions

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:	16
Popularity:	0.095465
First Submitted:	2011-03-07 21:49 (UTC)
Last Updated:	2022-01-24 22:20 (UTC)

Dependencies (10)

gumbo-parser
harfbuzz (harfbuzz-git, harfbuzz-minimal-git)
jbig2dec
libjpeg-turbo (libjpeg-turbo-minimal-git, mozjpeg-git, mozjpeg, libjpeg-turbo-git)
libxrandr (libxrandr-git)
mujs (mujs-git)
openjpeg2 (openjpeg-git)
git (git-git, git-vfs, git-run-command-patch-git) (make)
glu (glu-git) (make)
libxi (libxi-git) (make)

Required by (20)

caj2pdf-git (requires mupdf-tools)
caj2pdf-qt (requires mupdf-tools)
hub-kids (requires mupdf) (optional)
hub-young (requires mupdf) (optional)
hunter (requires mupdf-tools) (optional)
hunter-git (requires mupdf-tools) (optional)
img2pdf-git (requires mupdf-tools) (check)
impressive (requires mupdf-tools)
llpp-git (requires mupdf)
llpp-git (requires mupdf) (make)
mcomix (requires mupdf-tools) (optional)
mcomix-git (requires mupdf) (optional)
mcomix-gtk3-git (requires mupdf-tools) (optional)
neovim-latex-previewer-git (requires mupdf)
openlp (requires mupdf) (optional)
openlp-git (requires mupdf) (optional)
pdftxt (requires mupdf)
vim-live-latex-preview (requires mupdf)
ws-session-git (requires mupdf) (optional)
xake-git (requires mupdf-tools)

Sources (5)

Latest Comments

vesath commented on 2019-10-30 22:31 (UTC)

rien333: Thanks for noticing. I see no point splitting this package into a viewer and separate tools. So I've added what you suggested to provides/conflicts, as well as mupdf-gl since we're in fact using the binary from the GL platform. (Upstream does not recommend using the x11 platform binary if you can avoid it.)

rien333 commented on 2019-10-27 23:08 (UTC) (edited on 2019-10-27 23:08 (UTC) by rien333)

@vesath Currently, this package builds some files provided by mupdf-tools:

error: failed to commit transaction (conflicting files)
mupdf-git: /usr/bin/muraster exists in filesystem (owned by mupdf-tools)
mupdf-git: /usr/bin/mutool exists in filesystem (owned by mupdf-tools)
mupdf-git: /usr/share/man/man1/mutool.1.gz exists in filesystem (owned by mupdf-tools

Maybe add mupdf-tools to conflicts or disable creating these files?

vesath commented on 2017-01-25 22:10 (UTC) (edited on 2017-01-25 22:25 (UTC) by vesath)

misc: There's no "must". Trusted users do as they please. Personally I consider Arch a shared-libs-based distro so I won't waste time and space packaging static libs. (It's bad enough that common code is duplicated four times between mujstest, mupdf, muraster, and mutool.)

misc commented on 2016-10-06 17:32 (UTC)

Seems the entire libmupdf stuff now must be packaged separately, as community does: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/mupdf

vesath commented on 2016-07-09 17:17 (UTC)

For a while the ever-increasing size of this package has been a real annoyance to me. It's a direct consequence of upstream's static-linking policy: common code and fonts are embedded into each individual binary. Ideally they would be built into a shared library which individual binaries would link against. However that's not trivial to achieve in our modest PKGBUILD. So in the meantime I tried to keep the package size under control with two slightly controversial tweaks: - static libraries are no longer provided - CJK fonts are no longer embedded I believe this keeps this package fit for nearly everyone's purpose and it brings its size down from 176 MB to 44 MB. Feel free to voice any concerns you might have, together with suggestions on alternative ways to keep this package manageable. Cheers.

tutu commented on 2016-01-10 17:16 (UTC)

vesath: Thanks for the info about how to deal with libs. It is very nice to be able to talk to someone that have more experience on the topic. I will study a bit about how to construct a package in AUR and perhaps create a mujs package :-).

vesath commented on 2016-01-10 07:02 (UTC)

tutu: If your own project is unrelated to mupdf, there is really no reason for you to depend on the specific versions of mujs (or any other library) that mupdf requires and bundles into its libmupdfthird.a; you should simply use upstream mujs. Last time I checked, mupdf could not be built against our shared openjpeg system libraries that our openjpeg package provides, indeed because it relies on yet unreleased openjpeg features. Of course I will compile against system libs whenever possible: the Arch way teaches us to avoid compiling libraries statically. Regarding zlib, it is not explicitely included in the packages dependencies because it is already indirectly included as a dependency of pretty much everything: freetype2 depends on it, jbig2dec depends on libpng which depends on it, etc.

tutu commented on 2016-01-10 00:41 (UTC) (edited on 2016-01-10 00:42 (UTC) by tutu)

Hello again vesath - Thanks for the explanation, it was really helpful. I noticed that you listed freetype2, jbig2dec, libjpeg and libxext as dependencies. Aren't zlib and the dependencies currently in mupdf Arch package supposed to be added as well? Some of those libraries are listed in the README file from mupdf and are not present in the PKGBUILD. Here is a quick summary of mupdf README and the dependencies: - dependencies: freetype2, jbig2dec, libjpeg, openjpeg, zlib - optional: # Command line tools (HAVE_X11=yes/no): xorg-dev # OpenGL-based viewer (HAVE_GLFW=yes/no): mesa-common-dev, libgl1-mesa-dev, xorg-dev, libxcursor-dev, libxrandr-dev, libxinerama-dev. The reason why I needed libmujs.a has actually been solved. The developers of mupdf are basically creating a static library called libmupdfthird.a with the third-party libs (mujs, openjpeg, etc). Since you are initializing the mujs git submodule, the routines I need are static linked to libmupdfthird.a. The same thing happen to openjpeg. Since Arch does have a package to openjpeg2 I tried to remove the line that active the submodule for openjpeg, however I had some compilation issues (some function were missing arguments - I think mupdf uses the most up to date version). I wonder if we could skip the initialization of openjpeg git submodule when a new stable release of openjpeg2 is available in the Arch package repository. What do you think? Thanks again.

vesath commented on 2016-01-09 08:18 (UTC)

tutu: Yes! Like openjpeg and jbig2dec, mujs is a separate project and should be packaged separately. It probably is a dependency of nothing but mupdf, still it was wrong of me to ship its libraries (static or otherwise) with mupdf. Concerning Arch's policy, there is a consensus to avoid static libs whenever possible, though they are tolerated when there is no dynamic counterpart. Nothing more. Of course a mujs or mujs-git package in the AUR would be a very welcome addition.

tutu commented on 2016-01-09 05:58 (UTC)

Hi vesath - Thanks for the reply, I really appreciate your comment. I'm current using llpp-git package and the current maintainer (drrossum) suggested (https://aur.archlinux.org/packages/llpp-git/?comments=all) to switch the required dependency from mupdf to mupdf-git. llpp uses most up to date mupdf libs and other third party libs, such as, mujs. Do you think it would be wise in creating a package in AUR for mujs to address this issue? The have mujs source here http://git.ghostscript.com/mujs.git, so, perhaps one could create a mujs-git? Or this is not recommend by Arch community? Thanks for the advice about `make install-nacl-libs`. I will do some research and see if solves my problem. Thanks again.

vesath commented on 2016-01-08 08:30 (UTC)

It appears upstream does not build third-party static libraries by default anymore. Those who want it can do `make install-nacl-libs` but I have no interest in doing that for this package: Arch has repeatedly discouraged the use of static libraries.

tutu commented on 2016-01-07 05:57 (UTC)

Hi there - I'm having issues in building the PKGBUILD. install: cannot stat ‘build/release/libmujs.a’: No such file or directory ==> ERROR: A failure occurred in package(). Aborting... Apparently libmujs.a is not being created anymore. Did the name of it changed or PKGBUILD is not build mupdf correctly?

vesath commented on 2014-07-27 22:10 (UTC)

Oh, well, okay. I forgot that mupdf does not ship dynamic libraries... My mistake. Should be fixed now. Thanks for the report.

misc commented on 2014-07-27 21:54 (UTC)

zathura-pdf-mupdf won't compile now since you removed "options=('staticlibs')" and the "install -Dm644 build/release/libmujs.a "$pkgdir"/usr/lib" line.

vesath commented on 2014-07-25 01:09 (UTC)

I've just adopted this package, added the freetype2 dependency, and made the pkgver monotonic. Feedback is welcome.

haawda commented on 2014-07-24 21:07 (UTC)

Sure, but I orphan this. The community package is recent enough for my needs.

misc commented on 2014-07-23 16:24 (UTC)

Could you please change the provides line so it includes the version? Some other pkgbuilds check for it, like zathura-pdf-mupdf[-git].

haawda commented on 2014-06-27 08:32 (UTC)

Done, thanks.

misc commented on 2014-06-26 17:53 (UTC)

Could use realignment with the community PKGBUILD, in particular the libmujs.a line: https://projects.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/mupdf

haawda commented on 2013-10-24 15:23 (UTC)

Sure, thanks for the hint.

mlq commented on 2013-10-24 08:21 (UTC)

It would be great if you could add the '-fPIC' flag to build it (like in the stable package) so that zathura-pdf-mupdf can be build against it.

haawda commented on 2013-10-17 13:26 (UTC)

added desktop file

haawda commented on 2013-08-14 18:51 (UTC)

Adopted and updated. I like "git describe --tags". Also had to add the curl subrepo, unfortunately.

commented on 2013-06-20 18:19 (UTC)

Ok, builds again after a tiny change in the package function.

xmw commented on 2013-06-20 08:19 (UTC)

bisson@archlinux.org filed this upstream bug report with a working patch. http://bugs.ghostscript.com/show_bug.cgi?id=694365&list_id=6717

xmw commented on 2013-06-20 07:16 (UTC)

The include files have been split and the directory structure changed. http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=19126babc37ac8243de60b3ca388bb5102661274 http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=923ab857eed6cd29b539910bf74be2aa26d71f39 http://git.ghostscript.com/?p=mupdf.git;a=commitdiff;h=595e10ebe3150402a6b3e84500ed50ad2ebf1c3e

commented on 2013-06-19 13:16 (UTC)

I get different errors trying to build commit 3323. Looks like it's messed up upstream right now. 3307 still worked, it's what I have installed right now.

doctorcolossus commented on 2013-06-19 11:20 (UTC)

Guys, the latest build seems to compile and link fine for me, but when attempting installation I get the errors below (transcribed by hand, hence typos possible). I've tried with both the yaourt and packer package helpers and have tried building both in my /tmp RAM disk and in a temporary directory in my home folder. Am I the only one getting this? If not, is it a problem with our PKGBUILD or is this an upstream issue? Any tips for troubleshooting? Thanks in advance. install -d /tmp/packerbuild-0/mupdf-git/mupdf-git/pkg/mupdf-git/usr/bin /tmp/packerbuild-0/mupdf-git/mupdf-git/pkg/mupdf-git/usr/lib /tmp/packerbuild-0/mupdf-git/mupdf-git/pkg/mupdf-git/usr/include /tmp/packerbuild-0/mupdf-git/mupdf-git/pkg/mupdf-git/usr/share/man/man1 install build/release/libmupdf.a /tmp/packerbuild-0/mupdf-git/mupdf-git/pkg/mupdf-git/usr/lib install fitz/memento.h fitz/fitz.h pdf/mupdf.h xps/muxps.h cbz/mucbz.h image/muimage.h /tmp/packerbuild-0/mupdf-git/mupdf-git/pkg/mupdf-git/usr/include install: cannot stat 'fitz/memento.h': No such file or directory install: cannot stat 'fitz/fitz.h': No such file or directory install: cannot stat 'pdf/mupdf.h': No such file or directory install: cannot stat 'xps/muxps.h': No such file or directory install: cannot stat 'cbz/mcucbz.h': No such file or directory install: cannot stat 'image/muimage.h': No such file or directory make: *** [install] Error 1 ==> ERROR: A failure occurred in package(). Aborting... The build failed.

commented on 2013-06-16 10:34 (UTC)

Added openssl to the dependencies, according to namcap mupdf now depends on it.

commented on 2013-05-27 17:15 (UTC)

Awesome, thanks for the info!

vesath commented on 2013-05-27 16:44 (UTC)

Army: You only need to embed openjpeg (not all thirdparty libraries) since mupdf switched to the openjp2 interface. See: http://arch.vesath.org/all/mupdf-git-20130527.22cde5d-1.src.tar.gz

commented on 2013-05-27 12:45 (UTC)

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.

commented on 2013-04-08 09:57 (UTC)

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 (UTC)

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

commented on 2013-04-05 22:34 (UTC)

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

commented on 2012-04-16 19:07 (UTC)

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

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.

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.

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.

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!!! ;)

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.

commented on 2012-01-28 11:07 (UTC)

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

commented on 2012-01-28 09:55 (UTC)

@Army - Upstream changes are causing this not to build anymore. These lines are not needed in the PKGBUILD anymore (and cause an error) as apparently the devs have changed the names for them. Delete them and this builds fine again. # avoiding conflicts with poppler cd "${pkgdir}/usr/bin" for i in pdf*;do mv "$i" "$i-mupdf";done Previously you needed to change these to: pdfclean-mupdf pdfdraw-mupdf pdfextract-mupdf pdfinfo-mupdf pdfshow-mupdf but the new unaltered names show up as this: mupdf mupdfclean mupdfdraw mupdfextract mupdfinfo mupdfshow muxpsdraw Thanks!!

commented on 2011-04-21 22:26 (UTC)

And sorry for my late reply, I somehow didn't get the mails, a config problem from my part.

commented on 2011-04-21 22:24 (UTC)

Thanks guys, I'll upload the new package in a minute.

haawda commented on 2011-04-11 13:04 (UTC)

There is no make step in the build function. I needed one: make build=release prefix="/usr" The chmod now has to be applied to all the libs. chmod -x $pkgdir/usr/lib/*

haawda commented on 2011-04-11 10:24 (UTC)

The -darcs-package was removed.

essenceoffoo commented on 2011-04-01 13:01 (UTC)

mupdf has officially switched to git. The new source is git clone git://git.ghostscript.com/mupdf.git I exchanged the URL in the PKGBUILD. Everything works fine.

commented on 2011-03-07 21:50 (UTC)

For all those people who don't want to install darcs just because of mupdf-darcs or who prefer git over darcs (which I do!)

Arch Linux User Repository