As long as my debug is correct, patch-2.6 introduced backward incompatible integration of -pnum and fuzz factor which may break epatch (see bug #293248) and other patching tools (may be bug #293385, but didn't checked it yet). For previous version of patch the priority was if target file exists not if the context is correct within fuzz scope, so for EPATCH_OPTS=-F3 epatch() run loop with -p{0..5} till target file was found. Currently fuzz is considered as more important and patch is applied on non existing files - -p1 isn't considered on patches with full headers (eg. pkg-ver/src/foo in ${S} env will apply patch on pkg-ver/pkg-ver/src/foo).
please post the actual files (source and patches) that exhibit behavior. it's a lot easier to deal with attachments/tarballs in this bug than having to piece together things from random bugs/packages.
Created attachment 210551 [details] Cleared source tarball with relevant files
Created attachment 210553 [details, diff] patch to apply Here you go.
and the exact dir and patch command to run ?
If you unpack the tarball to /tmp/tripwire-2.3.1-2/ and go into try applying patch like follows: cat /path/to/tripwire-friend-classes.patch | patch -p0 -F3 This will create /tmp/tripwire-2.3.1-2/tripwire-2.3.1-2-p1/src/foo files instead patching files inside /tmp/tripwire-2.3.1-2/src/ as expected from -p0 but patch-2.5.9 reports no file to patch. This way epatch() can run in a loop to -p1 and successfully apply.
I've now masked patch-2.6 on behalf of QA. The problem seem to be widespread, but what I'm worried about is not just the packages failing to build, but rather the other patches that might silently fail: a build failure is obvious enough, but what about crash fixes? Security fixes? Given the implications, users shouldn't get this not even in ~arch.
any package that relies on an increased fuzz factor (-F#) is doing stupid crap in the first place.
have fun, you can see the games bugs already don't you? I'm afraid the fuzz factor is not the only problem there…
i never said this was only an issue for -F# users, just that people who force -F# manually to get a patch to apply should be making cleaner patches
(In reply to comment #8) > have fun, you can see the games bugs already don't you? I'm afraid the fuzz > factor is not the only problem there… > Is there other known problems with patch-2.6 which result in not applied patch?
I'm afraid -F2 (the default) is also sometimes causing problem.
it all seems to be the same issue ... patch does not consider non-existent files when the fuzz factor equals or exceeds the number of contexts
Does this issue effect gentoo-sources?
(In reply to comment #13) > Does this issue effect gentoo-sources? In theory, yes. But number of patches is small so you can check youself if they applied properly for a kernel. I usually use vanilla kernels, so this problem is out of my interest.
patch-2.6.1 should fix this behavior
