aurupdater

pacman-static

Build times (auto-updated)

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

Triggered by a real AUR comment (BrainwreckedTech, 2026-11-10: “zlib has been updated to v1.4 and v1.3.2 is no longer available (404 Not Found)”). 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 pass was the minimal fix: repoint the URL at fossils/, keep 1.3.2 and the local zlib-1.3.2-CVE-2026-85091.patch (see the 2026-10-14 entry below for that patch’s origin) untouched, pkgrel 26 -> 27. User then asked to check what Arch’s own zlib package is doing before settling. 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 history shows 1:1.3.2-4 (“Apply unreleased upstream patch for CVE-2026-85091”, 2026-10-12) -> 1:1.4-1 (2026-11-06, no patches at all), confirming 1.4 folds the fix in natively. Checked zlib.net’s own 1.4 release notes too: “Security fixes” section explicitly lists CVE-2026-85091 fixed. Note: pacman -Q zlib on this build host still showed 1.3.2-4 at the time – that’s just this machine not having synced yet, not evidence Arch stayed on 1.3.2; the packaging repo’s live PKGBUILD is the thing to check, not the locally installed version.

Given that, user asked to follow Arch’s lead instead of the minimal fix: _zlibver 1.3.2 -> 1.4, source URL back to plain zlib.net/zlib-${_zlibver}.tar.gz (1.4 is the current release, not under fossils/), dropped the zlib-1.3.2-CVE-2026-85091.patch source entry and its prepare() application step, deleted the now-unused patch file. New sha512sum cross-checked two ways before trusting it: matches the SHA-256 zlib.net publishes on its own download page, and independently recomputed from a fresh download.

Array-index gotcha, mirror image of the 2026-10-14 entry: removing the CVE-patch source entry shifts every later index back by one – the case "${CARCH}" in i486|armv6h) block’s overrides had to move sha512sums[15] (xz git) -> sha512sums[14] and sha512sums[28] (libseccomp git) -> sha512sums[27]. Verified via makepkg --printsrcinfo | awk '/^ source = /{print NR": "$0}' against the case-statement indices rather than counting by hand.

[libarchive-static] got the identical fix in the same session – same vendored-zlib pattern, same root cause, shorter source array so only one index (not two) needed adjusting there. zlib 1.4’s breaking changes are CMake/Windows/minizip- specific; nothing affects this package’s plain ./configure --static build.

Built+signed+published across all 7 archs afterward (ARM cluster confirmed up by the user) via repo_release.sh maintained/pacman-static.

2026-11-04: ARM catch-up to pkgrel 26

Ran the ARM archs deferred from the nghttp2 bump below: REPO_BUILD_ONLY_ARCH="armv6h armv7h aarch64" repo_release.sh maintained/pacman-static. armv6h/armv7h (eurobuild4/5) built and published cleanly first try. aarch64 (eurobuild14) failed with modprobe: FATAL: Module nbd not found in directory /lib/modules/7.3.0-1-aarch64-ARCH – the board was running kernel 7.3.0-1 while linux-aarch64 7.3.1-2 was already installed (confirmed via uname -r vs pacman -Q linux-aarch64 and /lib/modules/ only having a 7.3.1-2 dir), i.e. a pending-reboot situation, same symptom as the documented memory/TOOLING_NOTES.md entry for this exact board. User rebooted eurobuild14 directly; confirmed back up on 7.3.1-2 with modprobe nbd working, then retried REPO_BUILD_ONLY_ARCH=aarch64 alone – built and published cleanly. All 7 archs now at pkgrel 26.

Note: attempting the reboot myself via ssh build@eurobuild14 "sudo reboot" was blocked by the auto-mode safety classifier (remote reboot is treated as a risky action regardless of prior same-symptom precedent) – had to hand this one back to the user rather than running it directly.

2026-11-03: nghttp2 1.70.0 -> 1.71.0, Intel archs only (ARM deferred)

User asked specifically for the nghttp2 bump. _nghttp2_ver 1.70.0 -> 1.71.0 (matches official libnghttp2 1.71.0-1, confirmed via both pacman -Si and the archlinux.org JSON API), pkgrel 25 -> 26 (bundled-dep bump, pkgver itself untouched – same convention as the earlier curl bump). Updated the sha512sum for the new tarball directly (downloaded + sha512sum’d it, index 3 in sha512sums=(), the slot right after the 3 pacman-git-related source entries). Ran update_pgp_key_dir.sh first per the standing convention – all keys unchanged.

Built via REPO_BUILD_ONLY_ARCH="x86_64 i686 pentium4 i486" repo_release.sh – same reasoning as the curl bump: avoids kicking off the slow remote ARM builds automatically. All 4 Intel archs built, signed, and published cleanly first try (old pkgrel-25 artifacts correctly archived, not deleted). ARM (armv6h/armv7h/aarch64) deliberately left at pkgrel 25 for now, same catch-up pattern as before – do it once convenient, not urgent.

