pacman-static

Build times (auto-updated)

i486: 11m41s (2026-10-17 15:05 UTC, MAKEFLAGS=-j6)
x86_64: 8m19s (2026-10-17 15:50 UTC, MAKEFLAGS=-j6)
i686: 36m33s (2026-10-17 15:41 UTC, MAKEFLAGS=-j6)
pentium4: 16m35s (2026-10-17 16:11 UTC, MAKEFLAGS=-j6)
armv6h: 5h38m (2026-10-19 23:57 UTC, remote, serial)
armv7h: 2h19m (2026-10-19 23:57 UTC, remote, MAKEFLAGS=-j1)
aarch64: 41m29s (2026-10-19 23:57 UTC, remote, MAKEFLAGS=-j1)

2026-10-17: curl 8.22.0 -> 8.23.0, Intel archs only (ARM deliberately skipped)

User asked specifically for curl (per nvchecker -c nvchecker-deps.toml diff: “curl: updated from 8.22.0-1 to 8.23.0-1”) on x86_64/i686/pentium4/i486 only – explicitly not ARM this time. pkgrel 22 -> 23 (bundled-dep bump, pkgver itself tracks the pacman git version separately, untouched). Ran scripts/update_pgp_key_dir.sh first (all keys unchanged, including Daniel Stenberg’s curl key). libarchive was already at 3.8.10 from a prior session, untouched here.

Built via REPO_BUILD_ONLY_ARCH="x86_64 i686 pentium4 i486" repo_release.sh – this env var is required to avoid triggering the remote ARM builds that a plain repo_release.sh call on this package would otherwise kick off automatically (repo_build.sh builds every arch in the PKGBUILD’s arch=() it has a local or remote path for; it doesn’t limit itself to local archs on its own).

pentium4 failed on the first pass with the same mirror.archlinux32.org flakiness documented elsewhere (connection timeout / “Operation too slow”); x86_64/i686/i486 built fine in that same run. Retried with REPO_BUILD_ONLY_ARCH="pentium4" once the mirror answered a plain curl again – succeeded. All 4 Intel archs now at -23; ARM (armv6h/armv7h/aarch64) left untouched at -22 as asked.

After a successful dep bump + build, remember to cp nvchecker-new.txt nvchecker-old.txt (done this time) so the next check_for_updates_maintained.sh run doesn’t re-report this same curl bump as pending.

2026-10-19/20: ARM catch-up to pkgrel 23 (“the cluster is up”)

Ran the ARM archs deliberately skipped above once the user confirmed the remote build boards were back online: REPO_BUILD_ONLY_ARCH="armv6h armv7h aarch64" repo_release.sh maintained/pacman-static. All three built and published cleanly on the first try (no mirror flakiness this time) – aarch64 (eurobuild14) finished first (~41m), armv6h (eurobuild4, serial/no parallelism on that board) and armv7h (eurobuild5) took their usual much longer ~5h38m/ ~2h19m. All 7 archs now at -23.

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.

2026-10-14: bundled zlib CVE-2026-85091 fix (pkgrel 20 -> 21), Intel-only this round

Same bundled-zlib security fix as [[libarchive-static]] this same day – see that file for the full CVE/patch detail (no zlib 1.3.3 release exists; fix is an unreleased upstream git commit, df84af25dc1942490e1d1c899a07619152a46148, confirmed authentic against Arch Linux’s own zlib packaging repo via pkgctl repo clone zlib). Unlike libarchive-static, this PKGBUILD already fetches two patches by URL with a pinned hash (pacman-revertme-makepkg-remove-libdepends-and-libprovides.patch, pacman-reproducible-builds.patch) – could have matched that style, but used the same locally-committed zlib-1.3.2-CVE-2026-85091.patch file in both packages instead, for one consistent artifact shared between them rather than two different source-declaration styles for the identical patch.

Same array-index trap as libarchive-static: this PKGBUILD’s case "${CARCH}" in i486|armv6h) block hard-codes four indices (pacman git, brotli git, xz git, libseccomp git – the sources that can’t be sha512-checksummed on old pacman). The new zlib patch source lands between the zlib tarball/sig and the xz git source, so only the indices after the insertion point shifted: sha512sums[14] (xz git) -> sha512sums[15], sha512sums[27] (libseccomp git) -> sha512sums[28]; index 0 (pacman git) and index 11 (brotli git) are before the insertion point and stayed unchanged. Verified the final .SRCINFO source/sha512sums pairing with paste rather than counting by hand – same lesson as [[libarchive-static]]’s 2026-08-27 entry about this array.

Packaging-only (no pkgver bump). Built Intel-only (REPO_BUILD_ONLY_ARCH="i486 i686 pentium4 x86_64"), ARM cluster (eurobuild4/5/14) currently down – armv6h/armv7h/aarch64 deferred to a follow-up session. This package’s full local build chain is slow (nghttp2 + curl + openssl + brotli + zlib + xz + bzip2 + zstd + libarchive + libgpg-error + libassuan + gpgme + libseccomp + pacman itself, serially, per arch) – expect each Intel arch to take noticeably longer than libarchive-static’s equivalent run; don’t mistake a long quiet stretch for a hang.

i686/pentium4 transient mirror failure: first build attempt’s i686 and pentium4 legs both failed identically and immediately – error: failed retrieving file 'core.db'/'extra.db' from mirror.archlinux32.org : Connection timed out during the chroot’s own pacman -Syu sync, before the real build even started (same category as the known harmless signal-11-during-chroot-sync noise, but this one actually aborted the build rather than just logging noise). i486/x86_64 succeeded in the same run – mirror-specific/transient, not a PKGBUILD or toolchain issue. Confirmed mirror reachable again with a plain curl a few minutes later and reran just the two failed archs (REPO_BUILD_ONLY_ARCH="i686 pentium4") – succeeded immediately. If i686/pentium4 (the 32-bit archlinux32 mirror) fail on a database-sync timeout again, check mirror reachability before assuming a real build problem.

2026-10-15: bundled libarchive 3.8.10 ahead of Arch’s official core/libarchive – marked as a known exception, not a bug

Full detail on bumping the bundled _libarchive_ver 3.8.9 -> 3.8.10 (all 7 archs) is in UPDATES.md’s entry for this session’s build queue. This entry is just about the nvchecker exception the user asked to have marked: this package’s nvchecker-deps.toml tracks its bundled libarchive copy via archpkg = "libarchive" (Arch’s official package, still 3.8.9-1 as of 2026-10-15) rather than libarchive’s own upstream – intentional, since the whole point of that file is “is our bundled dep stale vs. what Arch ships”, not “what does upstream have”. We bumped ahead of that baseline anyway this time (tracking libarchive’s real upstream release directly, same as [[memory/libarchive-static.md]]), so our bundled version is now ahead of what nvchecker-deps.toml’s [libarchive] entry reports. Added a comment there explaining this is expected and will self-resolve once Arch repackages – a future session seeing this mismatch shouldn’t “fix” it by reverting to 3.8.9, and shouldn’t abort/hold up a build or publish over it either (the user’s own words: “we don’t abort the builds and publishes this time”).