aurupdater

libarchive-static

Build times (auto-updated)

Build times (auto-updated)

2026-11-11/12: openssl bump 3.6.5 -> 4.1.0 (new major series), pkgrel 2 -> 3

User-requested (“enqueue libarchive-static for openssl update”), alongside the identical bump in [[pacman-static]]. _sslver=3.6.5 was already the newest release in OpenSSL’s 3.x line – no newer 3.x patch exists. The only thing actually newer upstream is the new 4.x major series (4.1.0 full release, just out). Checked with the user before touching the PKGBUILD since a major-version jump is more than a routine bump:

Built all 7 archs. aarch64 and armv7h both FAILED on the first pass purely from remote-board lock contention with pacman-static’s own concurrent run (both packages hit the exact same boards at the same time, lock fails closed by design – see [[remote_build_board_lock]]) – retried cleanly once both boards freed up, no package-level issue at all. All 7 archs published 3.8.11-3 with no connection failures.

User-requested bundled-openssl bump, same as [[pacman-static]]’s same-day entry (3.6.4 -> 3.6.5, real upstream release). Packaging-only pkgrel bump. updpkgsums clean, i486/armv6h SKIP-checksum case block (see this file’s own 2026-08-13-ish entry) left untouched and still correct. FEEDBACK.txt thread ANSWERED (2025-03-16), nothing new.

First repo_release.sh pass: i486 + all 3 ARM boards (armv6h/armv7h/ aarch64) succeeded, but i686/pentium4/x86_64 all failed at the very first step – pacman -Syu inside the chroot couldn’t reach archlinux32.andreasbaumann.cc (Connection timed out) – a transient network blip on the repo host, confirmed resolved within the hour (plain curl/ping to the host came back clean immediately after). Retried just those 3 with REPO_BUILD_ONLY_ARCH="i686 pentium4 x86_64" – all green on retry, confirmed via repo_arch_status.sh (all 7 at 3.8.9-5).

Two harmless-noise patterns seen in the retry log, neither indicating a real problem:

2026-11-10 (follow-up): ARM archs blocked by pacman-static board lock, retry pending

repo_release.sh maintained/libarchive-static published i486/i686/ pentium4/x86_64 at 3.8.11-2 cleanly (confirmed via repo_arch_status.sh), but armv6h/armv7h/aarch64 all failed closed: eurobuild4 is already building something else -- pacman-static (armv6h) ... (and same for eurobuild5/eurobuild14) – [[pacman-static]]’s own all-arch rebuild (same session, launched first) was already mid-build on all 3 ARM boards when this package’s remote dispatch ran. Exactly the “fails closed, kill+retry the losing job” behavior described in [[remote_arm_build_machines]] – not a bug, and nothing to clear, since the lock is legitimately held by a real in-progress build, not stale. ARM archs remain published at 3.8.11-1 (last known-good, zlib 1.3.2) until the retry. Follow-up: once pacman-static’s ARM builds finish and free the boards, rerun REPO_BUILD_ONLY_ARCH="armv6h armv7h aarch64" repo_release.sh maintained/libarchive-static to bring those 3 up to 3.8.11-2.

2026-11-10: zlib 1.3.2 -> 1.4 (pkgrel 1 -> 2), dropping the CVE-2026-85091 patch

Triggered by an AUR comment on [pacman-static] – same _zlibver=1.3.2 source affects this package identically, since both vendor zlib via the same source+=("https://zlib.net/zlib-${_zlibver}.tar.gz"...) pattern. Confirmed via curl -I: zlib.net/zlib-1.3.2.tar.gz -> 404, zlib.net/fossils/zlib-1.3.2.tar.gz -> 200 (upstream moved old releases to a fossils/ subdir when 1.4 shipped 2026-11-04).

