linux-lts515

• Path: arch/maintained/linux-lts515

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.

• 2026-08-10: 5.15.213 -> 5.15.215, via update.sh 5.15.215. Tarball confirmed available on cdn.kernel.org before running (HTTP 200) – no 404 games this time. All 4 archs’ config diffs were cosmetic-only (just the # Linux/x86 5.15.213/215 Kernel Configuration header comment; no Kconfig changes), consistent with a point-release with no toolchain-visibility-gated option changes. Full builds (sudo extra-<arch>-build, no --nobuild) run detached in a screen session as usual. x86_64 and i686 built clean on the first pass. i486 and pentium4 both failed identically and immediately – not a package/build issue at all, just the chroot’s pacman -Sy step: error: failed retrieving file 'core.db' from mirror.archlinux32.org : SSL connection timeout (both core.db and extra.db). Confirmed via plain curl -sI that the mirror was reachable again a bit later; simply re-ran sudo extra-i486-build/sudo extra-pentium4-build standalone (no need to redo x86_64/i686) and both succeeded on the retry. i486/pentium4 apparently hit archlinux32.org for their chroot pacman sync (unlike x86_64/i686’s normal repos) – if this recurs, it’s that mirror specifically, not this host’s network. Signed+published all 12 files (3 pkgnames x 4 archs) via repo_sign.sh + repo_publish.sh directly (skipping repo_build.sh since already built, per the established recovery pattern – see 2026-08-02 entry below). Caution: accidentally invoked repo_publish.sh a second time on the same already-uploaded files out of habit/checking-exit-code muscle memory – turned out harmless (repo_publish.sh just replaces the same-version repo entry with itself, no duplicate ARCHIVED/db-entry mess), but don’t rely on that; just check the first run’s output instead of re-invoking.
• 2026-08-01: 5.15.212 -> 5.15.213, cosmetic-only config diffs (build timestamp/toolchain version strings), no Kconfig changes. Full build across all 4 archs succeeded and got signed, but repo_publish.sh lost its SSH connection to the repo host (euroweb.lan) partway through step 3/3 – host became fully unreachable (connection timed out) mid-run, not just one flaky request. Resulting remote state: linux-lts515 (main) published on all 4 archs OK. linux-lts515-docs published+repo-added on i486 only – i686/ pentium4/x86_64 never attempted. linux-lts515-headers never attempted at all (connection was already down by then). Local *.pkg.tar.zst/.sig for all 3 pkgnames x 4 archs are preserved (repo_release.sh’s cleanup only runs on success), so a plain rerun of scripts/repo_release.sh maintained/linux-lts515 once the host is reachable again should re-sign (harmless, already signed) and finish the publish/repo-add for the missing entries. No PKGBUILD changes needed, this was a pure infra outage.
• Recovering from the outage: do NOT just rerun scripts/repo_release.sh – repo_build.sh unconditionally reinvokes sudo <archbuild> per arch with no “already built” check, so it silently redoes the full kernel compile even when a valid signed package already sits in pkgdir (wasted ~1hr+ per arch, had to be killed mid-run). Instead, once local *.pkg.tar.zst/.sig already exist and are good, skip straight to scripts/repo_sign.sh <pkgdir>/*.pkg.tar.zst (no-ops, already signed) + scripts/repo_publish.sh <pkgdir>/*.pkg.tar.zst, then rm -f the local files manually (repo_release.sh’s own post-publish cleanup) – confirmed working 2026-08-02, all 12 files (3 pkgnames x 4 archs) published cleanly this way.
• .nvchecker.toml tracks the upstream git tag (linux-5.15.y branch, git.kernel.org/.../stable/linux.git), but the PKGBUILD source=() pulls a full release tarball from cdn.kernel.org/pub/linux/kernel/v5.x/linux-$pkgver.tar.xz. These two can go out of sync: a git tag can exist (so nvchecker reports UPD) before/without kernel.org publishing the corresponding release tarball. Confirm real availability with makepkg -do --skippgpcheck (unsandboxed); a genuine 404 means “not published yet” — revert the pkgver bump and retry later, don’t chase it further.
• 2026-07-25: 5.15.211 -> 5.15.212, full update+build+publish across all 4 archs (x86_64, i686, i486, pentium4). Found and fixed a real ordering bug in update.sh: it reconciled the shared config file in place for x86_64 first, but only updated PKGBUILD’s checksum for it after the whole arch loop finished. Since config (unlike config.i686/etc) is appended to every arch’s source list via source_i686/source_i486/ source_pentium4 (those arrays add the per-arch config, they don’t replace the shared config entry), the 32-bit archs’ makepkg --nobuild re-validated config’s checksum against the stale PKGBUILD entry after its content had already changed for x86_64, and failed with a checksum mismatch. Fix: move the main-config checksum update to run immediately after reconciling the x86_64 config, inside the loop, before moving to the next arch — see update.sh’s if [ "$arch" = "x86_64" ] block. Also confirmed a new (previously undocumented) harmless chroot noise: during each arch’s post-build test-install, the mkinitcpio pacman hook errors file not found: '/etc/vconsole.conf' and command failed to execute correctly — this is the chroot’s own test-install step, not the package build itself (which already succeeded by that point); same category as the pre-existing namcap/checkpkg noise below, don’t chase it.
• 2026-07-02: 5.15.210 tag existed but tarball 404’d, twice (checked same day). Reverted both times, no diff left behind.
• 2026-07-04: same pattern again — nvchecker/git tag reported 5.15.211, but update.sh 5.15.211 hit a real 404 on cdn.kernel.org for the release tarball. Script auto-reverted the pkgver bump on the 404 path, but left an empty src/ dir behind (its cleanup only runs after successful config reconciliation, not on this early-exit branch) — removed it manually. Package still at 5.15.210. Retry later.
• 2026-07-03: 5.15.210 tarball became available. Full update done — see update.sh in the package dir, which now automates this whole process. Key points from doing it manually first:
  • Never use updpkgsums on this package. Its sha256sums array has bespoke logic (the “fail if upstream’s .config changes” block, ~line
  229. that swaps in sha256sums_pentium4/i686/i486 only when the main config’s checksum matches a hardcoded literal duplicated in two places (the main array entry at index 2, and the if condition string). updpkgsums doesn’t know about this and will desync it. Compute checksums by hand with sha256sum and update both occurrences of the literal.
  • config, config.i686, config.i486, config.pentium4 need to be reconciled against the new kernel version with make olddefconfig (this is exactly what prepare() already does at build time — reuse it via makepkg --nobuild --skippgpcheck, don’t reinvent it).
  • Must run the reconciliation inside each architecture’s real archbuild chroot, not on the host: sudo extra-<arch>-build -- -- --nobuild --skippgpcheck (note: needs a double --, see memory/TOOLING_NOTES.md). The chroot’s actual installed gcc/binutils versions get embedded in the config (CONFIG_CC_VERSION_TEXT/CONFIG_AS_VERSION/CONFIG_LD_VERSION), and some Kconfig options are gated on toolchain capability (e.g. CONFIG_CC_HAS_KASAN_SW_TAGS disappeared for all three 32-bit subarchs in the 2026-07-03 update, because their chroot’s gcc 15.2.1 differs from x86_64 host/chroot’s gcc 16.1.1) — reconciling on the host would silently produce a wrong config for the 32-bit builds.
  • The reconciled .config ends up at /var/lib/archbuild/extra-<arch>/<user>/build/linux-lts515/src/linux-<ver>/.config after the --nobuild run; copy it back over the source config[.arch] file (needs sudo cp + chown back to your user).
  • Even when the diff is only the header comment/version strings (no Kconfig option changes), still persist it — user’s explicit preference, don’t skip “cosmetic-only” diffs. Applied this to the 64-bit config too even though its Kconfig content was unchanged.
  • pkgrel stays at 1 for a pkgver bump (this package always resets it).
  • Clean up leftover *-prepare.log, PKGBUILD-namcap.log, the downloaded tarball, and src/ after --nobuild runs — none of these should be left behind.
  • Full builds (sudo extra-<arch>-build, no --nobuild) take a while (kernel compile); run them detached (screen -dmS <name> ..., see memory/TOOLING_NOTES.md) if the session might end before they finish — a plain backgrounded shell command dies with the session (SIGHUP), a detached screen doesn’t.
  • Known-harmless chroot noise same as other packages: namcap crashes with ImportError: libalpm.so.14 inside the chroot’s python env, and checkpkg says “target not found” (no local repo) — neither means the build failed, verify via presence of the produced log/package instead.