Caught a stale nvchecker reading mid-session: a concurrently-running full generate_overview.sh pass had written nvchecker-new.txt showing nghttp2 still at 1.70.0-1 even though archlinux.org had already synced to 1.71.0-1 a day earlier – a transient nvchecker flake, not a real discrepancy. Re-ran nvchecker -c nvchecker-deps.toml standalone afterward, got the correct 1.71.0-1 “updated” result, then cp nvchecker-new.txt nvchecker-old.txt to lock in the new baseline (only after the build+publish were confirmed successful) – so the next check_for_updates_maintained.sh run won’t re-report this same bump as pending. If a bundled-dep nvchecker check ever looks suspiciously unchanged right after a known upstream bump, rerun it standalone rather than trusting a reading taken while another generate_overview.sh gather pass was also hitting nvchecker.

Also noted: .SRCINFO ended up correctly in sync with the new PKGBUILD (pkgrel = 26, new nghttp2 source URL) by the time this was checked, but nothing in repo_build.sh/repo_build_staged.sh/repo_release.sh writes .SRCINFO back to the original arch/ location (confirmed by reading all of them) – so the mechanism that regenerated it this time is unexplained from the tooling side; possibly done by the user directly in parallel. Not chased further since the content was correct, but worth a second look if it ever happens again without an obvious explanation.

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)

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

2026-11-01: bundled libarchive 3.8.10 -> 3.8.11 (pkgrel 24 -> 25), to match libarchive-static’s real publish

Companion bump to [[libarchive-static]]’s own 3.8.11 republish (that package’s gate – .nvchecker-gate.toml – had just lifted once Arch’s core/libarchive caught up to 3.8.11). Bumped _libarchive_ver 3.8.10 -> 3.8.11 here too, pkgrel 24 -> 25 (plain integer – maintained/ + real content change, a packaging-only dep bump). updpkgsums touched only the one libarchive-3.8.11.tar.xz checksum, as expected. Built+signed+published cleanly across all 7 archs via MAKEFLAGS=-j6 repo_release.sh, launched right after libarchive-static’s own build finished (ran sequentially, not concurrently, to avoid colliding on the same local chroots/remote ARM boards). Confirmed published (7.1.0.r9.g54d9411-25) on all 7 via repo_arch_status.sh, no connection/mktemp errors. Total wall clock ~5h45m – longer than libarchive-static’s own ~3h40m run, since this package’s dependency chain is longer (nghttp2, curl, openssl, brotli, zlib, xz, bzip2, zstd, libarchive, gpg-error, libassuan, gpgme, libseccomp, then pacman itself) and armv6h is slow on all of them sequentially. Confirmed genuine progress partway through (not a hang) via pgrep -af makepkg + recent file mtimes on the board directly, same technique as libarchive-static’s entry above.

2026-10-25: brotli 1.2.0 -> 1.2.1 bump, i486 hang + corrupted shared VCS source cache

Routine bundled-dep bump (nvchecker-deps.toml flagged “brotli: updated from 1.2.0-1 to 1.2.1-1”), _brotliver + pkgrel 23->24, all 7 archs (user’s explicit choice over the usual Intel-then-ARM split). i486 build hung for ~1h48m with zero CPU activity: two pacman -S --needed --noconfirm namcap processes stuck inside the chroot (one in poll_schedule_timeout, one in futex_do_wait behind it), /var/lib/pacman/db.lck never released – almost certainly the same mirror.archlinux32.org flakiness documented in the 2026-10-17 curl entry above (a stuck TCP read that never times out, rather than an outright connection failure this time). machinectl terminate didn’t recognize the nspawn instance (started with --register=no) – had to kill -9 the process tree directly: the outer makechrootpkg/sudo wrapper, systemd-nspawn itself, AND its (sd-stubinit) child (the container’s own PID 1 under --as-pid2), which lingered briefly after nspawn died. repo_build.sh correctly marked i486 FAILED and moved on.

First-guessed cause, later corrected below: initially assumed killing i486’s hung build corrupted the shared VCS source cache for the brotli git source (/data/INSTALL/pacman-static/brotli, a bare clone reused across every local arch’s build of this package) – git fsck --full showed real error: Could not read <sha> entries (not just benign dangling commits), and i686/pentium4/x86_64 each then failed their own source-validation step with brotli ... FAILED (“One or more files did not pass the validity check”). Fixed in the moment by rm -rfing the corrupted bare clone (disposable cache, makepkg re-clones it fresh).

Dead-end theory, logged then disproven: the brotli ... FAILED error recurred on a completely fresh, non-interrupted retry (i486 built cleanly in 7m6s, i686/pentium4/x86_64 immediately failed again), and a git fsck --full on the bare clone right after that failure came back clean – at the time this read as “transient git-auto-gc racing the next arch’s fetch”, and gc.autoDetach false/gc.auto 0/ fetch.writeCommitGraph false were set on the bare clone as a guessed fix. That theory was wrong.

