patch command : Hunk #1 succeeded at 25 with fuzz 1.

Karl Godt · 10-21-2010, 07:50 AM

Hi !

I am beginning to start to work with compiling and I get some confusing output adding patches to sourcecode (xosview-1.8.3).

(The patch is for suppressing warnings while running the make command :

deprecated conversion from * char to ** char )

Xosview compiles without the patch.

The patch itself contains 17 files to add mostly const char instead of char.

It is one single file containing also files in one subdirectory.

While running `patch < PATCHFILE.patch I had to copy'n'paste the filenames of the subdirectory to the terminal to keep it going.

To get it going without much manual input I split it up for the two directories.

I got the original patch and both splitted patches succeeding
but
with confusing output like :

patch unexpectedly ends in middle of line
Hunk #2 succeeded at 78 with fuzz 1.

or just

patching file nfsmeter.h
patch unexpectedly ends in middle of line
#

I splitted the original patch to every 17 files and this kind of output I get now at almost every patchfile.

I downloaded patch source from debian

and running `pfind` (Puppy-linux speciality .sh) for search text in files showed off

patch.c

Quote:

if (verbosity != SILENT)
say ("Hunk #%d FAILED at %s.\n", hunk,
format_linenum (numbuf, newwhere));
} else {
if (verbosity == VERBOSE
|| (verbosity != SILENT && (fuzz || last_offset))) {
say ("Hunk #%d succeeded at %s", hunk,
format_linenum (numbuf, newwhere));
if (fuzz)
say (" with fuzz %s", format_linenum (numbuf, fuzz));
if (last_offset)
say (" (offset %s line%s)",
format_linenum (numbuf, last_offset),
"s" + (last_offset == 1));
say (".\n");

and pch.c

Quote:

/* Input a line from the patch file, worrying about indentation.
Strip up to INDENT characters' worth of leading indentation.
Then remove up to RFC934_NESTING instances of leading "- ".
If STRIP_TRAILING_CR is true, remove any trailing carriage-return.
Unless PASS_COMMENTS_THROUGH is true, ignore any resulting lines
that begin with '#'; they're comments.
Ignore any partial lines at end of input, but warn about them.
Succeed if a line was read; it is terminated by "\n\0" for convenience.
Return the number of characters read, including '\n' but not '\0'.
Return -1 if we ran out of memory. */

The patches are patching but I would feel more confident to adjust the patches to get them running without warnings.
/path/to/xosview-1.8.3/linux/netmeter.h.p :

Code:

--- xosview-1.8.3~/linux/netmeter.h	2008-05-31 13:28:23.000000000 +0200
+++ xosview-1.8.3/linux/netmeter.h	2008-05-31 13:29:56.728546050 +0200
@@ -31,7 +31,7 @@
   int _ipsock;
   Timer _timer;
   unsigned long long _lastBytesIn, _lastBytesOut;
-  char *_netfilename;
+  const char *_netfilename;
   bool _usechains;
   int _bytesInDev;

/path/to/xosview-1.8.3/linux/netmeter.h

Code:

//
//  Copyright (c) 1994, 1995, 2006 by Mike Romberg ( mike.romberg@noaa.gov )
//
//  This file may be distributed under terms of the GPL
//
//
// $Id$
//
#ifndef _NETMETER_H_
#define _NETMETER_H_

#include "fieldmetergraph.h"
#include "timer.h"

class Host;

class NetMeter : public FieldMeterGraph {
public:
  NetMeter(XOSView *parent, float max);
  ~NetMeter( void );

  const char *name( void ) const { return "NetMeter"; }
  void checkevent( void );

  void checkResources( void );
protected:
  float maxpackets_;
  std::string netIface_;

private:
  int _ipsock;
  Timer _timer;
  unsigned long long _lastBytesIn, _lastBytesOut;
  const char *_netfilename;
  bool _usechains;
  int _bytesInDev;

  void adjust(void);
  void checkOSVersion(void);

  void checkeventOld(void);
  void checkeventNew(void);
};

#endif

that

Quote:

patch unexpectedly ends in middle of line

As you can see the patch is working but what would I have to add to the patch ?
I added more newlines , added all lines to close a "{" if the patched line was inside ( also added "}" ), adjusted the path at the diff -uraNd /PATH/ -line, even deleted the diff line.

GrapefruiTgirl · 10-21-2010, 08:17 AM

If you have visually verified that the patched files are indeed A-OK despite the fuzz warnings, then why not use:

Code:

diff -up unpatched_file patched_file

to create a new patch. Then you'd have a working, quiet patch file to apply to the source file whenever you need to (why do you need to keep patching it over and over?

)

Also, you can use `diff` to make a patch of all the files in the tree - in other words, copy your unpatched source tree, patch all the files in the copied tree, and diff the trees; this would result in a new patch for patching the whole tree. I don't know what other options for `diff` you need for this so check the manpage; if you can't figure it out, someone else may be able to help.

Karl Godt · 10-26-2010, 11:59 PM

Thank zou very much for the HeadUp, Celine !

As far as I can explain it for now with another example :

Hunk :

Quote:

@@ -169,6 +170,7 @@ void fsnotify_put_group(struct fsnotify_

fuzz 1 :

Quote:

fsnotify_recalc_global_mask();
fsnotify_destroy_group(group);
}

part to patch :

Quote:

+EXPORT_SYMBOL(fsnotify_put_group);

fuzz 2 :

Quote:

/*
* Simply run the fsnotify_groups list and find a group which matches

As far as I can see (my) patch command compares the whole Hunk part within the whole file to be patched.

If it finds one of the two fuzz to be 100% identical it executes the part to patch, even at different line numbers.

If only one fuzz is identical patch echoes

Quote:

Hunk #6 succeeded at 421 with fuzz 2.

the fuzz that doesn't match.

If also the lines have been put or found elsewhere in the file :

Quote:

Hunk #2 succeeded at 71 with fuzz 2 (offset -99 lines).

the largest offset I've encountered at the moment
( 71 + 99 = 170 ).

I guess hacking code also requires often to put new blank lines for better overview and it seems to be common to forget to delete the one or two added new lines afterwards or adding a patch after one had changed some part of the file to patch already.

GrapefruiTgirl · 10-27-2010, 05:05 AM

Hi Karl

I don't quite detect a question in the above post - if there is one, please rephrase it. Otherwise, it appears that you have a basic understanding of what's happening when you're patching the files; so does the patched code work Ok?

And though I believe you understand what "fuzz" means, it's this: the fuzz factor allows a patch to still work, even though the target file is slightly different than the version that the original patch was intended to patch. Fuzz allows the `patch` tool to try to be a little bit clever, and figure out how to patch the file even when it doesn't match perfectly. With small fuzz, and messages of "patch successful", usually the patched file will be fine. Occasionally it isn't.

If you run into further issues though, do feel free to tell us what's happening, and ask questions if something's still unclear.

Good luck!

Karl Godt · 10-27-2010, 11:52 AM

first : I am happy to have found a solution and google search with these keywords didn't threw explanations somehow....

second : I had also to understand how patch -p1 is working :
it is actually -p 1 (one) and not -pl (small "L") or -p| ( I really don't know the name for this "keep going using more commands" like lsmod | grep MODULE .. It is also an "OR" in C and shell as far as I can see)

third: I lost some time to find out about Kernel compiling ... Thought the patch next to the kernel would be a patch for it but I realized that it's the whole diff from the former kernel = simply upgrade patch to reduce the time to bunzip2 and tar -xf 'it.

With the patch unexpectedly ends in middle of line
I would have to play around with later this month or year
because some features at xosview are more interesting atm.
It seems that I could find out to get a background pixmap working but I get some confusing output that some colors couldn't be allocated.

GrapefruiTgirl · 10-27-2010, 12:01 PM

For the record, the "|" is referred to as a "pipe", when used in "pipelines", i.e. feeding stdout into stdin. And yes, also as an "OR" in some contexts.

Karl Godt · 11-29-2010, 02:36 PM

Quote:

diff -up unpatched_file patched_file

You got me really sour, grapef* girl !

patch -up doesn't worked for me

but patch -uaNd did ( for just one file )

I submitted a patch somewhere and days later I recognized that patch -up
# patch < /usr/local/petget/diff-up-check_deps.sh.patch.01
patching file check_deps.sh
Hunk #4 FAILED at 181.
Hunk #5 FAILED at 191.
Hunk #6 succeeded at 236 with fuzz 2.
2 out of 6 hunks FAILED -- saving rejects to file check_deps.sh.rej

while patch -uaNd did it flawlessly

GrapefruiTgirl · 11-29-2010, 03:45 PM

Quote:

Originally Posted by Karl Godt

You got me really sour, grapef* girl !

patch -up doesn't worked for me

but patch -uaNd did ( for just one file )

I submitted a patch somewhere and days later I recognized that patch -up
# patch < /usr/local/petget/diff-up-check_deps.sh.patch.01
patching file check_deps.sh
Hunk #4 FAILED at 181.
Hunk #5 FAILED at 191.
Hunk #6 succeeded at 236 with fuzz 2.
2 out of 6 hunks FAILED -- saving rejects to file check_deps.sh.rej

while patch -uaNd did it flawlessly

Heh, it's over a month later and you're just going sour now? And blaming me?? LOL.. Nowhere did I instruct you or suggest you use:

Code:

patch -up

so if it didn't do what you expected... Where did you get that command?

What I suggested was:

Code:

diff -up

for creating the patch, NOT for using the patch. And, where I suggested that, it was intended to be used on a single file; for a whole directory, you need a different command, as you have discovered.

I'm glad you have got the commands you need, working now. ;-)