First considered the minimal fix (repoint the URL at fossils/, keep 1.3.2 + the local CVE patch) but the user asked to check Arch’s own zlib package first. Arch’s packaging repo (gitlab.archlinux.org/archlinux/packaging/packages/zlib) had already bumped straight to 1:1.4-1 (tag 1-1.4-1, 2026-11-06, 4 days before this check) and dropped the patch entirely – their own 1:1.3.2-4 → 1:1.4-1 commit confirms zlib 1.4 folds in the exact same unreleased-git-commit fix for CVE-2026-85091 that our local zlib-1.3.2-CVE-2026-85091.patch applied (see this file’s 2026-10-14 entry – that patch is now upstream, redundant, and was removed here). Note: pacman -Q zlib on the build host still shows 1.3.2-4 – that’s just this machine not having synced yet, not evidence Arch stayed on 1.3.2; always check the packaging repo’s live PKGBUILD (or pkgctl repo clone zlib), not the locally installed version, when deciding whether to follow Arch’s lead on a bundled dep.

User decided to follow Arch’s bump rather than just patch the URL: _zlibver 1.3.2 -> 1.4, source URL back to plain zlib.net/zlib-${_zlibver}.tar.gz (1.4 is the current release, not in fossils/), dropped the zlib-1.3.2-CVE-2026-85091.patch source entry and its prepare() application step, deleted the now-unused patch file from the package dir. New sha512sum verified two ways before trusting it: matched the SHA-256 zlib.net publishes on its own download page, and recomputed locally from a fresh download.

Array-index gotcha repeats from the 2026-10-14 entry, in reverse: removing the CVE-patch source entry shifts every later index back by one – this package’s case "${CARCH}" in i486|armv6h) block’s sha512sums[14] (old xz-git override, added when the patch entry was inserted) had to become sha512sums[13]. Verified via makepkg --printsrcinfo | awk '/^ source = /{print NR": "$0}' against the case-statement indices rather than counting by hand, same technique as before.

[[pacman-static]] got the identical fix in the same session (its own memory/pacman-static.md has the full array-index trace for that package, which has a longer source array). Breaking-changes section of zlib 1.4’s release notes is CMake/Windows/minizip-specific; nothing affects this package’s plain ./configure --static Linux build.

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

User asked for a bundled-zlib security fix. zlib 1.3.1.2 through 1.3.2 (current _zlibver) has a heap buffer overflow in gz_vacate()/gz_write() reachable via gzprintf()/gzvprintf() after a non-blocking gzwrite() stall with a stale external buffer pointer (CVE-2026-85091, CVSS 8.3). There is no zlib 1.3.3 tarball release containing the fix – upstream fixed it only as a git commit (df84af25dc1942490e1d1c899a07619152a46148, “Fix buffer overflow bug in non-blocking gzwrite”, 4 lines in gzwrite.c). Confirmed via pkgctl repo clone zlib (Arch’s own packaging repo) that Arch Linux’s own zlib package handles this the same way: no pkgver bump, pkgrel 3 -> 4, fetches that exact commit as a .patch and applies it in prepare() – verified our downloaded patch’s sha512 matches Arch’s .SRCINFO byte-for-byte (a8cca9039ff9f09f92fa7fbcf5c6744615e8cd71a033784c0b996ee931af0dfa69f5b6efb67243693d418b9b3e1f7dadc178335bd407b72b0d72bdc4679da9ff), so this is the authentic upstream fix, not a guess.

Committed the patch locally as zlib-1.3.2-CVE-2026-85091.patch (matching this file’s existing local-patch convention, e.g. libarchive-3.8.3-all-static.patch – unlike pacman-static, which already fetched some patches by URL, this PKGBUILD had none, so kept it consistent with its own style rather than pacman-static’s). Applied in prepare() right after the existing openssl patch block, cd "${srcdir}/"zlib-${_zlibver} then patch -Np1. Dry-run verified clean against a freshly downloaded real zlib-1.3.2 tarball before touching the PKGBUILD.

