On 1/30/26 6:02 PM, Josh Poimboeuf wrote: > On Fri, Jan 30, 2026 at 02:59:53PM -0800, Josh Poimboeuf wrote: >> On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote: >>> On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote: >>>> Hm, isn't the whole point of --recount that it ignores the line numbers? >>>> Or does it just ignore the numbers after the commas (the counts)? >>>> >>> >>> I don't know exactly. As I continue digging into the test that sent me >>> down this path, I just found that `git apply --recount` doesn't like >>> some output generated by `combinediff -q --combine` even with NO line >>> drift... then if I manually added in corresponding diff command lines >>> (to make it look more like a .patch file generated by `diff -Nu`), ie: >>> >>> diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c <--- >>> --- src.orig/fs/proc/array.c >>> +++ src/fs/proc/array.c >>> >>> Suddenly `git apply --recount` is happy with the patch. >>> >>> So I suspect that I started with git not liking the hunks generated by >>> combinediff and drove it to the rebase feature, which solves a more >>> interesting problem, but by side effect smoothed over this format >>> issue when it recreated the patch with git. >>> >>> Anyway, I think this patch still stands on it's own: perform the same >>> apply/revert check as what would happen in the fixup steps to fail >>> faster for the user? >> >> If we just run fix_patches() at the beginning then can we just get rid >> of validate_patches() altogether? > > Or at least validate_patches() could be replaced with > check_unsupported_patches(), as the apply/revert test wouldn't be needed > since the actual apply/revert would happen immediately after that in > fix_patches(). >
Currently fix_patches runs in short-circuit step (2) after building the original kernel. But what if the user runs: $ klp-build -T 0001.patch $ klp-build -S 2 0002.patch If we move fix_patches() to step (1) to fail fast and eliminate a redundant apply/revert, aren't we then going to miss it if the user jumps to step (2)? Is there a way to check without actually doing it if we're going to build the original kernel first? And while we're here, doesn't this mean that we're currently not running validate_patches() when skipping to step (2)? -- Joe
