aurupdater

linux-lts515

Build times (auto-updated)

2026-09-15/16: 5.15.220 -> 5.15.221, update.sh interrupted by a 10-minute command timeout, resumed by hand; full x86_64/pentium4/i686/i486 MAKEFLAGS=-j6 baseline

Routine point release, tarball confirmed on cdn.kernel.org (HTTP 200) before running update.sh 5.15.221. That script itself got killed by an unrelated 10-minute shell-command timeout partway through the per-arch config-reconciliation loop – x86_64/i686/i486 had already completed (each leaves behind a <pkg>-prepare.log, a cheap way to tell), pentium4 hadn’t started yet. Since update.sh short-circuits immediately if pkgver already matches its argument (see its own OLDVER = NEWVER guard), simply rerunning it would have skipped straight past the reconciliation entirely rather than resuming – finished the remaining steps by hand instead: sudo extra-pentium4-build -- -- --nobuild --skippgpcheck, copied the reconciled .config over config.pentium4 (cosmetic-only diff, same as the other three archs), then replicated the script’s own tail end (log/tarball/src cleanup, sha256sums_pentium4/i686/i486 update via the same sed patterns, .SRCINFO regen). pkgrel stayed at 1 as always for a pkgver bump.

Built+published via repo_release.sh with MAKEFLAGS=-j6 applied to every local arch this time (previous entries below only had it for the archs still running after the feature landed mid-session) – first real end-to-end timing baseline for all four at once: x86_64 2h3m, pentium4 2h21m, i686 2h23m, i486 2h31m (see the auto-updated block above) – x86_64 alone dropped from the old 4h10m serial baseline to 2h3m, confirming the parallelism actually helps that arch too, not just the 32-bit ones. All 12 files (3 pkgnames x 4 archs) uploaded cleanly – confirmed via a full log grep for connection-reset/broken-pipe/etc. (none) and repo_arch_status.sh showing all 4 archs published (5.15.221-1) directly against the remote repo.

repo_build.sh was edited on disk (adding the new persistent build-status instrumentation for the site’s “Currently Building” page) while this exact build’s x86_64 phase was already running under it. Confirmed harmless to the build itself (progressed normally throughout), but the entire invocation – not just x86_64, all the way through pentium4/i686/i486 too – kept running the pre-edit code for its whole ~8.5h lifetime (an already-open script fd doesn’t see edits to the path made after it opened, no matter how many loop iterations are still ahead of it). So none of this build’s four archs ever got a build-status entry; the instrumentation only takes effect on a fresh repo_build.sh invocation started after the edit. See memory/TOOLING_NOTES.md’s 2026-09-15/16 entry for the full story.

2026-09-04/05: 5.15.219 -> 5.15.220, first build using MAKEFLAGS parallelism + a mid-run resume

Routine point release via update.sh 5.15.220, tarball confirmed on cdn.kernel.org first. All 4 archs’ config diffs cosmetic-only (just the version header comment), same pattern as every prior point release. pkgrel stayed at 1.

Unusual build cycle: this was the first real-world use of two new features added mid-session (see the project’s own memory/ TOOLING_NOTES.md for full detail) – per-arch build-time recording and an opt-in MAKEFLAGS parallelism override for local chroot builds. x86_64 was already mid-build (serial, ~4h in) when both features landed, so it finished the old way (4h10m, no parallelism label). To still benefit the remaining 3 archs without wasting the x86_64 progress already sunk, repo_release.sh’s run was killed cleanly right at the x86_64 -> pentium4 boundary (SIGTERM to the nspawn process, then SIGKILL the whole process group; no stale mounts, no orphaned processes) and resumed as MAKEFLAGS="-j6" REPO_BUILD_ONLY_ARCH="pentium4 i686 i486" repo_build.sh /data/INSTALL/linux-lts515 – calling repo_build.sh directly, not via repo_build_staged.sh, since that wrapper unconditionally deletes every *.pkg.tar.* in the staging dir at the start of each invocation (would have destroyed the already-built x86_64 package). Artifacts were then copied back into this dir by hand and signed/published the same way repo_release.sh normally would.