Inserting a new source/sha512sums entry mid-array shifts every later index – this package’s case "${CARCH}" in i486|armv6h) block hard-codes array indices for the two git sources that can’t be sha512-checksummed on old pacman (see the 2026-08-27 entry below). The new zlib patch source landed right after the zlib tarball/sig (old index 12/13), between them and the xz git source – so sha512sums[13] (old xz-git override) had to become sha512sums[14]. Verified the final .SRCINFO’s source/sha512sums pairs line up 1:1 by paste-ing them side by side rather than counting by hand.

Packaging-only (no pkgver bump, per [[feedback_pkgrel_vs_pkgver]]). Built Intel-only this round (REPO_BUILD_ONLY_ARCH="i486 i686 pentium4 x86_64") – user explicitly deferred armv6h/armv7h/aarch64 since the ARM cluster (eurobuild4/5/14) is currently down; do those archs in a follow-up once it’s back.

2026-10-31 (follow-up): implemented the “wait for Arch” idea as .nvchecker-gate.toml

Added .nvchecker-gate.toml ([gate] source="archpkg" archpkg="libarchive") right here in this package’s own dir. check_for_updates_maintained.sh now checks it whenever this package would otherwise show UPD: if upstream (this package’s .nvchecker.toml, tracking libarchive’s own GitHub tags) is still ahead of Arch’s own core/libarchive version, the state becomes WAIT instead – visible but not actioned by a routine update cycle. Confirmed against the exact live state right after the revert below: upstream 3.8.11, Arch still 3.8.10 -> correctly shows WAIT, not UPD, in both STATES.txt and OVERVIEW.md (🟣 icon). Full mechanism detail in memory/TOOLING_NOTES.md. Once Arch repackages 3.8.11, this should flip back to UPD on its own and the 3.8.11 rebuild+publish can go ahead for real.

2026-11-01: gate lifted, 3.8.11 published for real

Re-checked the gate a few hours later (same day): Arch’s own core/libarchive had moved to 3.8.11-1 (confirmed across 3 retries after one transient archlinux.org connection-reset false alarm – retrying the gate check itself is worth doing before trusting a single result). check_for_updates_maintained.sh correctly flipped back to UPD. Bumped pkgver 3.8.10 -> 3.8.11 again (same diff shape as the 2026-10-31 attempt that got reverted – only sha512sums[0] changes via updpkgsums), built+signed+published across all 7 archs via MAKEFLAGS=-j6 repo_release.sh. Confirmed published (3.8.11-1) on all 7 via repo_arch_status.sh, no connection/mktemp errors in the full log.

Total wall clock ~3h40m this run – armv6h was the long pole again (3h39m, back to its old serial baseline; the 2026-10-31 run’s unusually-fast 46m/14m armv7h/aarch64 parallel dispatch doesn’t apply to armv6h itself, which has always been the slowest board regardless). Confirmed genuine progress rather than a hang partway through by checking the board directly (pgrep -af makepkg + recent file mtimes in the build dir), not just trusting elapsed time – useful technique for any future multi-hour remote build that looks suspiciously quiet.

2026-10-31: 3.8.10 -> 3.8.11 built+published, then REVERTED same session – hold until Arch’s own libarchive catches up

Confirmed real upstream tag (v3.8.11) via git ls-remote before bumping. Bundled-dep diff (nvchecker-deps.toml) empty – none of attr/acl/openssl/ zlib/xz/bzip2/zstd changed. Followed the documented procedure exactly: bumped pkgver, pkgrel stayed at 1, updpkgsums (only sha512sums[0] changed, as expected), regenerated .SRCINFO. Ran update_pgp_key_dir.sh first – all keys unchanged.

