python-pyqt5-datavisualization
Build times (auto-updated)
- x86_64: 2m28s (2026-09-24 10:09 UTC, MAKEFLAGS=-j6)
- Path: arch/maintained/python-pyqt5-datavisualization
- Build failure during the 2026-07-07 “build all packages for x86_64”
private-repo release pass. Needs
qt5-datavis3d, not in thisarch/tree (external-dependency class, seememory/dbmodel-qt4.md). Not fixed as part of this pass. - 2026-08-02: fixed. Vendored
qt5-datavis3dfrom AUR (seememory/qt5-datavis3d.md). Built+published cleanly (5.15.6-5, + python-pyqt5-datavisualization-debug), x86_64.
2026-09-21: SPDX license fix applied, but build currently broken (unrelated)
Fixed license=(GPL3) -> license=('GPL-3.0-only') (no open AUR
comment about this specifically – PyQt is GPLv3-only per Riverbank’s
licensing, not “or later”; fixed proactively while auditing SPDX
issues). pkgrel 5 -> 6.
Discovered a separate, pre-existing, unrelated build failure while
testing: sip-build: ABI v12 is being targeted but the
PyQt5.QtDataVisualization module doesn't support it. Currently
installed sip 6.16.1 / pyqt-builder 1.19.1 default to a newer ABI
than this old 5.15.6 binding supports. Not caused by the license
edit (pure metadata, no functional change) – build failed identically
before and after. Not fixed as part of this pass; would need either
pinning sip/pyqt-builder to older versions (messy, affects other
python-pyqt5-* siblings sharing the same makedepends) or forcing an
older ABI via sip-build --abi-version in build(). Left
pkgrel=6/the license fix in place (harmless, correct either way);
nothing published this session – still needs the ABI fix before it
builds again.
2026-09-24: AUR comment confirms the same ABI v12 issue
jghodd commented on AUR (2026-09-21 21:13) hitting the exact same
sip-build: ABI v12 failure independently. No new information – same
root cause as above, still needs the sip/pyqt-builder pin or
--abi-version decision. No reply posted.
2026-09-24 (2): root-caused and fixed – pkgrel 6 -> 7
Traced the real cause instead of guessing at --abi-version/pinning
sip: patched a local copy of sipbuild’s parser
(generator/parser/parser_manager.py, _finalise_abi_version) with a
debug print (via PYTHONPATH override so the actual installed
/usr/lib/python3.14/site-packages/sipbuild was never touched – never
modify host-installed software to debug/fix a build) and reran
sip-build directly against
the extracted source. Confirmed: spec.minimum_abi_versions was an
empty list, and the target major (12) correctly matched the
installed PyQt5’s own ABI (QtGui.toml says sip-abi-version =
"12.15") – so this was never actually an ABI mismatch between our
toolchain and PyQt5. minimum_abi_versions is populated only by an
explicit %MinimumABIVersion "X.Y" directive inside the binding
module’s own top-level .sip file (sipbuild/generator/parser/rules.py,
p_minimum_abi_version) – it is not derived automatically from
%Import resolution. PyQtDataVisualization-5.15.6’s
sip/QtDataVisualization/QtDataVisualizationmod.sip simply never
gained that directive – Riverbank’s last release (2022-era) predates
when sip-build started enforcing it. So every build with any
reasonably modern sip/PyQt5 combination was always going to hit
this, regardless of exact version – not an environment-drift issue,
a genuine upstream omission.
Fix: fix-minimum-abi-version.patch adds
%MinimumABIVersion "12.0" immediately after %Module(...) and
before %Import QtGui/QtGuimod.sip – position matters, the parser
rejects the directive (“move it closer to the %Module directive”) once
%Import has already triggered ABI finalisation. Applied via a new
prepare() as a standalone patch file (this project’s convention:
source fixes go in .patch files, not inline sed in the PKGBUILD).
Verified locally against the extracted
source before touching the PKGBUILD: with the patch, sip-build
generates cleanly and gets all the way to qmake (which only then
fails locally because qt5-datavis3d isn’t installed on this host –
irrelevant, it’s a real chroot depends). pkgrel 6 -> 7,
pkgver unchanged.
Real chroot test build (repo_build_staged.sh, x86_64) confirms: builds
clean, namcap only flags implicit/expected deps (glibc, libstdc++,
qt5-base – all transitively via qt5-datavis3d/python-pyqt5) and a
false-positive “python-pyqt5 may not be needed” (it’s an API-level dep,
not a linkage one, same as always). checkpkg shows no soname
differences vs. the currently-published 5.15.6-5.
Built+signed+published cleanly via repo_release.sh: 5.15.6-7 +
-debug, x86_64.