libarchive-static

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