qt5-connectivity

Build times (auto-updated)

aarch64: 6m41s (2026-09-08 10:25 UTC, remote)

Path: arch/maintained/qt5-connectivity (submodule).
KDE-maintained fork of Qt5’s Connectivity module (Bluetooth/NFC), built from invent.kde.org/qt/qt/qtconnectivity at a pinned commit, pkgver() computed as 5.15.19+kde+rN via git rev-list --count since the v5.15.19-lts-lgpl tag.
depends=(qt5-base bluez-libs), makedepends=(qt5-declarative git) all resolve from the official extra repo (not tracked in this arch/ tree) – nothing else needed building as a prerequisite.

2026-09-01: added aarch64

Previously arch=('x86_64') only. User added aarch64 to the PKGBUILD directly (pkgrel 1 -> 2, packaging-only change, no pkgver bump) – not a reply to duckie_xyz’s AUR comment asking for the same thing (see the entry below); user’s own call, made without commenting on AUR since it’s an obvious-enough fix not to need one. Built via the remote-ARM-board mechanism (see TOOLING_NOTES.md’s “Remote ARM build machines” entry) – dispatched to eurobuild14. Built and published cleanly on the first attempt for both x86_64 and aarch64, no arch-specific fixes needed. First qt5-family package in this tree to carry aarch64.

Did not add armv6h/armv7h – user was asked and chose aarch64-only for this round.

2026-09-07: AUR comment (already resolved before this session saw it)

duckie_xyz commented on AUR (2026-08-31) asking to add aarch64 – surfaced via check_aur_feedback.sh/FEEDBACK.txt on 2026-09-07, i.e. after the 2026-09-01 fix above had already landed (this package’s own .seen state apparently hadn’t captured that comment until this later run). Rebuilt+republished aarch64 without checking this file first – turned out to be a no-op: repo_publish.sh reported “Removing existing entry ‘qt5-connectivity-5.15.19-2’” before re-adding the identical build, i.e. 5.15.19-2/aarch64 was already live. Lesson: check this file before acting on a FEEDBACK.txt item, not just FEEDBACK.txt’s own dedup state – would have caught that this was already done and saved a redundant ~7 min remote build. No comment reply was ever posted on AUR for this one – confirmed deliberate (see the 2026-09-01 entry above): user fixed it directly and didn’t bother replying, an “obvious enough” fix. This means check_aur_feedback.sh’s ANSWERED-tracking (last-comment-authored-by-you) will never mark this thread answered even though it’s fully resolved – a real, accepted gap in that heuristic, not a bug. Don’t read “still shows as unanswered” as “still needs work” without checking the actual PKGBUILD/ repo state first.