aurupdater

linux-lts515

Build times (auto-updated)

2026-10-17: 5.15.222 -> 5.15.223, mirror outages on both i686 and i486

Routine point release, tarball confirmed on cdn.kernel.org first. Ran scripts/update_pgp_key_dir.sh (Greg KH key unchanged). All 4 archs’ config diffs cosmetic-only (just the version header comment), same pattern as every prior point release.

update.sh 5.15.223 itself aborted partway through – i686’s chroot pacman sync hit mirror.archlinux32.org connection timeouts (host-level outage, confirmed via a plain curl from outside the chroot too, not just inside it). Since update.sh short-circuits on OLDVER = NEWVER (pkgver was already bumped to 5.15.223 before the per-arch loop even starts), a plain rerun once the mirror recovered would have skipped reconciliation entirely – same resume-by-hand situation as the 2026-09-15/16 entry below. Finished i686/i486/ pentium4 manually: sudo extra-<arch>-build -- -- --nobuild --skippgpcheck, copied each .config back, then replicated update.sh’s own tail end (per-arch sha256sums_* update, .SRCINFO regen, log/tarball/src cleanup). All three diffs cosmetic-only, matching x86_64.

The real build then hit the same mirror flakiness twice more, this time during the actual extra-<arch>-build package syncs, not just --nobuild reconciliation: first pass built x86_64+pentium4 fine but i686 failed the chroot’s pacman -Sy (repo_build.sh’s arch loop stops at the first failure and never attempts the archs after it in arch=() order – i486 was never even attempted that first pass, not just i686). Resumed with REPO_BUILD_ONLY_ARCH="i686 i486" once the mirror answered again – i686 succeeded, but i486 hit the same mirror error again on that same run and had to be resumed a second time with REPO_BUILD_ONLY_ARCH="i486" alone. Confirmed via repo_arch_status.sh all 4 archs published (5.15.223-1) and a full-log grep for connection-reset/broken-pipe (none) each time.

Each mirror-outage check used a plain curl -s -o /dev/null -w '%{http_code}' against mirror.archlinux32.org directly (not through a chroot) before retrying – faster signal than waiting for extra-i686-build to fail again, and a background Monitor polling loop (60s interval) was used to wait for the mirror’s HTTP 200 rather than manually re-checking. i486’s build this time (2h24m) ran noticeably longer than its usual ~1h28m baseline – partly the repeated failed mirror-sync attempts counted into wall clock, and it also ran concurrently with a pacman-static rebuild sharing the same local archbuild host, so some of the slowdown may be CPU contention between the two rather than the kernel build itself being slower.

Build times (auto-updated)

2026-10-07: user confirms 5.15.222 boots fine – 221 boot regression resolved

User tested 5.15.222 directly (“5.15.222 works now”) – boots cleanly, unlike 5.15.221’s “fails to mount root, drops to emergency shell” regression (own AUR comment 2026-09-24, void-packages#62643). This is despite the 2026-10-04 entry below finding no ext4/mount-related commits in 5.15.222’s changelog, so the fix (if any) wasn’t identified via changelog inspection – either the suspected 7461c60b9c6a theory was wrong, some other change incidentally fixed it, or it was environment-specific to begin with. Don’t chase the root cause further now that it’s confirmed working.

Own AUR comment from 2026-09-24 (“Stick to 5.15.220”) is now stale – worth a follow-up AUR reply noting 5.15.222 resolves it, but posting is a user action (this pipeline is read-only against AUR, see check_aur_feedback.sh’s own docstring) – flagged to the user, not posted automatically.

2026-10-04: 5.15.221 -> 5.15.222, checked whether it fixes the 221 boot regression (it doesn’t appear to)

Routine point release, update.sh 5.15.222 run detached (4 sequential chroot --nobuild reconciliations). All 4 archs’ config diffs were effectively cosmetic: just the version header comment plus CONFIG_PAHOLE_VERSION=131 -> 132 (a toolchain version string, not a real feature/behavior Kconfig change) on the main config. pkgrel stayed at 1 as always for a pkgver bump. Ran scripts/update_pgp_key_dir.sh first (one key, Greg KH’s, unchanged).

Before bumping, checked the upstream 5.15.222 changelog (cdn.kernel.org/…/ChangeLog-5.15.222) specifically for the ext4 mount-path commit (7461c60b9c6a) suspected in the 2026-10-03 entry below of causing the 5.15.221 “fails to mount root, drops to emergency shell” regression (our own AUR comment 2026-09-24; also void-packages#62643). No ext4 or mount-related commits appear in 5.15.222’s changelog at all – this release is security/driver fixes (eventpoll UAF, Bluetooth, netfilter, NFC, etc.), unrelated to the suspected commit. So there is no reason to expect this point release resolves that regression; it most likely still carries the same bug forward. Proceeded with the update anyway per explicit user request (“at least a new linux-lts515 kernel should be out worth building and publishing”) – this is a routine version-bump update each cycle regardless, not a signal the regression is fixed. If another “fails to boot” report comes in against 5.15.222, don’t re-investigate the root cause from scratch – it’s almost certainly the same 7461c60b9c6a-era issue carried over, see the 2026-10-03 entry below for the existing analysis.

Built+published via MAKEFLAGS=-j6 scripts/repo_release.sh maintained/linux-lts515 (detached via nohup, long multi-arch build). See build-times block above for per-arch timing once this run completes.

2026-10-03: researching the 5.15.221 boot-failure report (own AUR comment, 2026-09-24)

Own AUR comment (“Every machine I boot on I fail to boot beyond the RAMdisk (root device or root partition not mountable). Stick to 5.15.220.”) is still the only report in our FEEDBACK.txt, unanswered by anyone else since. Checked upstream for a fix before touching anything:

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.