libkcompactdisc

• Path: arch/maintained/libkcompactdisc
• .nvchecker.toml scrapes the KDE GitLab tags page (https://invent.kde.org/multimedia/libkcompactdisc/-/tags) with a regex (v([\d+.]+)) rather than using a GitLab-API-aware source — fragile to page layout/pagination.
• 2026-07-20: check_for_updates_maintained.sh flagged UPD with a bogus check version of 52 (vs. actual pkgver=25.12.3) — almost certainly a transient scrape glitch (GitLab tags page returned something the regex mismatched against, e.g. a merge-request or pipeline number). Re-running nvchecker -c .nvchecker.toml immediately after correctly returned 25.12.3, matching the installed pkgver — no actual update needed. If this recurs, re-run nvchecker standalone before trusting a 52-style implausible version number from this package.
• 2026-07-28: recurred, this time as UPD ... 25.12.3 58 (bogus 58). Standalone nvchecker -c .nvchecker.toml again returned 25.12.3, matching pkgver — no update needed. Confirms this is a recurring transient scrape glitch on the GitLab tags page, not a one-off; the batch run inside check_for_updates_maintained.sh seems to hit it more than a standalone rerun does (maybe rate-limiting/pagination under the full-tree scan’s request volume). Treat any implausible single/double digit “new version” from this package as this glitch and just re-verify with a standalone nvchecker run rather than acting on it.

AUR comment already resolved (checked 2026-09-21)

jsimon0 (2026-05-31) asked to add PGP key BB463350D6EF31EF for source verification. Already present – it’s the trailing 16 hex chars of the third validpgpkeys entry, D81C0CB38EB725EF6691C385BB463350D6EF31EF (Heiko Becker). Current pkgrel=2/25.12.3 is published and up to date. No action needed; no AUR reply posted (see [[python2]]’s 2026-09-21 entry for why).