Built+signed+published via MAKEFLAGS=-j6 repo_release.sh across all 7 archs in one call – i486/i686/pentium4/x86_64 locally (sequential, ~8-9min each) then armv6h/armv7h/aarch64 dispatched to eurobuild4/5/14 in parallel (not serial), so this round’s remote wall-clock was bounded by the slowest board rather than the sum of all three – much faster than the 2026-08-27 entry’s serial figures. All 7 confirmed published (3.8.11-1) via repo_arch_status.sh, no connection-reset/mktemp errors in the full log. Usual harmless noise only (BSD is not a valid SPDX license identifier, checkpkg soname-diff warnings).

User then asked to hold: unlike the 2026-10-15 entry’s “ahead of Arch’s own packaging, known exception” stance, this time the user explicitly wants to wait for Arch’s official core/libarchive to actually ship 3.8.11 before publishing our static build at that version – revert to 3.8.10 live for now, re-publish 3.8.11 later once Arch catches up. Follow-up idea from the user, not yet implemented: have the update-check tooling cross-check a *-static package’s upstream version against whether Arch’s own corresponding package has picked it up yet, so this gap is caught before a build, not after a publish – worth revisiting for this package and [[pacman-static]] alike.

Revert execution hit a real self-inflicted bug worth remembering: restored 3.8.10 by downloading the archived 3.8.10 files back from archive/<arch>/ and calling repo_publish.sh on them – but passed both the .pkg.tar.xz and its .pkg.tar.xz.sig as separate positional arguments (globbed *3.8.10*.pkg.tar.xz*). repo_publish.sh’s usage is “one or more PACKAGE files” – it handles each file’s .sig automatically and does NOT expect the .sig passed as its own argument. Passing it anyway makes the script process the .sig as if it were itself a same-named/same-version package to publish: it re-archives the just-uploaded real package (now “old” relative to this bogus duplicate target) via _archive_old, uploads the .sig into os/<arch>/ as if it were data, then fails repo-add on it (bsdtar: Error opening archive: Unrecognized archive format / is not a package file, skipping / Package database was not modified due to errors) – net effect across every arch: the db ends up with no entry at all (“not published” on repo_arch_status.sh), and os/<arch>/ is left with only a stray orphaned .sig (the real .pkg.tar.xz got swept into archive/ a second time instead). Not caught until a repo_arch_status.sh check right after. Fix: always pass only the real package file(s) to repo_publish.sh, never the matching .sig alongside it as a separate arg – re-ran with just the 11 .pkg.tar.xz paths (7 main + 4 debug) and it published clean. Confirmed fully restored via repo_arch_status.sh (published (3.8.10-1) on all 7) and a direct os/<arch>/ listing (correct .xz+.sig pair each, no orphans).

Local PKGBUILD/.SRCINFO reverted back to 3.8.10 via git checkout -- PKGBUILD .SRCINFO (working-tree revert against the already-committed 3.8.10 state, no new commit). Downloaded source cache (openssl/zlib/attr/acl/bzip2/zstd tarballs + libarchive/xz git clones, plus the temporarily-redownloaded 3.8.10 package files) all cleaned up from the package dir. The PGP key-dir refresh from this same session (all keys unchanged, harmless) was left in place.

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

Full detail on the 3.8.9 -> 3.8.10 bump itself (all 7 archs, pkgrel reset to

  1. is in UPDATES.md’s entry for this session’s build queue. This entry is just about the nvchecker exception: .nvchecker.toml deliberately tracks libarchive’s own GitHub releases directly (confirmed live, 3.8.10), not Arch’s official core/libarchive package (still 3.8.9-1 as of 2026-10-15, per nvchecker-deps.toml-style archpkg tracking elsewhere in this tree). Added a comment to .nvchecker.toml right above the [libarchive] section explaining this, so a future session seeing our pkgver run ahead of Arch’s own package doesn’t mistake it for a problem – it’s expected to self-resolve once Arch repackages libarchive 3.8.10 on their end. See [[memory/pacman-static.md]] for the same exception on the bundled copy of libarchive pacman-static vendors.