The MAKEFLAGS mechanism needed a real fix mid-flight: the first resume attempt silently built pentium4 at -j1 anyway – sudo --preserve-env=MAKEFLAGS alone wasn’t enough, because makechrootpkg’s own load_makepkg_config() re-sources the host’s /etc/makepkg.conf internally and doesn’t preserve MAKEFLAGS across that reload. Caught by grepping the live chroot’s actual baked /etc/makepkg.conf, not by trusting the sudo/printenv chain. Fixed by having repo_build.sh generate a scratch copy of the host’s makepkg.conf with MAKEFLAGS commented out and pointing load_makepkg_config’s own MAKEPKG_CONF override at it – confirmed working afterward (chroot showed MAKEFLAGS='-j6', and multiple concurrent cc1 processes observed live). That pentium4 attempt was killed and restarted once fixed, so the recorded pentium4/i686/i486 times below are all genuinely at -j6, not a mix.

Net effect vs. an all-serial run: pentium4/i686/i486 each took ~2.5-3h at -j6 instead of a presumably-similar-to-x86_64 multi-hour serial time each – a real, if unquantified (no serial baseline exists for these archs at this kernel version), speedup. All 12 files (3 pkgnames x 4 archs) verified published via direct remote ls, no connection-failure strings in the full log.

2026-08-29/30: 5.15.217 -> 5.15.219

Routine point release via update.sh 5.15.219, tarball confirmed on cdn.kernel.org first. All 4 archs’ config diffs cosmetic-only (just the version header comment). pkgrel stayed at 1 as usual. Built staged via repo_release.sh (multi-hour wall clock as usual, x86_64 alone taking most of it). All 12 files (3 pkgnames x 4 archs) built, signed, and published cleanly – confirmed both via a full-log grep for connection-failure strings (none found, unlike the 2026-08-24 entry below) and directly via repo_arch_status.sh, all 4 archs showing published (5.15.219-1).

Saw three categories of scary-looking but harmless “Error”/"error” lines in the log, all from the post-build checkpkg/namcap steps, not the real package() step: (1) namcap’s own “Checking PKGBUILD” linter apparently runs the PKGBUILD in some minimal env lacking date/grep in PATH, producing PKGBUILD: line 41: date: command not found / “is not a valid PKGBUILD” – but the actual built linux-lts515-5.15.219-1-x86_64.pkg.tar.zst gets checked right after with the correct version, so the real package was fine; (2) mkinitcpio warning “errors were encountered during the build. The image may not be complete” / “error: command failed to execute correctly” during checkpkg’s post-install initramfs regeneration, three times (once per additional local arch) – expected in a disposable build chroot missing a proper /boot setup, not a real package defect.

2026-08-24: 5.15.216 -> 5.15.217

