aurupdater

linux-lts515

Build times (auto-updated)

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.