trojita

Build times (auto-updated)

• x86_64: 12m24s (2026-09-10 15:25 UTC, serial)

---

• Path: arch/maintained/trojita
• The 2026-07-07 patch-checksum failure noted below was fixed by commit daed407 (“updated patch checksums”) — not reproducible any more as of 2026-07-20.
• 2026-07-20: cannot locally test-build at all, for an unrelated reason — depends=(... qt5-webkit qtkeychain-qt5 ... qgpgme-qt5 mimetic) (PKGBUILD:15) includes qt5-webkit, which is not part of this tree (no maintained/qt5-webkit dir) and is maintained on AUR by someone else (FabioLolix, not andreas_baumann). qtkeychain-qt5, qgpgme-qt5, and mimetic are in this tree and are published to the archlinuxaba private repo, so those resolve fine via archlinuxaba-x86_64-build (see TOOLING_NOTES.md’s intra-tree dependency section) — but pacman’s “install missing dependencies” is a single transaction, so the one unresolvable qt5-webkit fails the whole build with error: target not found: qt5-webkit (and lists the other three as “missing” too, misleadingly, even though only qt5-webkit is actually the blocker).
  • This is an environment gap, not a packaging bug in trojita itself: verifying a trojita build here would require also packaging/building qt5-webkit (a large, obsolete Qt5 module dropped upstream), which is out of scope unless explicitly asked for.
• 2026-08-02: qt5-webkit was explicitly asked for this time (as part of a broader vendoring pass), but deliberately deferred without attempting – available disk was too tight (~22GB free) to risk a multi-hour WebKit build failing partway through, same call as qt5-webengine (see memory/qmc2.md). Revisit with more disk headroom.
• 2026-09-10: the qt5-webkit gap is resolved (now built via local-install/qt5-webkit, per install_only_packages) – a routine repo_release_changed.sh cycle got past dependency resolution and reached actual compilation for the first time. Hit a new, real, unresolved blocker: gpgme++/key.h:355 (system header, from the gpgmepp package) declares std::vector<std:: string_view> keyGrips() const – std::string_view is a C++17 library feature, but trojita’s CMake build compiles with -std=c++11 ... -std=gnu++14 (the last -std= flag on the command line wins), so under C++14 <string_view>’s contents are feature- test-guarded out even if included.
  • First attempt was wrong: assumed a missing #include <string_view> and patched src/Cryptography/GpgMe++.cpp to add it. Patch applied cleanly and looked plausible, but didn’t fix anything – the header just isn’t populated under C++14 regardless of whether it’s included, so the exact same error: 'string_view' is not a member of 'std' recurred at the same line. Reverted (pkgrel back to 16, patch file removed, .SRCINFO regenerated) rather than leave a non-functional patch checked in.
  • The real fix needed a C++ standard bump to (at least) C++17, which was not a safe drop-in change on its own: src/Imap/Parser/ MailAddress.h derives from std::binary_function (already emitting deprecation warnings under C++14) – std::binary_ function was removed outright in C++17, so bumping the standard alone would trade today’s string_view error for a new 'binary_function' is not a member of 'std' error at a different file.

2026-09-10 (same day): real fix landed – pkgrel 16 -> 17, builds and publishes clean

Found where the C++ standard was actually pinned: build()’s own cmake -B build ... -DCMAKE_CXX_STANDARD=14 ... line in the PKGBUILD itself – not CMakeLists.txt (which never sets CMAKE_CXX_STANDARD at all; the -std=c++11 seen in compiler invocations comes from cmake/FindCXXFeatures.cmake’s own detection, a lower-priority flag). An earlier attempt at this same fix tried patching CMakeLists.txt with set(CMAKE_CXX_STANDARD 17), which would have been silently overridden by this PKGBUILD-level -D cache variable (command-line -D definitions win over a plain set() in CMakeLists.txt) – caught before publishing, so no wasted build. Fix: bumped -DCMAKE_CXX_STANDARD=14 to =17 directly in the PKGBUILD, no CMakeLists.txt patch needed at all.

That alone would have broken on std::binary_function/std::bind2nd as predicted, so also swept the whole source tree for every C++17- removed pre-C++11 relic (not just the two MailAddress.h/ Recipients.cpp sites known about already) and found a third, previously unnoticed category: dynamic exception specifications (throw(SomeType) / throw()), also removed outright in C++17, in Exceptions.h/.cpp (what()/destructor overrides – replaced with noexcept, since std::exception::what() itself is noexcept) and Response.h/.cpp (kindFromString()/NumberResponse’s constructor – specific-type throw(X) specs have no direct modern equivalent, so just dropped). Also found Response.h’s CompareListDataIdentifier template deriving from std::unary_function (same removed-in-C++17 issue as binary_function) – safe to drop outright, its operator() already declares an explicit bool return and nothing else in the codebase touches its argument_type/result_type typedefs.

New patch trojita-0.7-cxx17-compat.patch covers all of the above in one patch (generated via real diff -u against a working copy, not hand-written – an earlier hand-written attempt at the MailAddress.h piece had malformed hunks that patch rejected outright). bind2nd call sites in Recipients.cpp became lambdas (the standard C++11+ replacement; the original code even had a resigned “I want to stop this madness. I want C++11.” comment right above them).

Verified via a full local build (not just --dry-run patch checks): patch --dry-run clean, then a real repo_release.sh maintained/trojita run – built, signed, and published cleanly on x86_64 (5m56s, pkgrel 0.7-17). No further C++17-removed constructs surfaced during the actual compile.

(historical, resolved) 2026-07-07 patch checksum failure

• Build failure during the 2026-07-07 “build all packages for x86_64” private-repo release pass (see repo_release_logs/maintained_trojita.log).
• Five of the nine local patch files failed their sha512sums check (trojita-fix-crash.patch, trojita-qt5.15.patch, trojita-desktop.patch, trojita-highdpi.patch, trojita-wayland.patch all FAILED; the other four Passed) — stale recorded checksums, fixed by re-running updpkgsums (commit daed407).