dev-python/mupdf
Python bindings for the MuPDF library
-
mupdf-1.28.6~amd64 ~arm64test python_targets_python3_12 python_targets_python3_13 python_targets_python3_14 debug +llvm_slot_22 llvm_slot_18 llvm_slot_19 llvm_slot_20 llvm_slot_21 llvm_slot_23
View
Download
Browse License: AGPL-3 Overlay: stuff -
mupdf-1.28.5~amd64 ~arm64test python_targets_python3_12 python_targets_python3_13 python_targets_python3_14 debug +llvm_slot_22 llvm_slot_18 llvm_slot_19 llvm_slot_20 llvm_slot_21 llvm_slot_23
View
Download
Browse License: AGPL-3 Overlay: stuff -
mupdf-1.28.4~amd64 ~arm64test python_targets_python3_12 python_targets_python3_13 python_targets_python3_14 debug +llvm_slot_22 llvm_slot_18 llvm_slot_19 llvm_slot_20 llvm_slot_21 llvm_slot_23
View
Download
Browse License: AGPL-3 Overlay: stuff
ChangeLog
commit 3b668c2082d88d238ad41eb046740673ea8b0139
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Oct 29 08:10:25 2026 +0100
dev-python/mupdf: add 1.28.6
commit fa378a4700466b0dd72ca4f657c0a6ef63fa4729
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Oct 8 09:57:18 2026 +0200
dev-python/mupdf: add LLVM 23 to LLVM_COMPAT
mupdfwrap loads the selected slot's libclang through the unslotted
dev-python/clang bindings, which are at 23 on the ~amd64 and ~arm64
keywords this package carries. Bindings newer than the libclang they
load can fail on missing symbols, as clang 22's did against slot 20, so
the slot range has to reach the bindings' major. The libclang 22 AST
patch covers 23 as well.
commit 5e08f48aa486f18b5b6e45bd3df86309e636e2cf
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Oct 4 13:12:22 2026 +0200
dev-python/mupdf: add missing || die
The devmanual asks for || die after every command that can fail; these
cd, mv, cp, mkdir and rm calls could fail silently. No installed files
change, so no revision bump.
commit 5d5dec9e44f7c3e73b74569d0f9f7d84af00f53b
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Oct 3 20:31:11 2026 +0200
dev-python/pymupdf: rename from dev-python/PyMuPDF
Gentoo's Python guide asks for dev-python packages to carry their PyPI
name, normalised per PEP 503. MY_P keeps upstream's casing for the
GitHub archive and its directory, so the distfiles are unchanged.
profiles/updates moves installed copies, and amd-gaia, unsloth,
pymupdf4llm, pymupdf-layout-bin and mupdf's metadata use the new name.
commit e3cabb5067377b2201f82951130a955b2430ecd4
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Sep 26 18:42:09 2026 +0200
dev-python/mupdf: drop 1.27.2, 1.28.0, 1.28.2
Each version pins the matching app-text/mupdf exactly. 1.28.0 lost
that partner when app-text/mupdf dropped it, and retention keeps the
same last three releases as the library, 1.28.3 to 1.28.5.
pymupdf-layout-bin pins 1.28.3, which stays.
commit 291ec62e69306e707da0bfa9b71242444edf3c8a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Sep 26 13:16:06 2026 +0200
dev-python/mupdf: add 1.28.5
Follows app-text/mupdf 1.28.5, which it pins exactly. python.diff and
the clang has_refs patch still apply, and the autovenv bootstrap line
the ebuild removes is still present.
commit e49d28fdab2dceaf05e64b4112ddb16c9d8e88cf
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 16 13:42:58 2026 +0200
dev-python/mupdf: add 1.28.4
Both patches still apply and the build interface is unchanged.
commit 5860915dd6f62f550856d0889915b2f3d027e3d3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 07:11:44 2026 +0200
dev-python/mupdf: trim 1.28.0 build rationale
commit 8ae6796e43604ba10316d81a7887a3201da38df7
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 07:11:44 2026 +0200
dev-python/mupdf: trim 1.27.2 build rationale
commit f3e76434d89964daa3fb8474e18a2891caa99598
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 05:23:18 2026 +0200
dev-python/mupdf: trim 1.28.3 comment prose
commit d42935767b8e7d6782cd604455bc1a5f1393f29c
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 05:23:18 2026 +0200
dev-python/mupdf: trim 1.28.2 comment prose
commit f574b28658c248469fbaf99f3ca2440e48ce3dd3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Aug 29 13:08:30 2026 +0200
dev-python/mupdf: add 1.28.3
Second half of the mupdf chain; its ~app-text/mupdf-$ pin means this
version is unusable until the matching app-text/mupdf lands, which it did in
the preceding commit.
Both patches (python.diff, mupdf-clang22-has_refs) apply unchanged -- neither
is version-named, unlike app-text/mupdf's, so nothing needed renaming here.
Build-checked against the 1.28.3 C library.
PyMuPDF deliberately stays at 1.28.2 -- still the newest release on PyPI --
and accepts the newer C library because its system-library path has no
version gate; see the app-text/mupdf commit for the detail and for the merge
+ runtime round-trip that proves it (create -> insert_text -> tobytes ->
reparse -> get_text, %PDF-1.7 out, text identical in).
The three packages only have to move together across a MINOR bump, where
PyMuPDF's pre-generated SWIG bindings target a specific MuPDF API; a patch
bump within 1.28 is not that case.
commit b7989b7994552db10718ffd7687d29bbc431d24b
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 7 10:51:11 2026 +0200
dev-python/mupdf: add 1.28.2
1.28.2 adds an autovenv.enter() bootstrap to scripts/wrap/__main__.py
that re-execs the C++/SWIG build inside a fresh venv without system
site-packages, hiding pipcl and firing a network `pip install --upgrade
pipcl` the build sandbox rejects. Drop the call in src_prepare so the
build stays in the system Python, and declare dev-python/pipcl in
BDEPEND (a genuine new build-time requirement in 1.28.2).
commit eabead9f00317168a6710c15d14f39f5cba4bebd
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Tue Jul 7 16:44:06 2026 +0200
dev-python/mupdf: fix binding generation with libclang 22
mupdfwrap.py assumed Cursor/Type.get_declaration() returns completed definitions and that a struct or union FIELD_DECL exposes its members as children. libclang 22 instead returns forward declarations and inline type declarations, so parse.has_refs() and parse.get_members() abort during binding generation: the fz_pixmap .refs member is not found, get_members() reports "No fields found", and the fz_stext iterator path hits a NoneType via find_name().
mupdf-clang22-has_refs.patch resolves a forward-declaration cursor to its definition via Cursor.get_definition(), and descends a struct or union FIELD_DECL to its record declaration before enumerating members. Both are no-ops on older libclang. LLVM_COMPAT is extended to 22 so the bindings build against the libclang matching dev-python/clang.
commit 534bb437d880f1ae8fe81f2cd483cfcd5d9d9d59
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Jun 29 16:07:19 2026 +0200
dev-python/mupdf: add 1.28.0
commit 1b3149d19abfec9bd639b1167455cdf0549c98a1
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Jun 17 18:19:09 2026 +0200
dev-python/mupdf: Keyword 1.27.2 for ~arm64
Official MuPDF SWIG/libclang Python bindings. Builds against the
installed LLVM 20 slot (LLVM_COMPAT 18..21); the binding generator and
the link against app-text/mupdf's libmupdf both work natively on
aarch64. C/C++ (SWIG); aarch64-portable.
commit 56f6e194107e378e70e4d2b7c7cf561a77ed03f0
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat May 9 14:54:36 2026 +0200
dev-python/mupdf: new package, fork from ::4nykey
Python bindings for the MuPDF library: C++ shim + SWIG-generated Python
module. Forked at 1.27.2 to match app-text/mupdf in tree (slot-pinned
~app-text/mupdf-$).
Build is non-trivial: scripts/mupdfwrap.py uses libclang
(dev-python/clang BDEPEND, currently version 23) to parse mupdf
headers and generate C++ shim sources, then SWIG generates the Python
binding from those headers. python.diff (forked from 4nykey) keeps
libmupdf.so itself out of the build (we link against system
app-text/mupdf C lib instead) and fixes link-flags ordering.
LLVM_COMPAT= matches 4nykey. Gentoo tree provides
llvm-core/clang slots 19-23; build picks slot 21 from the
LLVM_COMPAT ∩ tree-keyworded intersection. Bump LLVM_COMPAT upper
bound in a follow-up if a newer clang gets exercised.
Verified end-to-end: import mupdf, FZ_VERSION = 1.27.2 (matches PV);
libmupdfcpp.so.1.27.2 + _mupdf.so installed; SWIG class surface
accessible.
Stepping stone toward forking dev-python/PyMuPDF.
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Oct 29 08:10:25 2026 +0100
dev-python/mupdf: add 1.28.6
commit fa378a4700466b0dd72ca4f657c0a6ef63fa4729
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Oct 8 09:57:18 2026 +0200
dev-python/mupdf: add LLVM 23 to LLVM_COMPAT
mupdfwrap loads the selected slot's libclang through the unslotted
dev-python/clang bindings, which are at 23 on the ~amd64 and ~arm64
keywords this package carries. Bindings newer than the libclang they
load can fail on missing symbols, as clang 22's did against slot 20, so
the slot range has to reach the bindings' major. The libclang 22 AST
patch covers 23 as well.
commit 5e08f48aa486f18b5b6e45bd3df86309e636e2cf
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Oct 4 13:12:22 2026 +0200
dev-python/mupdf: add missing || die
The devmanual asks for || die after every command that can fail; these
cd, mv, cp, mkdir and rm calls could fail silently. No installed files
change, so no revision bump.
commit 5d5dec9e44f7c3e73b74569d0f9f7d84af00f53b
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Oct 3 20:31:11 2026 +0200
dev-python/pymupdf: rename from dev-python/PyMuPDF
Gentoo's Python guide asks for dev-python packages to carry their PyPI
name, normalised per PEP 503. MY_P keeps upstream's casing for the
GitHub archive and its directory, so the distfiles are unchanged.
profiles/updates moves installed copies, and amd-gaia, unsloth,
pymupdf4llm, pymupdf-layout-bin and mupdf's metadata use the new name.
commit e3cabb5067377b2201f82951130a955b2430ecd4
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Sep 26 18:42:09 2026 +0200
dev-python/mupdf: drop 1.27.2, 1.28.0, 1.28.2
Each version pins the matching app-text/mupdf exactly. 1.28.0 lost
that partner when app-text/mupdf dropped it, and retention keeps the
same last three releases as the library, 1.28.3 to 1.28.5.
pymupdf-layout-bin pins 1.28.3, which stays.
commit 291ec62e69306e707da0bfa9b71242444edf3c8a
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Sep 26 13:16:06 2026 +0200
dev-python/mupdf: add 1.28.5
Follows app-text/mupdf 1.28.5, which it pins exactly. python.diff and
the clang has_refs patch still apply, and the autovenv bootstrap line
the ebuild removes is still present.
commit e49d28fdab2dceaf05e64b4112ddb16c9d8e88cf
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 16 13:42:58 2026 +0200
dev-python/mupdf: add 1.28.4
Both patches still apply and the build interface is unchanged.
commit 5860915dd6f62f550856d0889915b2f3d027e3d3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 07:11:44 2026 +0200
dev-python/mupdf: trim 1.28.0 build rationale
commit 8ae6796e43604ba10316d81a7887a3201da38df7
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 07:11:44 2026 +0200
dev-python/mupdf: trim 1.27.2 build rationale
commit f3e76434d89964daa3fb8474e18a2891caa99598
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 05:23:18 2026 +0200
dev-python/mupdf: trim 1.28.3 comment prose
commit d42935767b8e7d6782cd604455bc1a5f1393f29c
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 05:23:18 2026 +0200
dev-python/mupdf: trim 1.28.2 comment prose
commit f574b28658c248469fbaf99f3ca2440e48ce3dd3
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat Aug 29 13:08:30 2026 +0200
dev-python/mupdf: add 1.28.3
Second half of the mupdf chain; its ~app-text/mupdf-$ pin means this
version is unusable until the matching app-text/mupdf lands, which it did in
the preceding commit.
Both patches (python.diff, mupdf-clang22-has_refs) apply unchanged -- neither
is version-named, unlike app-text/mupdf's, so nothing needed renaming here.
Build-checked against the 1.28.3 C library.
PyMuPDF deliberately stays at 1.28.2 -- still the newest release on PyPI --
and accepts the newer C library because its system-library path has no
version gate; see the app-text/mupdf commit for the detail and for the merge
+ runtime round-trip that proves it (create -> insert_text -> tobytes ->
reparse -> get_text, %PDF-1.7 out, text identical in).
The three packages only have to move together across a MINOR bump, where
PyMuPDF's pre-generated SWIG bindings target a specific MuPDF API; a patch
bump within 1.28 is not that case.
commit b7989b7994552db10718ffd7687d29bbc431d24b
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri Aug 7 10:51:11 2026 +0200
dev-python/mupdf: add 1.28.2
1.28.2 adds an autovenv.enter() bootstrap to scripts/wrap/__main__.py
that re-execs the C++/SWIG build inside a fresh venv without system
site-packages, hiding pipcl and firing a network `pip install --upgrade
pipcl` the build sandbox rejects. Drop the call in src_prepare so the
build stays in the system Python, and declare dev-python/pipcl in
BDEPEND (a genuine new build-time requirement in 1.28.2).
commit eabead9f00317168a6710c15d14f39f5cba4bebd
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Tue Jul 7 16:44:06 2026 +0200
dev-python/mupdf: fix binding generation with libclang 22
mupdfwrap.py assumed Cursor/Type.get_declaration() returns completed definitions and that a struct or union FIELD_DECL exposes its members as children. libclang 22 instead returns forward declarations and inline type declarations, so parse.has_refs() and parse.get_members() abort during binding generation: the fz_pixmap .refs member is not found, get_members() reports "No fields found", and the fz_stext iterator path hits a NoneType via find_name().
mupdf-clang22-has_refs.patch resolves a forward-declaration cursor to its definition via Cursor.get_definition(), and descends a struct or union FIELD_DECL to its record declaration before enumerating members. Both are no-ops on older libclang. LLVM_COMPAT is extended to 22 so the bindings build against the libclang matching dev-python/clang.
commit 534bb437d880f1ae8fe81f2cd483cfcd5d9d9d59
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Jun 29 16:07:19 2026 +0200
dev-python/mupdf: add 1.28.0
commit 1b3149d19abfec9bd639b1167455cdf0549c98a1
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Jun 17 18:19:09 2026 +0200
dev-python/mupdf: Keyword 1.27.2 for ~arm64
Official MuPDF SWIG/libclang Python bindings. Builds against the
installed LLVM 20 slot (LLVM_COMPAT 18..21); the binding generator and
the link against app-text/mupdf's libmupdf both work natively on
aarch64. C/C++ (SWIG); aarch64-portable.
commit 56f6e194107e378e70e4d2b7c7cf561a77ed03f0
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat May 9 14:54:36 2026 +0200
dev-python/mupdf: new package, fork from ::4nykey
Python bindings for the MuPDF library: C++ shim + SWIG-generated Python
module. Forked at 1.27.2 to match app-text/mupdf in tree (slot-pinned
~app-text/mupdf-$).
Build is non-trivial: scripts/mupdfwrap.py uses libclang
(dev-python/clang BDEPEND, currently version 23) to parse mupdf
headers and generate C++ shim sources, then SWIG generates the Python
binding from those headers. python.diff (forked from 4nykey) keeps
libmupdf.so itself out of the build (we link against system
app-text/mupdf C lib instead) and fixes link-flags ordering.
LLVM_COMPAT= matches 4nykey. Gentoo tree provides
llvm-core/clang slots 19-23; build picks slot 21 from the
LLVM_COMPAT ∩ tree-keyworded intersection. Bump LLVM_COMPAT upper
bound in a follow-up if a newer clang gets exercised.
Verified end-to-end: import mupdf, FZ_VERSION = 1.27.2 (matches PV);
libmupdfcpp.so.1.27.2 + _mupdf.so installed; SWIG class surface
accessible.
Stepping stone toward forking dev-python/PyMuPDF.

