linux: remove two patch files that are not in the series - #328
Merged
Conversation
build/meta-linux/recipes-linux/linux/files/0001-linux-6.12-r0/ holds
eight .patch files, but 0001-linux-6.12-r0-patches.inc references only
six. The two extras are never applied by bitbake — they just sit there
looking like part of the boot path, which is how they cost me a debugging
detour: reading the guest DT, the obvious file to trust is the
higher-numbered one.
Neither carries anything the live series does not:
0022-virt64.dts.patch body byte-identical to the live 0004.
A pure duplicate.
0023-virt64_guest.dts.patch identical to the live 0002 except for the
CMA size — 0x6000000 (96 MB) where 0002
has 0xa000000 (160 MB). A stale revision
from before that bump.
Both carry `--- a/<path>` headers where their live counterparts create
the file from /dev/null, which points at an updiff run that regenerated
the set without replacing it. (0004's own header still names an absolute
path inside an infrabase build tree, from the same era.)
No functional change: the .inc is untouched, so exactly the same six
patches are applied before and after. Verified that nothing else in the
tree references either filename, and that the rpi4 series is clean
(17 files, 17 entries).
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.
build/meta-linux/recipes-linux/linux/files/0001-linux-6.12-r0/holds eight.patchfiles, but0001-linux-6.12-r0-patches.increferences only six. The two extras are never applied by bitbake — they just sit there looking like part of the boot path, which is exactly how they cost me a debugging detour: reading the guest DT, the obvious file to trust is the higher-numbered one.Neither carries anything the live series does not:
0022-virt64.dts.patch0004. A pure duplicate.0023-virt64_guest.dts.patch0002except the CMA size —0x6000000(96 MB) where0002has0xa000000(160 MB). A stale revision from before that bump.Both carry
--- a/<path>headers where their live counterparts create the file from/dev/null, which points at an updiff run that regenerated the set without replacing it. (0004's own header still names an absolute path inside an infrabase build tree, from the same era — not fixed here.)No functional change
The
.incis untouched, so exactly the same six patches are applied before and after. Verified that nothing else in the tree references either filename, and that the rpi4 series is clean (17 files, 17 entries).Companion to #327, which fixes the content of the live guest DT; this one only removes the misleading dead copies.
🤖 Generated with Claude Code
https://claude.ai/code/session_01LQQDPHFAGVU67bEXrdboRS