Repairing failed HUNKs

[eK3eKyToPa]

Every patch I'm trying to put on my build have several hunks failed.
I get the latest patches from the tracker but still they failed some of the HUNKs
When I'm trying to -R the patch it again get failed.
And in the end if even one HUNK has failed I can't do the 'make' command and it failed too

When a HUNK failed I read the .rej fail but I cant understand anything in it, I'm not programer , how to repair the patch so that to work.
Please give some advice, so to get my build working.
   Thanks eK3eKyToPa

[GodEater]

The only way to fix them is to become a programmer, so that you can understand what they're doing, and what about the patch has caused it to fail. There simply isn't another way to do it.

[eK3eKyToPa]

Does the patches uploaded in the tracker are able to use in the build of the same day ?

[AlexP]

It depends on what version of the source code the patch was made against, but generally people will upload a patch straight after synching it to current source.  Of course as the source code is changed many times per day, it might be that an incompatible change is made 5 minutes after a patch is synched.

If a patch fails to apply you can either fix it yourself, wait for someone else to resync it, or use a version of the source from when the patch was current.  However the more patches you use the greater the likelyhood of some being out of sync or one breaking another.  Also bear in mind that some patches are written to depend on other patches.

[TheMono]

Disclaimer: Following instructions in this post may well result in breaking the source even worse than before.

Having said that,

The patch files are basically instructions to change parts of the source. If you read down the left hand side, you will notice most lines begin with a " ", a "+", or a "-". For example, one patch I use contains this text:

Code: [Select]

         if ( GPIOD_INPUT_VAL & 0x20 )
         {
             GPIOD_OUTPUT_VAL &=~ 0x40;
-            udelay(50);
+            udelay(100);
             data = adc_scan(ADC_SCROLLPAD);

The lines starting with a space are a reference to the code as it stands. So, when you apply the patch, it will look for where in the code it contains

Code: [Select]

         if ( GPIOD_INPUT_VAL & 0x20 )
         {
             GPIOD_OUTPUT_VAL &=~ 0x40;-

The next instruction is

Code: [Select]

-            udelay(50);

When it reads this, it will remove that line, hence the "-". The line comes directly after that reference piece of code, hence the reference code being there to make sure it doesn't accidentally remove the wrong instance of that line.

The next instruction is

Code: [Select]

+            udelay(100);

When it reads this, it will add in that line. This is then followed with some more reference code.

So the net result is that this:

Code: [Select]

        if ( GPIOD_INPUT_VAL & 0x20 )
        {
            GPIOD_OUTPUT_VAL &=~ 0x40;
            udelay(50);

            data = adc_scan(ADC_SCROLLPAD);

Gets changed to this:

Code: [Select]

        if ( GPIOD_INPUT_VAL & 0x20 )
        {
            GPIOD_OUTPUT_VAL &=~ 0x40;
            udelay(100);
            data = adc_scan(ADC_SCROLLPAD);

The .rej files are just pieces of the patch that didn't apply - generally because the reference code is wrong, or a line it is supposed to remove is changed. As an example, again using the code above, if the line in the actual code was changed from this:

Code: [Select]

            udelay(50);

To this:

Code: [Select]

            udelay(250);

The patch would not apply correctly, as it would try to remove a line that does not exist. To sync the patch, just change the line in the patch from reading "50" to reading "250" so that it again matches up, and it will apply. To apply it manually, just do what the program does by interpreting the + and - signs yourself from the points provided by the reference code, and use discretion to see what will and will not work.

Sometimes patches can be so far out of sync that you really need to be able to program to get them to apply, but often they can apply cleanly with just a little tinkering and no programming knowledge.

Oh, and with regards to patches depending on each other - an example is album art and bitmap resize. The reference code in the bitmap resize patch is code that is only applied in the album art patch, so you need to have applied album art in order for the bitmap resize patch to be able to find the reference code it is looking for.

[eK3eKyToPa]

@TheMono Thank you very much, great tutorial.
I get it now , and will have to modify some patches

[TheMono]

Glad I could help. All the best with your patching - feel free to contact me if you have any other questions, though I'll only be of limited help, as programming (and indeed Rockbox in general) isn't my specialty...

[eK3eKyToPa]

What does these lines mean

Code: [Select]

Index: apps/lang/english.lang =================================================================
--- apps/lang/english.lang	(revision 14888) 
+++ apps/lang/english.lang	(working copy)
@@ -11327,4 +11327,20 @@

What is the difference between the 2 lines 'apps/lang/english.lang' sometimes the second one ends with .orig extension of the file

And what does the lines between the '@@' and '@@' means, how I have to change them if going to sync the patch?

[TheMono]

Don't worry about that. Roughly speaking, it's just switching from a specific revision of the source to your own individualised version. Those lines don't really matter much if you are just patching source and building, not developing.

[bluebrother]

Code: [Select]

Index: apps/lang/english.lang =================================================================
--- apps/lang/english.lang	(revision 14888) 
+++ apps/lang/english.lang	(working copy)
@@ -11327,4 +11327,20 @@

What is the difference between the 2 lines 'apps/lang/english.lang' sometimes the second one ends with .orig extension of the file

It tells which files diff compared. The filename doesn't tell much, it's just for reference -- and if you diff against svn it includes the revision of the svn you're diffing against. Again, this is just for convenience and gets ignored when applying the patch.

And what does the lines between the '@@' and '@@' means, how I have to change them if going to sync the patch?

They indicate which portion of the source file has to be changed. Basically they contain line numbers and number of changed lines. Still, you shouldn't change those lines -- you should apply the failed hunks manually (you'd need to do that anyway to have enough control) and then generate a diff from the modified file. I.e. you create a diff the same way you do when generating the diff in the first place.

[eK3eKyToPa]

... and then generate a diff from the modified file. I.e. you create a diff the same way you do when generating the diff in the first place.

I didn't get how to generate the diff ( is .patch available) file

[bluebrother]

if you're working on a svn checkout, simply issue

Code: [Select]

svn diff

This will diff the complete tree. If you only want do diff some specific files just add them as arguments to the command.

Diff and patch are almost identical: diff is the tool for checking the differences between two files. The output is a simple text and usually saved to a file. It's common use to use the file extension .diff or .patch for this output. Patch is the tool to apply the output of diff to a source tree.

And I'd really suggest you reading the documentation for diff / patch. This is simply basic usage of those tools.

[Mad Cow]

And remember that just typing svn diff won't output it to a file. You need to type svn diff >filename.diff

[eK3eKyToPa]

Ha-ha
Thx

[tdtooke]

Bear in mind sometimes things have just moved substantially and then you can use the reject files to find what landmarks you need to be looking for to put things in, but then other times you have to know C and have to be familiar with how whatever it is your working with works.  It can involve endless hours of staring at the code until your eyes are bloodshot before you begin to see how something works.