Routine point release via update.sh 5.15.217, tarball confirmed on cdn.kernel.org first. Unlike most recent point releases, this one had a real (non-cosmetic) Kconfig change on the 32-bit archs, not just the header-comment/toolchain-version diff: CONFIG_CAN_ESD_USB2=m -> commented out (# CONFIG_CAN_ESD_USB is not set) on config.pentium4 (and presumably i686/i486 too, same config lineage). pkgrel stayed at 1 as usual for a pkgver bump. Built via repo_release.sh (repo_build_staged.sh staged it under /data/INSTALL/linux-lts515 as normal) across all 4 archs, all 12 files (3 pkgnames x 4 archs) built, signed, and published with no failures. x86_64 alone took a genuinely long time (multi-hour wall clock, mostly module compilation) — confirm real progress via the live build log under /var/lib/archbuild/archlinuxaba-x86_64/build/logdest/ and active cc1/make processes before assuming a long-running build is stuck.

Mid-run SSH outage to the repo host, same failure mode as the 2026-08-01 entry below — euroweb.lan dropped the connection partway through repo_publish.sh (Connection reset by peer / Broken pipe / then ssh: connect ... Connection refused for everything after). Only 5 of 12 files (main pkg x4 archs + docs-i486) got uploaded before the drop; linux-lts515-docs for i686/pentium4/x86_64 and all of linux-lts515-headers were still missing. A grep limited to SIGNED/UPLOADED/ARCHIVED/FAILED does not catch this — those lines all look normal, the failure only shows up as Connection reset/Broken pipe/Connection refused/ rsync error further down the same log, and the overall backgrounded command’s reported exit code was still 0. Always grep a repo-publish log for those connection-failure strings specifically, and/or verify the actual remote directory listing (repo_ssh "ls \"\${REPOSITORY_REMOTE_PATH}/os/<arch>/\"") before declaring a publish done, not just the tail of the log. Recovery: once the host answered ping/ssh again, no rebuild needed — the local .pkg.tar.zst/.sig for the missing files were already good, so re-ran repo_publish.sh directly on just those 7 files, then confirmed via remote ls that no 5.15.216 entries remained anywhere before cleaning up the local copies by hand (repo_release.sh’s own cleanup only fires on its exit code, which had already been consumed/misread once here too).

2026-08-21: 5.15.215 -> 5.15.216, plus a staging-recovery precedent

Routine point release, tarball confirmed on cdn.kernel.org before running. update.sh 5.15.216 reconciled all 4 archs’ configs (x86_64/i686/i486/pentium4) cleanly – every diff was cosmetic-only (just the # Linux/x86 5.15.215/216 Kernel Configuration header comment), same pattern as every prior point-release update here.

Built the wrong way first: ran build_all_archs.sh directly inside this arch/maintained/linux-lts515 package dir (in-place) instead of starting with repo_release.sh/repo_build_staged.sh, which stage the build under /data/INSTALL/linux-lts515 instead. By the time this was caught the x86_64 compile was already well underway, so rather than kill it and restart staged, let it finish (all 4 archs, all 12 files – 3 pkgnames x 4 archs – built successfully), then recovered by migrating the result into the layout repo_build_staged.sh would have produced:

  1. The existing /data/INSTALL/linux-lts515 was stale anyway (last touched 2026-07-05, still at 5.15.211 – three point releases behind). Moved it aside to /data/INSTALL/linux-lts515-old rather than overwriting it, following the same rotation convention already used for linux-lts510 (-old/-older/-oldest).
  2. rsync -a --exclude=.git from arch/maintained/linux-lts515/ into a fresh /data/INSTALL/linux-lts515/ – carries tracked PKGBUILD/patches/configs/keys and the untracked build byproducts (downloaded tarball, the 12 produced *.pkg.tar.zst, per-arch build/package/namcap logs) together.
  3. git clean -fd inside arch/maintained/linux-lts515 to drop every untracked byproduct, restoring the tracked tree to exactly its pre-build state (verified via git status --short – clean).
  4. Signed (repo_sign.sh) + published (repo_publish.sh) all 12 files straight from the /data/INSTALL/linux-lts515 copy. All uploaded cleanly; old 5.15.215 entries archived per-arch as usual.
  5. Left the downloaded tarball/logs sitting in /data/INSTALL/linux-lts515 afterward rather than trying to clean them out by hand – confirmed that staged dir has no working .git (rsync excludes it), so repo_build.sh’s own post-build cleanup (which is driven by git status --porcelain) would silently no-op there too even in the normal staged flow. Matches the untouched state the old -old dir was already in from 2026-07-05.

Generalized this 5-step recovery into memory/TOOLING_NOTES.md (search “Recovering an in-place build”) for any future package caught mid-build in place instead of staged.