libarchive-static

Build times (auto-updated)

• i486: 8m26s (2026-10-15 00:29 UTC, MAKEFLAGS=-j6)
• i686: 8m26s (2026-10-15 00:38 UTC, MAKEFLAGS=-j6)
• pentium4: 8m26s (2026-10-15 00:46 UTC, MAKEFLAGS=-j6)
• x86_64: 7m33s (2026-10-15 00:54 UTC, MAKEFLAGS=-j6)
• armv6h: 3h39m (2026-10-15 04:34 UTC, remote, serial)
• armv7h: 1h28m (2026-10-15 04:34 UTC, remote, MAKEFLAGS=-j1)
• aarch64: 25m56s (2026-10-15 04:34 UTC, remote, MAKEFLAGS=-j1)

---

Build times (auto-updated)

• i486: 23m14s (2026-10-02 00:15 UTC, MAKEFLAGS=-j6)
• i686: 8m28s (2026-10-02 04:04 UTC, MAKEFLAGS=-j6)
• pentium4: 8m28s (2026-10-02 04:12 UTC, MAKEFLAGS=-j6)
• x86_64: 7m24s (2026-10-02 04:20 UTC, MAKEFLAGS=-j6)
• armv6h: 3h38m (2026-10-02 03:54 UTC, remote, serial)
• armv7h: 1h28m (2026-10-02 03:54 UTC, remote, MAKEFLAGS=-j1)
• aarch64: 25m49s (2026-10-02 03:54 UTC, remote, MAKEFLAGS=-j1)

---

2026-10-02: openssl bump to 3.6.5 (pkgrel 4 -> 5), all 7 arches incl. ARM

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:

• error: command terminated by signal 11: Segmentation fault during the chroot’s own pacman -Syu sync/upgrade step (e.g. around upgrading gzip/post-transaction hooks) – pre-existing chroot quirk, nothing to do with this package, happens before the actual build even starts.

• error: failed to commit transaction (conflicting files) / Errors occurred, no packages were upgraded. right after ==> Finished making: libarchive-static 3.8.9-5 – this is makepkg’s own disposable post-build test-install (pacman -U into the chroot for namcap/sanity checking), failing because this package’s static build intentionally installs under hardcoded /build/libarchive-static/src/temp/usr/... paths (the static-recovery design) that collide with leftover files already in the chroot from the build itself. The real package was already built and compressed by this point; signing/publishing afterward succeeded cleanly regardless.

• Path: arch/maintained/libarchive-static

