Arch Linux User Repository

I just updated to package to the best of my abilities, still it is very buggy and only some functionality works. In my tests this is also the case with the debian package. If anyone is able to fix it please let me know. For the moment the only solution to get full functionality is to download the pre-built binary from willus.

PS: kudos to the debian developer for fixing the build with mupdf, currently it works on my end. Only tesseract support remains disabled.

Thanks @gilcu3 and @spider-mario for the replies. I've learned not to try a full system update when I'm already deep in a different rabbit hole. Updated today, started over:

[loren@Gazp9 k2pdfopt]$ makepkg ==> Making package: k2pdfopt 2.55-4 (Sun 14 Sep 2025 01:23:23 PM PDT) ==> Checking runtime dependencies... ==> Missing dependencies: -> libmupdf ==> Checking buildtime dependencies... ==> ERROR: Could not resolve all dependencies. [loren@Gazp9 k2pdfopt]$

I had to manually do pacman -Ss libmupdf and then it worked.

pacman -Syu is indeed the way to solve the issue.

What happened:

1. at some point in the past, when your pacman mirror had libmupdf 1.26.4, you ran pacman -Sy(u), so from then on, that was the version your local database knew about.
2. The mirror updated libmupdf to 1.26.5, updated their database file accordingly, and removed the old version.
3. Your pacman, when trying to install libmupdf, still thinks 1.26.4 is what your mirror has, since that’s what your local database references.

pacman -Sy is theoretically enough to refresh your local database so that it knows that 1.26.5 is the version to get, but doing -Sy without -u is dangerous and can break your system because you might end up mixing package versions that were not meant to be mixed: https://wiki.archlinux.org/title/System_maintenance#Partial_upgrades_are_unsupported

@LorenAmelang this package does not depend on fixed versions of other packages, nor libmupdf or gumbo-parser. Therefore, you must have an issue with your package manager. Something like pacman -Syu (full system upgrade) might solve the issue. It could also be that the mirror you are using is outdated, try changing the mirror.

I'm seeing error: failed retrieving file 'libmupdf-1.26.4-1-x86_64.pkg.tar.zst' from mirror.givebytes.net : The requested URL returned error: 404 error: failed retrieving file 'gumbo-parser-0.13.1-1-x86_64.pkg.tar.zst' from mirror.givebytes.net : The requested URL returned error: 404 from every mirror.

Looks like MuPDF 1.26.5 (2025-08-12) Gumbo 0.13.2 (2025-08-26) are current.

Is there something I could fix?

Hi. I'm seeing the following build errors as of today;

==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
CMake Warning (dev) at CMakeLists.txt:1 (project):
  cmake_minimum_required() should be called prior to this top-level project()
  call.  Please see the cmake-commands(7) manual for usage documentation of
  both commands.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- The C compiler identification is GNU 15.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at CMakeLists.txt:2 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.


-- Configuring incomplete, errors occurred!
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: k2pdfopt-exit status 4

@frankspace you are right, I was not looking at the correct version of the package. I think mujs should actually be a dependency, I will fix ASAP

@gilcu3 I'm running Artix, which definitely has some weird quirks, but I'm pretty sure it's not an Artix thing here because that flag is actually found in the "mupdf.pc" file in the "Libs.private" line.

@frankspace I tried finding where does that flag is set in the source, and could not find any reference. Can you provide more details on where does it appear and what is your environment?

Compilation in a clean chroot fails for me unless mujs is installed, I'd get the following:

[100%] Linking C executable k2pdfopt
/usr/bin/ld: cannot find -lmujs: No such file or directory
collect2: error: ld returned 1 exit status

The compiled binary doesn't seem to link to anything in the mujs package, so I presume it's a makedep rather than a dependency. Still, I couldn't compile without it.

@gilcu3 apologies for the noise then, I'm using manjaro and somehow this never happened.