Real root cause: the committed PKGBUILD’s sha512sums entry for brotli (source+=("git+https://github.com/google/brotli#tag=v${_brotliver}")) was simply never updated when _brotliver was bumped 1.2.0 -> 1.2.1 – it still held the hash of the old tag’s content. makepkg -g recomputed fresh checksums for every source and only this ONE entry differed from what was committed; every other git-based source in this PKGBUILD (pacman itself, xz, libseccomp) matched exactly, confirming those really are stable/reproducible and this was an isolated miss, not a systemic VCS-checksum problem. Updated the entry to the freshly-computed hash (5b75c0bd67e47441aac8d8e67b4f2416f06c2f5e4fb09f1f213ccf313d00a9d08dfda42d59f5133884f980ea712509bbc6f26f4e942316352eb4150b2f16e964, replacing the stale 36b8fadb...), regenerated .SRCINFO. This also explains the live AUR comment from simona (2026-10-25 12:52, “brotli fail checksum”) against the officially published package – a separate, independent confirmation of the exact same stale hash, unrelated to this session’s local chroot/build activity.

Still genuinely puzzling: i486 (the first local arch to run each time) passed source validation both times before this fix, while i686/ pentium4/x86_64 (immediately after, same shared bare clone) failed with the stale hash every time – never fully explained, and moot now that the real hash is fixed, but worth remembering if a similarly order-dependent validation result shows up again on this package: don’t assume the first arch’s pass means the checksum is fine.

The 122d20e "updated brotli to 1.2.1" commit that introduced this (_brotliver/pkgrel only, no checksum update) was made directly by the user (Andreas Baumann, 2026-10-25 11:04 local time) in parallel with this session’s own identical, separately-applied (uncommitted) edit to the same two fields – not something this session committed; this session’s own rule is to never git commit/push. The checksum fix above is applied on top, uncommitted, same as usual – left for the user to commit.

i486/i686/pentium4/x86_64 all ended the first two runs FAILED or mixed (i486: a separate, unrelated chroot/pacman hang the very first time; i686/pentium4/x86_64: the stale brotli hash, both times) – remote ARM boards (armv6h/armv7h/aarch64) fetch their own sources independently per board, unaffected either way, built successfully both times. Still needs: a retry of REPO_BUILD_ONLY_ARCH="i486 i686 pentium4 x86_64" repo_release.sh maintained/pacman-static now that the real checksum fix is in place.

Resolved. The REPO_BUILD_ONLY_ARCH-limited retry above was itself aborted at the user’s request (user wanted a clean full restart rather than a partial-arch follow-up) – killed the in-flight armv6h remote build on eurobuild4 (its process tree: remote_build.sh -> makepkg -> cmake --build) and released both the board’s .building.lock and euronuc’s own /data/INSTALL/pacman-static/ .building.lock, then launched a fresh, full repo_release.sh maintained/pacman-static (all 7 archs) with the checksum fix already in place. All 7 archs built and published cleanly this time, pkgrel 24 confirmed via repo_arch_status.sh: i486 6m6s, i686 6m31s, pentium4 6m33s, x86_64 6m36s (all roughly back to the old ~6-14m baseline, well under the earlier 2h55m/hung figure), armv6h/armv7h/aarch64 unaffected throughout by any of this session’s local-side churn, as expected.

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

User-requested (“enqueue pacman-static for openssl update”), alongside the identical bump in [[libarchive-static]]. See that package’s memory for the shared investigation (confirmed _sslver=3.6.5 was already the newest 3.x release; the no-atomic patch and every Configure flag this PKGBUILD passes still work unmodified against the real 4.1.0 tarball; the release signature uses a subkey of the already-trusted primary key, no validpgpkeys change needed).

updpkgsums recomputed only the openssl tarball’s hash – every other bundled dependency (pacman itself, nghttp2, curl, brotli, zlib, xz, bzip2, zstd, libarchive, libgpg-error, libassuan, gpgme, libseccomp) matched exactly, confirming they’re genuinely unaffected.

Built all 7 archs. armv6h failed twice before succeeding, both non-package-related infra hiccups: first attempt hit a transient NBD-device setup error on eurobuild4 (“Error: Failed to setup device, check dmesg”) during the /data mount-check step – dmesg on the board confirmed /data (nbd0) actually mounted fine moments later, so this was a one-off reconnect race, not a real failure; retried clean. Second attempt failed purely from remote-board lock contention with libarchive-static’s own concurrent run on the same board (see [[remote_build_board_lock]] – fails closed by design); retried again once the board freed up and succeeded. Neither retry needed any package-level change. All 7 archs published 7.1.0.r9.g54d9411-28 cleanly, no connection failures in any of the logs.