Patch succeeded with fuzz 1

Then the source changed to:. The patch still says: replace line bb by dd , but line bb no longer exists, so that the patch can no longer be applied successfully. The solution is to look at the failed hunk, at the corresponding part of the old source on which the patch could be applied , and try to see what has changed in the new source, then try to adapt the new source to regenerate the patch.

This can only be done manually, and when there have been major changes in the source, this can be difficult, if not impossible. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. What is "fuzz" in applying patches? Ask Question. Asked 7 years, 1 month ago. The first line in the patch doesn't have two spaces.

The first space only identifies it as a context line. The second space is part of the line. The indexes in your patch file the numbers between are wrong. As xofon said, you have a problem with the starting line, you have 2 , but should be 1 But also the second number should be 3 not 4 , as you have 3 lines of code in your patch file before the patch is applied and 3 lines of code in your patch file after the patch is applied. Julien Julien 1, 18 18 silver badges 22 22 bronze badges.

Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. Email Required, but never shown. Sorry, something went wrong. The modified code is actually just a few lines further down than the diff specifies. After that it compiled fine for me, with the per worker listeners available. I am using nginx 1. Looking at where the issues in the patch were occurring I was able to modify it slightly and get the patch to work working just means the patch command is not failing.

Skip to content. Also interesting is that the patch works if I reverse the asymmetry, that is one line before and two after:. GNU patch is being helpful in one case by accepting a malformed patch.

For proper operation, patch typically needs at least three lines of context. The error is still in the diffutils info file. POSIX patch handles unified diffs. GNU patch just does not like when there is more prefix context than suffix context. A simple but ugly workaround is to convert the first line of context into a no-op change like this:.

I did go through patch 's source code and found the offending piece. Without understanding it too deeply, I came up with a simple fix similar to how prefix context is already handled in the code. Here is my output of git diff a patch for patch :. As Patrick Mevzek pointed out, there already is a regression test for asymmetric contexts.

So that is also corrected to not expect fuzzing. Unfortunately the merge test also fails in one case and I am not sure why. I guess I cannot submit the patch because of this. It would be nice if someone with more insight could come up with a better fix.