Package Details: mupdf-git 20231101.dc7489fd9-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.000015
First Submitted: 2011-03-07 21:49 (UTC)
Last Updated: 2023-11-11 01:32 (UTC)

Required by (17)

Sources (5)

Latest Comments

1 2 3 4 5 6 Next › Last »

vesath commented on 2023-02-11 21:08 (UTC)

Yes, my fix is now obsolete, so you can just remove the patch line. Here's an updated version. Cheers.

Xwang commented on 2023-02-11 12:56 (UTC)

source/fitz/output-jpeg.c:38:13: error: redefinition of ‘fz_jpg_mem_init’ 38 | static void fz_jpg_mem_init(j_common_ptr cinfo, fz_context ctx) | ^~~~~~~~~~~~~~~ source/fitz/output-jpeg.c:31:13: note: previous definition of ‘fz_jpg_mem_init’ with type ‘void(struct jpeg_common_struct , fz_context )’ 31 | static void fz_jpg_mem_init(j_common_ptr cinfo, fz_context ctx) | ^~~~~~~~~~~~~~~ source/fitz/output-jpeg.c:31:13: warning: ‘fz_jpg_mem_init’ defined but not used [-Wunused-function] make[1]: [Makefile:126: build/release/source/fitz/output-jpeg.o] Error 1 make[1]: uscita dalla directory «/home/andreak/tmp/trizen-andreak/mupdf-git/src/mupdf» make: [Makefile:513: release] Error 2 ==> ERRORE: Si è verificato un errore in build(). L'operazione sta per essere interrotta... :: Unable to build mupdf-git - makepkg exited with code: 4

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.

1 2 3 4 5 6 Next › Last »