From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8906 invoked by alias); 19 Oct 2006 17:34:41 -0000 Received: (qmail 8896 invoked by uid 22791); 19 Oct 2006 17:34:40 -0000 X-Spam-Check-By: sourceware.org Received: from mail.zeugmasystems.com (HELO zeugmasystems.com) (192.139.122.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 19 Oct 2006 17:34:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: How to do patching? Date: Thu, 19 Oct 2006 17:34:00 -0000 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D4178ED@exchange.ZeugmaSystems.local> From: "Kaz Kylheku" To: , X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00139.txt.bz2 bjgnu@sunnorth.com.cn wrote: > Hello all, >=20 > When patching a file, report following error message: > Hunk #1 FAILED at 1184. > Hunk #2 FAILED at 1238. > Hunk #3 FAILED at 1840. > Hunk #4 FAILED at 2000. > Hunk #5 succeeded at 2409 with fuzz 2. >=20 > The operation flow is as follows: > 1. copy diff text in maillist mail to my.patch You should hunt down the original form of the patch. Patches in e-mail sometimes get munged. Whitespace is significant in patches. In particular, do not cut and paste patches from mailing list archives that are hosted on the web. You can use the -l or --ignore-whitespace options so that patch works more "loosely", but the best thing is to just have the correct, unmodified patch. > Note: I use emacs to edit my.patch. > My mail box is Lotus Notes. > I found there are many space in my.patch.=20 > 2. execute "patch < my.patch", the above error message emit. >=20 > Which step is wrong or What is the problem? That's impossible to diagnose without having an exact copy of your patch and the files that it's being applied to. You have to look at the patch hunks and the file together to see whether the file has exactly matching context lines that patch can find. If you are not applying the patch to the exact same base version of the software against which it was produced, then you may get these errors because the context lines in the patch do not match the text in the source file. If that's the case, you have to "rediff" the patch. This means: look at each hunk which did not apply, think about what that hunk is trying to do, and then, if necessary, create the equivalent (though obviously not identical) change in the file manually, using your creativity and programming skill. Sometimes the sources of conflict are trivial. Someone reformatted the code with whitespace changes only, or changed the name of an identifier, or fixed a spelling error in comment text, whatever. Sometimes the conflicts are not trivial, and you have to take some serious software engineering responsibility for doing the rediffing. It may be best to go back to the original patch author and ask if he or she has a rediffed verison of the patch against your version of the code base. You might want to learn how to use the "quilt" utility if you are doing a lot of patching. It doesn't help with the patch resolution problems themselves, but it helps to manage other aspects of the whole process. Quilt makes rediffing easier because it keeps a pristine copy of the patched files. You can force a patch with "quilt push -f", then manually rediff the parts that didn't apply by editing the affected files. When you are done just "quilt refresh" and the patch is replaced with a new diff which applies cleanly to the original files.