• Source layout: pkgver tracks upstream libarchive only (git tag v${pkgver} from https://github.com/libarchive/libarchive.git). Bundled deps (attr, acl, openssl, zlib, xz, bzip2, zstd) each have their own _xxxver variable and are version-checked separately via nvchecker-deps.toml (archpkg source, i.e. compared against current Arch package versions). Don’t assume a libarchive bump means the deps need bumping too — check nvchecker-old.txt vs nvchecker-new.txt diffs first.

• Update procedure that worked (2026-07-02, 3.8.7 -> 3.8.8):

  1. Bump pkgver, reset pkgrel=1 in PKGBUILD.
  2. Run updpkgsums (needs real network — run with dangerouslyDisableSandbox if sandboxed curl gives spurious 404s). It re-clones the libarchive git tag and only the sha512sums[0] entry (the libarchive source) should change if deps are unchanged.
  3. Regenerate .SRCINFO with makepkg --printsrcinfo > .SRCINFO.
  4. Clean up: updpkgsums/makepkg leave the downloaded sources (openssl tarball etc, ~80MB) and cloned libarchive/, xz/ dirs behind in the package dir — remove them after a successful build.

• Builds for arch = i486, i686, pentium4, x86_64, arm, armv6h, armv7h, aarch64. Only i486/i686/pentium4/x86_64 buildable locally via archbuild (extra-i486-build, extra-i686-build, extra-pentium4-build, extra-x86_64-build). All four built cleanly for 3.8.8.

• Known-harmless build noise, not real failures:

  • namcap emits BSD is not a valid SPDX license identifier (E) — cosmetic, package still builds and installs fine.
  • In the 32-bit/pentium4 chroots, the post-build namcap/checkpkg step crashes with ImportError: libalpm.so.14: cannot open shared object file (chroot’s namcap python env vs host libalpm mismatch) and then error: target not found: libarchive-static — this is chroot tooling breakage, not a package build failure. Verify success by checking that libarchive-static-<ver>-<arch>.pkg.tar.xz was actually produced in the package directory instead of trusting the tail of archbuild’s output.

• 2026-07-07, private-repo release pass: this package’s .xz output (confirmed above, not new) tripped a real bug in repo_release.sh, which hardcoded a .pkg.tar.zst-only glob for the sign/publish steps — the build itself succeeded, but the script reported ERROR: no *.pkg.tar.zst found ... after build. Same issue hit pacman-static (see its own memory file), which explicitly sets PKGEXT=.pkg.tar.xz. Fixed by making repo_release.sh collect every valid package extension (.gz/.bz2/.xz/.zst/.lz), matching the set repo_build.sh’s own cleanup already recognized. Signed and published successfully afterward using the already-built .xz artifacts (no rebuild needed).

• 2026-07-17: ran a full update_cycle.sh pass. nvchecker-old.txt vs nvchecker-new.txt diff was empty — all bundled deps (attr, acl, openssl, zlib, xz, bzip2, zstd) still match their 2026-07-02 bump. No PKGBUILD change made. (Compare memory/pacman-static.md, whose otherwise-identical dep tracking showed one phantom c-ares bump this same cycle — not applicable here since this package doesn’t track c-ares at all.)

• 2026-07-28: 3.8.8 -> 3.8.9. Same procedure as 2026-07-02; deps diff again empty (nvchecker-deps.toml unchanged). updpkgsums only moved sha512sums[0]. Test-built cleanly for x86_64 via extra-x86_64-build before realizing the real release should go through repo_diff_local_remote.sh + repo_release_changed.sh per TOOLING_NOTES.md, not a manual archbuild/sign/publish chain — see that file’s 2026-07-27 entry, same mistake repeated. Cleaned up the manual test artifacts (built .pkg.tar.xz + debug pkg + namcap/build logs) and the updpkgsums-downloaded dep tarballs before handing off to the sanctioned scripts.

• 2026-08-27: bundled-dep check flagged ssl 3.6.3-1 -> 3.6.4-1 (same rotation as [[pacman-static]], see that file’s 2026-08-27 entry for the full OpenSSL new-release-key story — added B146647E45A7B33947AB226B2A2C87D161692D40 to validpgpkeys here too). pkgrel 1 -> 2. updpkgsums re-downloads every source, not just the changed one, and download.savannah.gnu.org (hosts both attr and acl, unrelated to this bump) was intermittently 502’ing/hanging that day — real server-side outage, not a local network issue (confirmed via curl -v: TLS handshake completes, then the request just hangs). Worked around it package-by-package:

  • attr-2.5.2.tar.xz (tarball only, .sig wasn’t needed — already cached from a prior fetch): pulled a byte-identical copy from the Wayback Machine (https://web.archive.org/web/2id_/<original-url> redirects to a snapshot) — verified sha512 matched the PKGBUILD’s existing checksum before using it.
  • acl-2.3.2.tar.gz + .sig: Wayback Machine had no snapshot of the .sig (CDX API query came back empty — small files are less reliably crawled). Used download-mirror.savannah.gnu.org instead of download.savannah.gnu.org — savannah documents this as a real mirror hostname, not a workaround; it was up and serving normally the whole time. Verified both the tarball’s sha512 against the PKGBUILD and gpg --verify on the .sig before trusting either.
  • General lesson: for a savannah.gnu.org outage affecting one project’s release host, try download-mirror.savannah.gnu.org first (same path structure, just a different frontend) before reaching for archive.org — it’s faster and more likely to have the signature file too.
  • Since only _sslver actually changed, manually patched just the openssl tarball’s sha512sums[7] entry by hand (copied the already-known-good hash from pacman-static’s own updated checksum, which had independently downloaded and hashed the same openssl-3.6.4.tar.gz) instead of re-running full updpkgsums once the savannah blocker made that impractical — avoids re-verifying unrelated sources whose checksums aren’t changing anyway.
  • Manually re-fetched attr/acl files kept as untracked source cache in the package dir afterward (same convention as this file’s existing zlib-caching note below), not cleaned up.
  • Built and published cleanly on all 4 archs once sources were in place, no other issues.

• 2026-08-13, republished for all architectures (user request, version unchanged at 3.8.9-1 — only x86_64 had ever actually been published before this). Built+published i486/i686/pentium4/x86_64 (arm/armv6h/armv7h/aarch64 always SKIPPED here, no local archbuild chroots for those). libarchive-static-debug builds and publishes alongside the main package on every arch.

  • Known flaky source: https://zlib.net/zlib-1.3.2.tar.gz intermittently times out (GET hangs past 20s; HEAD can succeed while GET doesn’t) even though the host has working internet otherwise — seen failing identically across all 4 local archs in the same run. If a build fails only on that download, don’t chase it as a PKGBUILD/toolchain bug: check /data/INSTALL/libarchive-static/ and /scratch/INSTALL/libarchive-static/ for a previously-fetched zlib-1.3.2.tar.gz + .tar.gz.asc (both present there as of 2026-08-13) and copy them into arch/maintained/libarchive-static/ before rebuilding — makepkg finds the file locally and skips the network fetch entirely. Normal source-cache placement in the package’s own dir, not a host-level workaround.

• 2026-08-27, first real armv6h/armv7h/aarch64 builds (new remote build machines eurobuild4/armv6h, eurobuild5/armv7h, eurobuild14/ aarch64 — see REMOTE_BUILD_DESIGN notes / config/remote_build.conf — replacing the always-SKIPPED fallback these archs got before). pkgrel 2 → 3, packaging-only:

  • armv7h (eurobuild5) and aarch64 (eurobuild14) built cleanly first try, once remote_build.sh was made to explicitly gpg --import every keys/pgp/*.asc before building — makepkg’s own automatic import from that same directory during PGP verification didn’t reliably trigger on these boards for a key never seen there before (the openssl 2026-05 release key added below), even though the .asc file was right there; a plain manual gpg --import of it worked immediately. Not package-specific — fixed once at the remote-build-agent level.
  • armv6h (eurobuild4) failed source validation instead: libarchive ... NOT FOUND / xz ... NOT FOUND for the two git+... sources during Validating source files with sha512sums. Root cause: eurobuild4 runs pacman 6.0.1 (long EOL — ArchLinux ARM dropped armv6h support entirely a while back, so this board can never be upgraded past it), which can’t compute a checksum for a git source at all and reports it as NOT FOUND rather than treating a real sha512sums entry as unhashable the way a plain SKIP would. x86_64/i686/pentium4 (local) and armv7h/ aarch64 (remote, newer pacman) all verify these same hashes fine.
  • Turned out there was already a dead attempt at exactly this fix in the PKGBUILD: if [ "${CARCH}" = "i486" ]; then sha512sums[6]= 'SKIP'; sha512sums[12]='SKIP'; fi with a # i486, shasumming git archives is broken? comment — but indices 6 and 12 are the acl.tar.gz.sig / zlib.tar.gz.asc signature files, which are already unconditionally SKIP a few lines up; it never touched index 0 (libarchive git source) or 13 (xz git source), the ones that actually needed it. Replaced with a case "${CARCH}" in i486|armv6h) block setting sha512sums[0] and sha512sums[13] to SKIP — verify the exact indices for any future edit to this array via makepkg --printsrcinfo | grep -n source (source and sha512sums entries share a 1:1 order, easy to miscount by hand across the source+=(...) brace-expansion blocks, which is exactly how the original dead attempt went wrong).
  • .SRCINFO always reflects the unconditional hashes (generated on this x86_64 host, doesn’t evaluate the case for other archs) — same as how the old i486 conditional already worked before this; not a new quirk.
  • Full release confirmed working end-to-end: pkgrel 2 → 3 (the sha512sums fix), scripts/repo_release.sh maintained/libarchive-static built+signed+published all 7 archs cleanly — i486/i686/pentium4/ x86_64 locally, armv6h/armv7h/aarch64 via the new remote-build pipeline (eurobuild4/5/14). armv6h was REUSED from an earlier isolated retest in this same session rather than rebuilt a third time (see [[remote_arm_build_machines]] / TOOLING_NOTES.md’s remote-build entry) — confirms the pkgver-pkgrel-arch reuse check in repo_build.sh works as intended. First-ever publish of armv6h/armv7h/aarch64 for this package (previously always SKIPPED, per the 2026-08-13 entry above).

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-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.