Subject: [Dev] RE: embarrassing patch question

From: Ed Vance <[email-masked]>
Date: Thu, 28 Feb 2002 12:34:36 -0800

On Thu, Feb 28, 2002 at 11:46 AM, John F Davis wrote:
> Put another way, in your step 2.2, what is the implied 
> directory name used for the patch?  What is the p1 or 
> p0 bit?  Is that supposed to somehow strip the leading 
> directory name or something? 

Yes, the digit after the "-p" tells patch how many leading 
directory names to ignore. These are the directory names 
that are found inside the patch.file itself. Most kernel 
patches are designed to be used with "-p1" because it 
allows the author to have a completely bogus top level 
directory that labels what version is to be patched.

For example, the top three lines of one of my patches:

diff -urN -X dontdiff.txt linux-2.4.18-rc1/drivers/pci/pci.ids
rc1-ml/drivers/pci/pci.ids
--- linux-2.4.18-rc1/drivers/pci/pci.ids	Fri Feb 15 14:24:19 2002
+++ rc1-ml/drivers/pci/pci.ids	Fri Feb 15 14:49:07 2002

I would expect the user of the patch to execute patch in his top 
level source tree directory, perhaps named /usr/src/my-linux, with 
the -p1 specified so patch ignores the "linux-2.4.18-rc1" directory 
specified on the "---" line, and the "rc1-ml" directory specified on 
the "+++" line of my patch.file. Thus patch is looking for directory 
drivers/pci ... which it will find in its current directory, 
/usr/src/my-linux. The directory where patch will look for the file 
to be patched, pci.ids, is /usr/src/my-linux/drivers/pci. My leading 
directory name was chosen to inform the user that this patch was 
created from the version 2.4.18-rc1 kernel files.

>                               When you issue that
> command, are you in the parent directory which owns
> the kernel directory to be patched or are you in the 
> directory to be patched?

Is it clearer now? Patch ignores the leading directories that you 
tell it to ignore, and looks for the rest of the specified path in 
it's current directory.

Best regards,
---------------------------------------------------------------- 
Ed Vance              [email-masked]
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------

---

From: "John F Davis" <[email-masked]>
Date: Thu, 28 Feb 2002 17:37:28 -0500

Hello

Ok. After much consternation its working now.  Many thanks to Greg KH who
pointed
out this gem on a document: linux/Documentation/SubmittingPatches file.  It
explains in
pointed detail the answer to my question about the prescribed method.  It
instructs
the user to use the dontdiff file list which contains more than just the
asm directory.
I forgot about autoconf.h and its ilk.  Also, when you use dontdiff you
don't need
to do a make mrproper beforehand.  you can build it with your object files
in place!

So to sum it up:

Building the patch:
diff -Nur -X dontdiff linux-2.4.2_hhl20.orig linux-2.4.2_hhl20 > k2.patch
Applying the patch:
patch -d linux-dir-to-patch -p1 < k2.patch

Many thanks to all who gave me a hand (That includes you Ed).

JD

ps. see the SubmittingPatches doc for how to get the dontdiff file list.

Jan Hudec <[email-masked]>@nl.linux.org on 02/28/2002 05:08:56 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    Re: embarrassing patch question

> > Then without changing the directory, I attempt to patch the directory
like
> > so:
> > patch -d linux-to-be-patched -p1 < k2.patch
>
> try:
> cd linux-to-be-patched
> patch -p1 < ../k2.patch

The manual page claims, that
$ patch -d directory -p1 < the.patch
and
$ cd directory
$ patch -p1 < ../the.patch
is _exactly_ equivalent. So if one of them works and the other does not, it
seems like a bug in patch or at least in the man page.

Oh, think I see the fault now. diff seems to handle symlinks wrong. There
is
the dontdiff file to take care of that. (-X dontdiff option)

--------------------------------------------------------------------------------

                      - Jan Hudec `Bulb' <[email-masked]>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
IRC Channel:   irc.openprojects.net / #kernelnewbies
Web Page:      http://www.kernelnewbies.org/