pacman-static

Build times (auto-updated)

• i486: 14m6s (2026-10-01 17:27 UTC, MAKEFLAGS=-j6)
• i686: 13m58s (2026-10-01 17:41 UTC, MAKEFLAGS=-j6)
• pentium4: 13m51s (2026-10-01 17:55 UTC, MAKEFLAGS=-j6)
• x86_64: 12m23s (2026-10-01 18:07 UTC, MAKEFLAGS=-j6)
• armv6h: 5h38m (2026-10-01 23:46 UTC, remote, serial)
• armv7h: 2h20m (2026-10-01 23:46 UTC, remote, MAKEFLAGS=-j1)
• aarch64: 41m42s (2026-10-01 23:46 UTC, remote, MAKEFLAGS=-j1)

---

• 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.
• 2026-08-27: bundled-dep check flagged ssl 3.6.3-1 -> 3.6.4-1. Bumped _sslver, pkgrel 15 -> 16. Build initially failed on all 4 archs identically: openssl-3.6.4.tar.gz ... FAILED (unknown public key 64ED7B1DCCE71CB2) — OpenSSL rotated to a new dedicated release key (OpenSSL <openssl@openssl.org>, primary fingerprint B146647E45A7B33947AB226B2A2C87D161692D40, issued 2026-05-26, supersedes/supplements the old per-maintainer keys). Note: hkps://keys.openpgp.org had the key but stripped of its user ID (gpg refuses those — “new key but contains no user ID - skipped”); hkps://keyserver.ubuntu.com had the full key with UID and imported cleanly. Added the fingerprint to both validpgpkeys arrays (there are two separate openssl validpgpkeys+=() blocks in this PKGBUILD, keep both in sync — see [[libarchive-static]] which has the identical pair), reran update_pgp_key_dir.sh, rebuilt. Same key rotation affects memory/libarchive-static.md, bumped there in the same session.
• 2026-08-27: same old-pacman git-checksum fix as [[libarchive-static]], pkgrel 16 → 17. This PKGBUILD has four real (non-SKIP) git sources: pacman.git (index 0), git+brotli (index 11), git+xz (index 14), git+libseccomp (index 27) — verified via makepkg --printsrcinfo, source/sha512sums share 1:1 order (see TOOLING_NOTES.md’s remote-build entry for why hand-counting across source+=(...) blocks is risky). Added the same case "${CARCH}" in i486|armv6h) sha512sums[N]='SKIP' ;; esac pattern used there, SKIPping all four. Unlike libarchive-static, there was no pre-existing (dead or otherwise) guard here at all — first time this package gets the fix.
  • Confirmed a real, different root cause on top of the checksum fix: local i486/i686/pentium4/x86_64 built+published cleanly at pkgrel 17, but armv6h (eurobuild4) still failed — PKGBUILD: line 161: syntax error near unexpected token 'then' (if [[ ... ]] then with no ; before then, in the _git_patch_level_commit block). Reproduced directly: if [[ 1 != 2 ]] then echo yes; fi parses fine on bash 5.3.15 (eurobuild5/14, this host) but is a hard syntax error on bash 5.1.16 (eurobuild4) — a genuine bash grammar change between those versions (]] apparently became lenient enough to allow a following reserved word without a separator sometime after 5.1), not a “git trickery” issue as first guessed. Fixed with a plain ; before then — valid on every bash version, no behavior change. Kept pkgrel at 17 (this fix landed before ARM ever published successfully at that pkgrel, so it’s still one coherent release, not a second bump).
  • Also hit (and cleared) a stale/corrupted brotli git checkout on both eurobuild5 and eurobuild14’s /data/INSTALL/pacman-static/ — fatal: bad object refs/remotes/origin/test_902775910, pre-existing from those boards’ prior manual build history, nothing to do with this session’s changes. Fix: rm -rf the corrupted brotli/ dir on each board so makepkg re-clones fresh (our own rsync push never touches VCS-source checkout dirs — those live only where makepkg itself creates them on the remote board, so a stale one has to be cleared by hand, doesn’t self-heal).
  • Also hit a stale pacman/ VCS checkout on the same boards (a pacman-reproducible-builds.patch hunk failing with “the next patch would create the file … which already exists” — the working copy under $srcdir had already been prepare()-mutated by an earlier attempt at the same pkgver-pkgrel, and makepkg doesn’t clean $srcdir between retries by default). General fix landed in remote_build.sh itself (makepkg -s -C, -C/ --cleanbuild), not package-specific — see TOOLING_NOTES.md.
  • Full release confirmed 2026-08-28: all 7 archs (i486/i686/pentium4/x86_64 local, armv6h/armv7h/aarch64 remote) built+published cleanly at pkgrel 17 — first time this package has ever had armv6h/armv7h/aarch64 published. armv7h/aarch64 ran genuinely in parallel with each other (confirmed via scripts/repo_arch_status.sh), and armv6h needed a fresh REPO_BUILD_ONLY_ARCH=armv6h pass after eurobuild4 got rebooted mid-session (board got stuck, user rebooted it — remote_build.sh’s auto-mount handled /data coming back unmounted after reboot without further intervention once the board was back on the network).

