aurupdater

nvchecker coverage plan for the 79 ?-flagged packages

Research notes for adding .nvchecker.toml files to the 79 packages currently flagged ? (no upstream-version checker) by scripts/check_for_updates_maintained.sh. Planning only — no .nvchecker.toml files or PKGBUILD changes were made.

Key nvchecker facts discovered while researching this (confirmed against lilydjwg/nvchecker upstream source, July 2026):

KDE Frameworks 5 family (shared release cadence: pkgver 5.116.0 lockstep)

All five share one upstream release cadence (KDE Frameworks) and one source pattern: https://download.kde.org/stable/frameworks/<major.minor>/<name>-<pkgver>.tar.xz. Recommended check: self-hosted GitLab tags at invent.kde.org/frameworks/<name>.

(Repo paths under invent.kde.org/frameworks/* follow KDE’s standard Frameworks convention; worth a one-time sanity check per repo before writing the toml, but all five are well-known, actively maintained Frameworks modules.)

KDE PIM / Akonadi family (shared release cadence: “release-service” tarballs)

Nine packages share the KDE PIM / release-service source layout: https://download.kde.org/stable/release-service/<pkgver>/src/<name>-<pkgver>.tar.xz. Recommended check: GitLab tags at invent.kde.org/pim/<name>.

Note: akonadi-notes (Qt6) is currently at 24.08.3 while the rest of the family sits at 23.08.5 — they don’t all bump on exactly the same day, but they share the same release-service mechanism and repo-naming convention.

KDE Plasma 5 family (shared release cadence: pkgver 5.27.12 lockstep)

Three packages track the Plasma 5 LTS tarball layout at https://download.kde.org/stable/plasma/<pkgver>/<name>-<pkgver>.tar.xz.

KDE-adjacent standalone libraries (own release cadence, still invent.kde.org)

These are not part of the Frameworks/PIM/Plasma lockstep releases — each has its own versioning — but all live on KDE’s self-hosted GitLab, so the same gitlab + host = "invent.kde.org" mechanism applies per-repo.

qgpgme-qt5 — not KDE-hosted, but GPG-project-hosted (see GitHub section below)

GitHub release-tag packages (quick wins)

Straightforward: real GitHub repo, real version tags, source = "github" will just work.

GitHub/GitLab VCS commit-or-branch tracking (no versioned releases)

These packages use PKGBUILD pkgver() functions (or hand-maintained commit pins) rather than tagged releases — nvchecker’s generic git source (works over plain git ls-remote, no API/host restriction) is the right tool for all of them.

mp3splt monorepo family (shared upstream: github.com/mp3splt/mp3splt)

Three packages all pin different commits/tags of the same upstream monorepo, each building a different subdirectory (libmp3splt, newmp3splt, mp3splt-gtk) — they’ll always want independent nvchecker entries (different commit pins) but share one git config shape:

All three: source = "git", git = "https://github.com/mp3splt/mp3splt.git", use_commit = true, branch = "master".

Laborejo Software Suite family (Nils Hilbricht, hilbricht.net)

Five packages are all releases of Nils Hilbricht’s “Laborejo Software Suite”, all published to one flat directory: https://hilbricht.net/downloads/lss/. Verified live (July 2026) — the directory currently lists exactly the tarballs these five PKGBUILDs already use, confirming they’re all at the latest available version right now:

agordejo-0.4.2.tar.gz
laborejo-2.2.2.tar.gz
libcalfbox-lss-1.2.0.tar.xz
patroneo-2.4.1.tar.gz
tembro-0.6.0.tar.gz

The project also has a self-hosted GitLab (git.laborejo.org, referenced by libcalfbox-lss’s url=), but it did not resolve/respond during this research (TLS cert mismatch / domain not configured on the host) — treat it as unreliable and prefer the directory-listing regex instead.

Recommended for all five: source = "regex", url = "https://hilbricht.net/downloads/lss/", regex = "<pkgname>-([\\d.]+)\\.tar\\.(gz|xz)".

Launchpad-hosted packages (quick wins)

nvchecker has a native launchpad source (launchpad = "<project>", queries api.launchpad.net). All five of these already source from launchpad.net.

SourceForge-hosted packages (regex on RSS feed — no native sourceforge source)

nvchecker has no dedicated SourceForge source type. The working substitute, verified live against the real cppcms feed:

source = "regex", url = "https://sourceforge.net/projects/<project>/rss?path=/<project>", regex = "<project>-([\\d.]+)\\.tar\\.(gz|bz2)".

Fetched https://sourceforge.net/projects/cppcms/rss?path=/cppcms directly and confirmed entries like /cppcms/1.2.1/cppcms-1.2.1.tar.bz2 and beta releases like cppcms-2.0.0.beta2.tar.bz2 — the regex above naturally skips betas because .beta2 breaks the immediate \.tar\. match.

Debian/Ubuntu-archive-hosted packages

nvchecker has native debianpkg/ubuntupkg sources that query the Debian/Ubuntu package archives directly.

Plain HTTP/FTP directory-listing packages (regex on index page)

No API, no releases feed — just an old-school Apache/nginx directory index to regex against. Feasibility varies a lot by how alive the upstream still is.

Dead / frozen / no good automatic check

These are cases where either (a) upstream is confirmed gone/archived/dead, or (b) the package is intentionally frozen at a fixed version forever by design, so an automated “new version available” signal would never fire and isn’t meaningful. Forcing a checker onto these would just be noise.

Quick wins first (add these .nvchecker.tomls first — trivial, verified-working sources)

  1. cppcms — SourceForge RSS regex, verified live against the actual feed.
  2. bochs-gdb-stub — SourceForge RSS regex; upstream (bochs) is actively released.
  3. kchmviewer — plain github source, tag-based.
  4. libvisual — plain github source, tag-based.
  5. qgpgme-qt5 — plain github source (gpg/gpgmeqt), tag-based.
  6. lockdev — native ubuntupkg source, exact package-name match.
  7. dbmodel / dbmodel-qt4 / dbmodel-qt5 — native launchpad source, one config reused three times.
  8. trayclock, vattery — native launchpad source.
  9. agordejo, laborejo, libcalfbox-lss, patroneo, tembro — one shared regex against hilbricht.net/downloads/lss/, verified live (directory contents currently match all five PKGBUILDs exactly).
  10. kcontacts5, kdesu5, kitemmodels5, kplotting5, kunitconversion5 (KDE Frameworks) and the KDE PIM and KDE Plasma families — mechanically simple once the first gitlab+host=invent.kde.org config is written and proven, since it’s the same shape repeated ~17 times with just the repo path changing.

Hard / low-value / skip