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