2026-10-01: openssl bump to 3.6.5 (pkgrel 19 -> 20), all 7 arches incl. ARM

User-requested bundled-openssl bump (3.6.4 -> 3.6.5, real upstream release confirmed). Packaging-only, pkgrel bump per [[feedback_pkgrel_vs_pkgver]]. PGP keys already current (update_pgp_key_dir.sh run proactively, all unchanged). updpkgsums clean. FEEDBACK.txt thread already ANSWERED (2026-09-12), nothing new.

Full repo_release.sh maintained/pacman-static run, all 7 arches: local i486/i686/pentium4/x86_64 (~13-14 min each) then remote armv6h/armv7h/ aarch64 on eurobuild4/5/14. armv6h took 5h38m, within noise of the 5h37m baseline from 2026-09-13 – this package’s full bundled-dependency chain (nghttp2/curl/openssl/brotli/zlib/xz/bzip2/zstd/libarchive/ libgpg-error/libassuan/gpgme/libseccomp/pacman itself) compiled serially on that board is just genuinely a multi-hour job, not a hang. All 7 published cleanly, confirmed via repo_arch_status.sh.

Operational note: the session’s normal backgrounded-bash mechanism got killed repeatedly for unrelated long-running tasks this same session (see [[thunderbird-esr140-bin]]’s 2026-10-01 entry) – used the same nohup ... & disown + manual PID-polling workaround here from the start given the known ~6h+ total runtime, rather than risk losing a build this long to the same issue.

2026-09-12: xz bump to 5.8.4 (pkgrel 18 -> 19), stray ‘arm’ trimmed, AUR self-handled

User asked for the routine xz bundled-dep bump (5.8.3 -> 5.8.4, real upstream release tag confirmed). Also removed the already-stray 'arm' from arch=() (done in an earlier pass this session) and trimmed the matching dead arm|armv6h|armv7h) case-statement branches (OpenSSL target selection) – unreachable since 'arm' isn’t buildable here.

Hit the same lesson as libarchive-static (see that file’s own 2026-0x entry): the vendored xz git source isn’t a SKIP checksum here, it’s pinned with a real hash. Bumping _xzver alone left the stale 5.8.3 hash in place – i486/i686/pentium4/x86_64 all failed sha512sum validation on the git-cloned xz source until updpkgsums regenerated it.

A live AUR user (tmoorman) hit the identical bug the same day (comment 2026-09-12 14:06, checked via scripts/aur_comments.py pacman-static on request) – the exact xz ... FAILED sha512sum error, presumably from an AUR-side _xzver bump that had the same stale-checksum gap. User confirmed they pushed the fix to the public AUR PKGBUILD themselves (this project only handles the private archlinuxaba repo side, per [[feedback_never_git_commit_or_push]] – never pushes to AUR or anywhere else). No reply drafted for the AUR comment thread; not tracked further here since it’s the public AUR-side PKGBUILD, not this tree.