qgpgme1-qt5

• Path: arch/maintained/qgpgme1-qt5
• 2026-07-28: failed in the routine repo_release_changed.sh batch – Missing dependencies: gpgme-1, qt5-base. gpgme-1 is a package in this same tree (arch/maintained/gpgme-1), not an official-repo package, so archlinuxaba-x86_64-build can only resolve it if it’s already published to the private repo. It failed to build in the same batch run (see memory/gpgme-1.md – transient upstream 429 rate limit on dev.gnupg.org, not a real defect), so it was never published, so this package’s dependency resolution failed too. This is the documented intra-tree ordering gotcha ([[private-repo-changed-only-builds]] / TOOLING_NOTES.md), not a problem with qgpgme1-qt5 itself – retry once gpgme-1 is successfully published.
• 2026-07-29: retried after gpgme-1 1.24.3-5 (github-mirror fix) published for x86_64. Dependency resolution now fine, but hit a real packaging bug: package() only ran make DESTDIR=... install inside lang/qt, never installing lang/cpp. The install-time libtool relink of libqgpgme.so needs -lgpgmepp resolvable under $pkgdir/usr/lib – gpgme-1 (this package’s depends=) does ship the runtime libgpgmepp.so.6.21.3 + versioned symlink, but deliberately no unversioned dev symlink (see memory/gpgme-1.md’s package() – headers moved to a nonstandard gpgme1/ prefix, no pkgconfig/cmake, runtime-only by design), so linking -lgpgmepp failed with cannot find -lgpgmepp.
  • Fix (pkgrel 1 -> 2): package() now runs make -C lang/cpp DESTDIR="${pkgdir}" install first (installs lang/cpp’s libgpgmepp into $pkgdir purely so the relink step can find it), then installs lang/qt as before, then strips the cpp bindings back out (usr/include/gpgme++, usr/lib/libgpgmepp*, usr/lib/cmake/Gpgmepp, usr/lib/pkgconfig/gpgmepp.pc) before the existing QGpgme -> QGpgmeQt5 cmake rename – gpgme-1 already ships the actual runtime lib, no need to duplicate/conflict with it. Verified the built x86_64 package only contains libqgpgme.so*, no leftover libgpgmepp*. Published successfully.
  • Worth checking whether qgpgme-qt5 (the modern gpgme-2.x sibling, which uses cmake --install build for the whole tree instead of a subdirectory make install) is naturally immune to this same class of bug, or just hasn’t hit it yet.