chore(deps): update dependency kernel-longterm-6.18 to v6.18.52 - #178
Merged
Merged
Conversation
![renovate-hash-sync[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
Recomputed from a freshly-fetched artifact:
- driver/firmware/libchdr package pins: sha256sum of the github
archive tarball at the new pinned owner/repo/ref (same "locally
computed" practice this tree's own .hash file headers already
document)
- kernel pins (stable 6.18.y and the RT/beta 7.2 line): kernel.org's
signed sha256sums.asc for each pin's own vN.x series. An -rc is
never refreshed here -- no signed manifest exists for one
- ip7z/7zip pins (lzma-sdk, 7zip): sha256sum of the release
ASSET for the new version (upstream publishes no checksums at
all -- see package/lzma-sdk/lzma-sdk.hash's header), PLUS the
files each package's *_LICENSE_FILES names, hashed from that
same asset. A changed license file is refreshed AND diffed
into the step log with a ::warning:: -- read that diff before
merging; it is the only thing standing between an automated
hash refresh and a silent relicense
- sdcard payload pins (update_all.sh, wifi.sh): sha256 + size of
the raw file at the new pinned commit, rewritten in place in
scripts/fetch-sdcard-payload.sh
- Buildroot pin (BUILDROOT_SHA256, root Makefile): transcribed
from buildroot.org's GPG-signed release manifest
(buildroot-<ver>.tar.gz.sign) -- the same signed file `make
buildroot-showsig` prints, never a locally-computed sha256sum
of the tarball (that remains forbidden; see the Makefile's own
header comment)
- azcopy pin: REBUILT, not fetched. Buildroot's own
support/download/go-post-process re-ran `go mod vendor` over the
newly pinned tag with the Go version the pinned Buildroot tree
pins, and the resulting azcopy-<ver>-go2.tar.gz was hashed --
the only way this value can be derived, since no URL serves that
file (see package/azcopy/azcopy.hash's header). LICENSE and
NOTICE.txt were re-hashed from the same tarball
Contributor
Author
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
mcfbytes
added a commit
that referenced
this pull request
Sep 15, 2026
6.18.52 and 7.2.6 both carry the stable fix that deletes
ctlr->imu_timestamp_us += 1000 * ctlr->imu_avg_delta_ms;
from joycon_parse_imu_report(). That line was leading context in
0032's hid_warn_ratelimited -> hid_dbg hunk, so the hunk failed at
`patch -F0` on both Renovate bumps and took the whole build with it
(runs 34904210029 / PR #178, 34904230953 / PR #179).
The hunk's leading context is now the single
if (dropped_pkts > JC_IMU_DROPPED_PKT_WARNING) {
line, which reads the same before and after that fix. It has to: the
patch is one real file symlinked into linux-patches-beta/ and
de25nano/linux-patches/, and those pins move on separate Renovate
managers (6.18 vs kernel-rt-7.2), so a single copy must apply to both
the old and the new tree or whichever board is still on the old pin
breaks instead.
Verified by replaying each full series at Buildroot's own flags
(patch -F0 -g0 -p1 --no-backup-if-mismatch -t -N) against trees built
from the pinned tarballs plus the kernel.org incremental patches:
6.18.51 de10nano 38 patches 0 failed 13 offsets 0 fuzz
6.18.52 de10nano 38 patches 0 failed 19 offsets 0 fuzz
7.2.5 beta/RT 40 patches 0 failed 71 offsets 0 fuzz
7.2.6 beta/RT 40 patches 0 failed 74 offsets 0 fuzz
7.2.5 de25nano 34 patches 0 failed 68 offsets 0 fuzz
7.2.6 de25nano 34 patches 0 failed 71 offsets 0 fuzz
Offsets only, zero fuzz -- the standard docs/kernel-export.md already
records for this series. 0032 was the only failure on the bumped trees,
so nothing was hidden behind it. Output on the two current pins is
byte-identical to the pre-trim patch, and `git am` replay of all six
combinations is clean, so the export path is unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SCbqKSYnSe7R5WGFT6w4Rm
mcfbytes
added a commit
that referenced
this pull request
Sep 15, 2026
The 6.18.51 -> 6.18.52 bump (PR #178) turned CI red at `linux-tools`, ~31 minutes in, with a perf compile error that looks like our bug and is not one: builtin-annotate.c:523:31: error: too few arguments to function 'hist_entry__tui_annotate'; expected 4, have 3 6.18.52 cherry-picked e97bd4417010 ("perf annotate: Fix build with NO_SLANG=1") but not the commit it repairs, mainline ad83f3b7155db28e ("perf c2c annotate: Start from the contention line"). That commit is what gives the TUI annotate entry points their `u64 al_addr` parameter -- on the HAVE_SLANG_SUPPORT prototypes, on the real definitions in ui/browsers/annotate.c, and at every call site -- and what puts `#define NO_ADDR 0` inside that #ifdef. The fix moves the #define out and adds `al_addr` to the two `#else` inline stubs. With only the fix applied the move has nothing to move, and those two stubs become the sole things in the whole tree that believe in `al_addr`: `grep -rn NO_ADDR tools/` on 6.18.52 returns exactly one line, the macro's own definition. Beware the Fixes: line when re-deriving this. It names cd3466cd2639783d ("perf c2c: Add annotation support to perf c2c report"), which does not touch hist.h at all -- two files, Documentation/perf-c2c.txt and builtin-c2c.c, and the one annotate call it adds is the three-argument form. The skip is narrower and stranger than the tag suggests: 6.18.y took f06ba25ec54a ("perf annotate: Rename to __hist_entry__tui_annotate()"), the commit immediately BEFORE ad83f3b7, and e97bd4417010, the commit immediately after -- the one before and the one after, missing only the middle. That breaks every NO_SLANG=1 build of perf, which is the only kind this image does: package/linux-tools/linux-tool-perf.mk.in:68 forces NO_NEWT=1 NO_SLANG=1 whenever BR2_PACKAGE_LINUX_TOOLS_PERF_TUI is unset, and it is unset here (enabling it would pull slang into the target for a TUI nothing on a MiSTer uses). BR2_PACKAGE_LINUX_TOOLS_PERF is selected unconditionally by package/mister-userspace/Config.in, so it fails `make all` outright rather than skipping an optional leg. So 0051 reverts that one stable commit for the 6.18 series. The patched tools/perf/util/hist.h is byte-identical to pristine v6.18.51's -- the arity CI built green on every run up to the bump -- and the alternative repair (backporting ad83f3b7, 55 insertions, plus the c2c feature commit its builtin-c2c.c hunks build on, 157 more, into a stable tree that took neither) is strictly worse. Verified, not inferred: - applies to pristine 6.18.52 at -F0, zero fuzz, zero offset; the result diffs empty against pristine v6.18.51's hist.h; - the CI failure REPRODUCED on a host build of the pristine tree with Buildroot's own perf flag set (same file, same line, same message, make exit 2), and with 0051 applied the same command reaches "LINK perf", exit 0; - fails closed on 7.x: at -F0 against pristine v7.2.6, "Hunk #1 FAILED at 700. Hunk #2 succeeded at 741 (offset 2 lines). 1 out of 2 hunks FAILED", exit 1; - lint-kernel-patches.sh 47/47, check-defconfigs.sh OK. It will NOT self-heal at 6.18.53: linux-6.18.y HEAD still has NO_ADDR at hist.h:712, al_addr on the stubs at :752/:760, and the three-argument call at builtin-annotate.c:523, and nothing in stable-queue's queue-6.18 (567 patches) touches perf annotate, c2c or hist.h. Expected -- distros build perf WITH slang, so only NO_SLANG=1 consumers compile the broken branch at all. The hunks are generated at -U12 on purpose, which is the opposite of 449ce9a ("kernel: trim patch 0032 context so it survives the 6.18.52 / 7.2.6 bumps") and deliberately so: 0032 is meant to survive bumps, 0051 is meant to die at the right one. The wide context pulls the HAVE_SLANG_SUPPORT prototypes into hunk 1, so the day 6.18.y repairs itself -- by taking ad83f3b7, by reverting e97bd4417010, or by the pin leaving 6.18.y -- this patch stops applying and CI names the file in the linux-patch step, instead of applying cleanly and failing twenty minutes later as a compile error nobody connects to it. When that happens the answer is DELETE, never re-anchor; re-anchoring would re-break the build. 0051 is the third shared patch the beta/DE25 series omit, and the first omitted because 7.x was never broken: 0047 is excluded because 7.x has the same mainline commit, 0050 because 7.x has mainline's own different fix, 0051 because 7.x took both halves and is self-consistent, so the revert would break a correct tree rather than no-op. Series header, rt-beta-kernel.md, the DE25 README, buildroot-config.md, README.md and patch-provenance.md updated to match (38 shared patches -> 39; the beta series stays at 40 entries). Not a fork-sync item, so no docs/kernel-recon/records/ entry: this is a linux-6.18.y stable defect, not a MiSTer fork commit. Worth reporting to stable@vger.kernel.org, but not sent -- that is an owner decision like every other outbound contribution here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M28mp7rtZJQov3ZEvHy4jJ
mcfbytes
added a commit
that referenced
this pull request
Sep 16, 2026
6.18.52 and 7.2.6 both carry the stable fix that deletes
ctlr->imu_timestamp_us += 1000 * ctlr->imu_avg_delta_ms;
from joycon_parse_imu_report(). That line was leading context in
0032's hid_warn_ratelimited -> hid_dbg hunk, so the hunk failed at
`patch -F0` on both Renovate bumps and took the whole build with it
(runs 34904210029 / PR #178, 34904230953 / PR #179).
The hunk's leading context is now the single
if (dropped_pkts > JC_IMU_DROPPED_PKT_WARNING) {
line, which reads the same before and after that fix. It has to: the
patch is one real file symlinked into linux-patches-beta/ and
de25nano/linux-patches/, and those pins move on separate Renovate
managers (6.18 vs kernel-rt-7.2), so a single copy must apply to both
the old and the new tree or whichever board is still on the old pin
breaks instead.
Verified by replaying each full series at Buildroot's own flags
(patch -F0 -g0 -p1 --no-backup-if-mismatch -t -N) against trees built
from the pinned tarballs plus the kernel.org incremental patches:
6.18.51 de10nano 38 patches 0 failed 13 offsets 0 fuzz
6.18.52 de10nano 38 patches 0 failed 19 offsets 0 fuzz
7.2.5 beta/RT 40 patches 0 failed 71 offsets 0 fuzz
7.2.6 beta/RT 40 patches 0 failed 74 offsets 0 fuzz
7.2.5 de25nano 34 patches 0 failed 68 offsets 0 fuzz
7.2.6 de25nano 34 patches 0 failed 71 offsets 0 fuzz
Offsets only, zero fuzz -- the standard docs/kernel-export.md already
records for this series. 0032 was the only failure on the bumped trees,
so nothing was hidden behind it. Output on the two current pins is
byte-identical to the pre-trim patch, and `git am` replay of all six
combinations is clean, so the export path is unaffected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SCbqKSYnSe7R5WGFT6w4Rm
mcfbytes
added a commit
that referenced
this pull request
Sep 16, 2026
chore(deps): update dependency kernel-longterm-6.18 to v6.18.52
mcfbytes
added a commit
that referenced
this pull request
Sep 16, 2026
The 6.18.51 -> 6.18.52 bump (PR #178) turned CI red at `linux-tools`, ~31 minutes in, with a perf compile error that looks like our bug and is not one: builtin-annotate.c:523:31: error: too few arguments to function 'hist_entry__tui_annotate'; expected 4, have 3 6.18.52 cherry-picked e97bd4417010 ("perf annotate: Fix build with NO_SLANG=1") but not the commit it repairs, mainline ad83f3b7155db28e ("perf c2c annotate: Start from the contention line"). That commit is what gives the TUI annotate entry points their `u64 al_addr` parameter -- on the HAVE_SLANG_SUPPORT prototypes, on the real definitions in ui/browsers/annotate.c, and at every call site -- and what puts `#define NO_ADDR 0` inside that #ifdef. The fix moves the #define out and adds `al_addr` to the two `#else` inline stubs. With only the fix applied the move has nothing to move, and those two stubs become the sole things in the whole tree that believe in `al_addr`: `grep -rn NO_ADDR tools/` on 6.18.52 returns exactly one line, the macro's own definition. Beware the Fixes: line when re-deriving this. It names cd3466cd2639783d ("perf c2c: Add annotation support to perf c2c report"), which does not touch hist.h at all -- two files, Documentation/perf-c2c.txt and builtin-c2c.c, and the one annotate call it adds is the three-argument form. The skip is narrower and stranger than the tag suggests: 6.18.y took f06ba25ec54a ("perf annotate: Rename to __hist_entry__tui_annotate()"), the commit immediately BEFORE ad83f3b7, and e97bd4417010, the commit immediately after -- the one before and the one after, missing only the middle. That breaks every NO_SLANG=1 build of perf, which is the only kind this image does: package/linux-tools/linux-tool-perf.mk.in:68 forces NO_NEWT=1 NO_SLANG=1 whenever BR2_PACKAGE_LINUX_TOOLS_PERF_TUI is unset, and it is unset here (enabling it would pull slang into the target for a TUI nothing on a MiSTer uses). BR2_PACKAGE_LINUX_TOOLS_PERF is selected unconditionally by package/mister-userspace/Config.in, so it fails `make all` outright rather than skipping an optional leg. So 0051 reverts that one stable commit for the 6.18 series. The patched tools/perf/util/hist.h is byte-identical to pristine v6.18.51's -- the arity CI built green on every run up to the bump -- and the alternative repair (backporting ad83f3b7, 55 insertions, plus the c2c feature commit its builtin-c2c.c hunks build on, 157 more, into a stable tree that took neither) is strictly worse. Verified, not inferred: - applies to pristine 6.18.52 at -F0, zero fuzz, zero offset; the result diffs empty against pristine v6.18.51's hist.h; - the CI failure REPRODUCED on a host build of the pristine tree with Buildroot's own perf flag set (same file, same line, same message, make exit 2), and with 0051 applied the same command reaches "LINK perf", exit 0; - fails closed on 7.x: at -F0 against pristine v7.2.6, "Hunk #1 FAILED at 700. Hunk #2 succeeded at 741 (offset 2 lines). 1 out of 2 hunks FAILED", exit 1; - lint-kernel-patches.sh 47/47, check-defconfigs.sh OK. It will NOT self-heal at 6.18.53: linux-6.18.y HEAD still has NO_ADDR at hist.h:712, al_addr on the stubs at :752/:760, and the three-argument call at builtin-annotate.c:523, and nothing in stable-queue's queue-6.18 (567 patches) touches perf annotate, c2c or hist.h. Expected -- distros build perf WITH slang, so only NO_SLANG=1 consumers compile the broken branch at all. The hunks are generated at -U12 on purpose, which is the opposite of 129b7eb ("kernel: trim patch 0032 context so it survives the 6.18.52 / 7.2.6 bumps") and deliberately so: 0032 is meant to survive bumps, 0051 is meant to die at the right one. The wide context pulls the HAVE_SLANG_SUPPORT prototypes into hunk 1, so the day 6.18.y repairs itself -- by taking ad83f3b7, by reverting e97bd4417010, or by the pin leaving 6.18.y -- this patch stops applying and CI names the file in the linux-patch step, instead of applying cleanly and failing twenty minutes later as a compile error nobody connects to it. When that happens the answer is DELETE, never re-anchor; re-anchoring would re-break the build. 0051 is the third shared patch the beta/DE25 series omit, and the first omitted because 7.x was never broken: 0047 is excluded because 7.x has the same mainline commit, 0050 because 7.x has mainline's own different fix, 0051 because 7.x took both halves and is self-consistent, so the revert would break a correct tree rather than no-op. Series header, rt-beta-kernel.md, the DE25 README, buildroot-config.md, README.md and patch-provenance.md updated to match (38 shared patches -> 39; the beta series stays at 40 entries). Not a fork-sync item, so no docs/kernel-recon/records/ entry: this is a linux-6.18.y stable defect, not a MiSTer fork commit. Worth reporting to stable@vger.kernel.org, but not sent -- that is an owner decision like every other outbound contribution here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M28mp7rtZJQov3ZEvHy4jJ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
6.18.51→6.18.52Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.