Re: [Buildroot] [PATCH 2/2] package/mupdf, python-pymupdf: bump to versions 1.28.5 and 1.28.2

[Waldemar Brodkorb <wbx@openadk.org>]

Hi,
Raphaël Mélotte via buildroot wrote,

> Release notes:
> https://mupdf.com/releases
> https://pymupdf.readthedocs.io/en/latest/changes.html
> 
> Note that this bump fixes multiple security vulnerabilities, and at
> least the following ones:
> - CVE-2025-46206
> - CVE-2025-71382
> - CVE-2026-7233
> - CVE-2026-40505
> 
> With this new python-pymupdf (and mupdf) version, we can no longer
> build the old implementation (the 'a' implementation).  We now need to
> build mupdf's python binding, which require host-clang (and its python
> bindings) to be built.
> 
> Also note that python-mupdf's version still needs to stay close to
> mupdf's version, they can only be updated together.
> 
> A number of mupdf patches were needed:
> - To allow changing the build-time log level from an environment
> variable.
> - To be able to provide the libclang include directories. This is
> needed because our default libclang include directories are not
> properly set.
> - To be able to link against mupdf with no versioning number.
> - To fix build errors when generating the python bindings for
> python-pymupdf with clang 22.
> - To fix build errors with uClibc.
> - To make it possible to build without a venv.
> 
> python-pymupdf also needed a (backported) patch to fix building with
> swig 4.5+.
> 
> In mupdf, setting JLIB_log_levels is not strictly necessary, but it
> greatly helps debugging build issues. It also only has an impact at
> build time anyway. To make it easier to debug potential future CI
> build failures, we enable it unconditionally.
> brotli is also added as a new optional dependency, supported since
> mupdf v1.26.0.
> Starting from version 1.28.1 pipcl is no longer bundled and needs to
> be installed separately, so add host-python-pipcl when we build the
> python bindings.
> Starting from version 1.28.2, mupdf added the unconditional use of a
> venv, so disable it with MUPDF_NO_AUTOVENV.
> 
> In python-pymupdf, !BR2_STATIC_LIBS is now required by mupdf anyway,
> so update the comment accordingly.
> pipcl (required to build python-pymupdf) used to be bundled in
> python-pymupdf but is now available as a separate package, so use
> it. This also allows us to use 'pep517' as the setup type.
> The test is also updated to use the new implementation.
> 
> For both packages, the patches that are now upstream are also removed.
> 
> The tarball filename for python-pymupdf has changed upstream so it is
> also updated accordingly.
> 
> These new versions no longer fit in the 120M rootfs configured for the
> runtime test, so double its size.

Thanks for your patch. I was once trying to do an update myself and
failed to get python-pymupdf to compile. They changed so much in
their new version. Great work!

You can add my 
Tested-By: Waldemar Brodkorb <wbx@openadk.org>

Tested mupdf-x11 in fluxbox with qemu-system-x86_64 and glibc
toolchain.
 
> The mupdf builds are quite finicky on at least swig and libclang
> versions, so applying these changes on the Buildroot LTS branches
> should only be done with careful consideration (and making sure that
> it builds and passes the runtime test).

I tried the update for 2025.02, but get:

./scripts/mupdfwrap.py  -d build/shared-release -b 01
(+0.0s): jlib.py:371:log_levels_add: adding level: filename_prefix='/' function_prefix=''
(+0.0s): parse.py:16:<module>: Warning, could not import clang: No module named 'clang'
(+0.0s): state.py:21:<module>: Warning: failed to import clang.cindex: e=ModuleNotFoundError("No module named 'clang'")
(+0.0s): state.py:21:<module>: We need Clang Python to build MuPDF python.
(+0.0s): state.py:21:<module>: Install with `pip install libclang` (typically inside a Python venv),

So adding it to LTS will be challenging again I think.

best regards
 Waldemar
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot