pacman-static

• Path: arch/maintained/pacman-static
• pkgver tracks the pacman git repo itself (_git_tag + optional _git_patch_level_commit) and is set manually, not auto-computed by a pkgver() function — a pacman version bump is a separate concern from the bundled third-party dependency bumps below.
• Bundled deps each have a _xxxver variable and are tracked via nvchecker-deps.toml (archpkg source, i.e. compared against current Arch package versions): nghttp2, curl, openssl, brotli, zlib, xz, bzip2, zstd, libarchive, libgpg-error, libassuan, gpgme, libseccomp.
• scripts/check_for_updates_maintained.sh runs nvchecker -c nvchecker-deps.toml for this package (and libarchive-static) unconditionally at the top of the script, before the main UPD/OK/? loop — its output isn’t part of the OK/UPD/? summary table, it only shows up as log lines in stderr (STATES.stderr). Check STATES.stderr for “updated from X to Y” lines — that’s the actual signal that a bundled dependency here (or in libarchive-static) needs bumping, since the version-check table doesn’t cover these deps at all.
• nvchecker’s old/new comparison files (nvchecker-old.txt, nvchecker-new.txt) must be kept in sync manually: after successfully bumping deps and building, cp nvchecker-new.txt nvchecker-old.txt so the next run doesn’t re-report already-applied bumps as new. If deps are unchanged, old/new are already identical and nothing to do.
• 2026-07-02: bumped curl 8.20.0->8.21.0, gpgme 2.1.0->2.1.2, libarchive 3.8.7->3.8.8 (all per nvchecker-deps.toml diff), pkgrel 12->13 (pkgver itself unaffected, it’s the pacman git version). updpkgsums + rebuilt .SRCINFO. Built cleanly on x86_64, i686, pentium4, i486.
• Same known-harmless noise as libarchive-static: namcap SPDX-license / RELRO / PIE / unstripped warnings and the chroot’s broken pyalpm/libalpm namcap crash — none of these indicate a real build failure, check for the produced .pkg.tar.xz instead.
• 2026-07-07, private-repo release pass: this package’s PKGEXT=.pkg.tar.xz override (line ~144 of the PKGBUILD, deliberate — “keep using xz-compressed packages… to recover on systems with broken zstd support”) tripped a real bug in repo_release.sh, which hardcoded a .pkg.tar.zst-only glob for sign/publish. Build succeeded but the script reported ERROR: no *.pkg.tar.zst found ... after build. Fixed by making repo_release.sh collect every valid package extension (.gz/.bz2/.xz/.zst/.lz) — see memory/libarchive-static.md for the same issue there. Signed and published successfully afterward from the already-built .xz artifacts.
• c-ares was never actually needed — removed from tracking 2026-07-18. Discovered 2026-07-17 while auditing a STATES.stderr “c-ares: updated from 1.34.6-1 to 1.34.8-1” line: unlike every other tracked dep, there was no matching _caresver-style variable anywhere in the PKGBUILD, and curl’s configure invocation (package(), around line 306) uses --without-{libidn2,librtmp,libssh2,libpsl,gssapi,nghttp3,ngtcp2} with no --enable-ares — curl here is built with the plain synchronous resolver, c-ares is never vendored/linked. Confirmed with the maintainer 2026-07-17 it was a stale/phantom entry; on 2026-07-18 [c-ares] was removed from nvchecker-deps.toml, and the matching entries were removed from nvchecker-old.txt/nvchecker-new.txt to keep them in sync. No PKGBUILD change needed since c-ares was never referenced there.
• 2026-07-17: ran a full update_cycle.sh pass. nvchecker-old.txt vs nvchecker-new.txt diff showed only the c-ares phantom bump above — every real bundled dep (curl, gpgme, libarchive, etc.) already matches the 2026-07-02 bump. No PKGBUILD change made.
• Why this package’s libarchive dep tracking lags libarchive-static’s own pkgver — asked/confirmed 2026-07-28. This package’s nvchecker-deps.toml tracks libarchive with source = "archpkg" (compares against the official Arch package version at archlinux.org/packages/core/x86_64/libarchive), by design – the intent is to bundle whatever Arch has actually packaged/vetted, not raw upstream tags. maintained/libarchive-static (a different package, its own standalone libarchive build) instead tracks libarchive directly via source = "git" against github.com/libarchive/libarchive tags in its own .nvchecker.toml – it sees a new upstream tag the instant it’s pushed. So when upstream tagged v3.8.9 (2026-07-28), libarchive-static flagged it immediately but this package’s checker correctly reported no change, since Arch’s own libarchive package was still 3.8.8-2 at the time – not a bug in either checker, just two different, intentional reference points. Once Arch rebuilds their libarchive package against 3.8.9, this package’s next nvchecker-deps.toml run will pick it up on its own.
• 2026-07-30: that predicted pickup happened – Arch’s official libarchive package moved to 3.8.9-1, so nvchecker -c nvchecker-deps.toml flagged it here too. Bumped _libarchive_ver 3.8.8 -> 3.8.9, pkgrel 13 -> 14, ran updpkgsums + regenerated .SRCINFO, then cp nvchecker-new.txt nvchecker-old.txt per this file’s own sync note above. Built and published cleanly on all four locally-buildable archs (i486, i686, pentium4, x86_64); arm/armv6h/armv7h/aarch64 skipped as expected (no local chroots, see TOOLING_NOTES.md).
• 2026-07-31: routine bundled-dep check (nvchecker -c nvchecker-deps.toml) flagged nghttp2 1.69.0-1 -> 1.70.0-1. Bumped _nghttp2_ver 1.69.0 -> 1.70.0, pkgrel 14 -> 15, updpkgsums + .SRCINFO + cp nvchecker-new.txt nvchecker-old.txt. Built and published cleanly on all four archs again.