75

I get the following error when running make, and I have no idea what it means or what to do about it. Can anyone illuminate me or point me in the right direction?

(cd libdvdnav-git && patch -p1) < ../../contrib/src/dvdnav/dvdnav.patch
patching file Makefile.am
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.am.rej
make: *** [dvdnav] Error 1

I'm trying to cross compile VLC for win32 (using linux).

JellicleCat
  • 28,480
  • 24
  • 109
  • 162

9 Answers9

87

It is an error generated by patch. If you would open the .patch file, you'd see that it's organized in a bunch of segments, so-called "hunks". Every hunk identifies corresponding pieces of code (by line numbers) in the old and new version, the differences between those pieces of code, and similarities between them (the "context").

A hunk might fail if the similarities of a hunk don't match what's in the original file. When you see this error, it is almost always because you're using a patch for the wrong version of the code you're patching. There are a few ways to work around this:

  • Get an updated version of libdvdnav that already includes the patch (best option).
  • Get a .patch file for the version of libdvdnav you're patching.
  • Patch manually. For every hunk in the patch, try to locate the corresponding file and lines in libdvdnav, and correct them according to the instructions in the patch.
  • Take the version of libdvdnav that's closer to whatever version the .patch file was intended for (probably a bad idea).
  • Thanks. Because I'm cross compiling and using a big script to get the libs, I think I'd rather edit the patch file. Can you tell me the meaning of the line with the `@@` symbols? – JellicleCat Jan 11 '13 at 17:15
  • 2
    Your patch is in [unified format](http://en.wikipedia.org/wiki/Diff#Unified_format). You can ignore the part after the second `@@`. Between the `@@`s, there are two terms: the `-l,s` term indicates the offset (`l` is a line number) and size (`s` is a number of lines) of the hunk in the original file, while the `+l,s` indicates the offset and size in the file after patching. When there are multiple hunks, determining the `+l,s` part by hand can be quite a bit work. –  Jan 11 '13 at 17:26
29

In some cases, there is no difference in file versions, but only in indentation, spacing, line ending or line numbers.

To patch despite those differences, it's possible to use the following two arguments :

--ignore-whitespace : It ignores whitespace differences (indentation, etc).

--fuzz 3 : the "--fuzz X" option sets the maximum fuzz factor to lines. This option only applies to context and unified diffs; it ignores up to X lines while looking for the place to install a hunk. Note that a larger fuzz factor increases the odds of making a faulty patch. The default fuzz factor is 2; there is no point to setting it to more than the number of lines of context in the diff, ordinarily 3.

Don't forget to user "--dry-run" : It'll try the patch without applying it.

Example :

patch --verbose --dry-run --ignore-whitespace --fuzz 3 < /path/to/patch.patch

More informations about Fuzz :

https://www.gnu.org/software/diffutils/manual/html_node/Inexact.html

André DS
  • 1,823
  • 1
  • 14
  • 24
  • Ran into same issue. Perhaps, just pipe instead of copying. – viggy28 Oct 31 '19 at 23:18
  • This was the issue for me. Mix of tabs and spaces between the files – LFMekz Jul 18 '20 at 10:35
  • This solved my issue compiling `libecwj`: `patch --verbose --dry-run --ignore-whitespace --fuzz 3 -p1 < ../libecwj2-3.3-wcharfix.patch` – robe007 Jul 18 '20 at 14:22
  • 1
    Hunks order also matter. If the code they have patch in a file comes before lines that were already previously handled (kinda impossible for this to happen if you have just freshly made yourself the patch, but not that absurd if you are playing with backports), regardless of whatever fuzzing power they will fail. – mirh Aug 08 '20 at 11:54
4

Debugging Tips

  1. Add crlf to the end of the patch file and test if it works
  2. try the --ignore-whitespace command like in: markus@ubuntu:~$ patch -Np1 --ignore-whitespace -d software-1.0 < fix-bug.patch see tutorial by markus
Ema
  • 209
  • 2
  • 4
1

In my case, the patch was generated perfectly fine by IDEA, however, I edited the patch and saved it which changed CRLF to LF and then the patch stopped working. Curiously, converting it back to CRLF did not work. I noticed in VI editor, that even after setting to DOS format, the '^M' were not added to the end of lines. This forced me to only make changes in VI, so that the EOLs were preserved.

This may apply to you, if you make changes in a non-Windows environment to a patch covering changes between two versions both coming from Windows environment. You want to be careful how you edit such files.

BTW ignore-whitespace did not help.

Ev0oD
  • 1,395
  • 16
  • 33
1

It happened for me when I was generating my patch file with git diff and pasting the output:

git diff branch-1 branch-2 # and then copy the output

This inserts or changes the nature of whitespaces.

I directed the output to a file instead:

git diff branch-1 branch-2 > my-patch.patch

This fixed the issue.

Pauline
  • 3,566
  • 8
  • 23
  • 39
0

I got the "hunks failed" message when I wasn't applying the patch in the top directory of the associated git project. I was applying the patch (where I created it) in a subdirectory.

It seems patches can be created from subdirectories within a git project, but not applied.

Patrick
  • 11,552
  • 7
  • 29
  • 41
  • 1
    This is not true. You do however need to provide a `-p` argument to tell how many leading parts of the path should be ignored when using patch. `Patch` is not aware of the repository. `git am` is. – JonnyJD May 22 '14 at 12:51
0

Follow the instructions here, it solved my problem.

you have to run the command like as follow; patch -p0 --dry-run < path/to/your/patchFile/yourPatch.patch

Jehangir Wahid
  • 31
  • 1
  • 1
  • 7
0

Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file Makefile.am.rej

The same error I found when I apply changes through the patch and then searched completely on StackOverflow but I didn't get the answer.

Then I searched small parts like the reason behind the patch error then I found that

Hunk #n FAILED at nnn. n out of n hunks FAILED - saving rejects to file file.rej

This means that one or more changes, called hunks, could not be introduced into the file. Occasionally this could be because the patch was emailed or copied into a file and whitespace was either added or removed. Try adding --ignore-whitespace to the command line to work around this.

Step 2

then I searched about the different ends of the file, I found that there are two types of format systems LF, CF

then I check my files in what format by using

Now if this file was made in *NIX systems, it would display

$ cat -A file
hello$

hello$

But if this file was made in Windows, it would display

$ cat -A file
hello^M$

hello^M 

represents CR and $ represents LF. Notice that Windows did not save the last line with CRLF

this I found from StackOverflow

then I check my original file format and .patch/diff I get that the patch file has both LF and Cf

then I convert these files before applying the patch to either windows or unix format by using

dos2unix filename.extension or unix2dos filename.extension

this converts file

then apply the patch to get the result

command promt commands

creating file

touch filename.txt

for creating a patch/ diff file

diff -u originalfile.txt editedfile.txt > originalfile.diff

or

diff -u originalfile.txt editedfile.txt > originalfile.patch

before applying change check file formats

cat -A originalfile.txt    
cat -A originalfile.diff

now converts doc2unix or unix2dos

unix2dos originalfile.txt
unix2dos originalfile.diff

apply changes

patch originalfile.txt < originalfile.diff

Done !!

I hope this will help you !

AsukaMinato
  • 1,017
  • 12
  • 21
0

Please make sure (before making the diff file) that the 2 files that to be diffed not have extra new lines at the end of the file

the cursor stops after last typed word in the file.

  • Insofar as the OP is compiling software someone else made, it's very unlikely that they built the patch themselves at all. Beyond that, do you have any evidence that this is the specific problem they hit, as opposed to merely one of a nearly infinite number of ways the patch can be a mismatch against the source to which it attempts to apply? – Charles Duffy Jul 20 '22 at 15:28