Bjoern Fischer <[EMAIL PROTECTED]> writes:
| while setting up a small network from scratch with hamm, I found that
| /usr/bin/patch ( patch_2.5-2 ) fails to locate files in directories
| deeper than one (eg. *** drivers/sound/lowlevel/init.c ). When patch
| prompts for an alternative file name I exactly give `drivers/sound/lo
| wlevel/init.c' -- and it worx. ( options like -d or -p are set
| properly. )
How and where are you running patch and what do the file
specifications in the patch file look like? Basically you ALWAYS have
to give the "-p" option to patch. Even, if you're applying the patch
from the base directory of the patch file you have to give it the -p0
option, although there are recommendations to go into the root
directory first and use -p1 (see note at the end).
| I examined the whole thing with strace: patch looks for `init.c',
| `RCS/init.c' and so on, but misses the path `drivers/sound/lowlevel'
| completely. There is no `chdir' call or anything.
|
| Is this a known bug? Am I missing anything? Any hints?
|
| patch is *really* essential for my work. I have to apply a huge scoop
| of patches before this network will run entirely. When I'm forced to
| apply each patch interactively I'll be busy till xmas. At the time
| I'm grabbing the sources of patch...
I've used it for at least a directory depth of 4 so I know it
works. If using the -p0 argument doesn't do what you want, and the
note below doesn't help, post a small example patch and how you're
trying to invoke patch and maybe we can help further.
Gary
Here's a bit of wisdom picked off the AIC7xxx mailing list as posted
by Doug Ledford:
Arggg.....quoting from ftp.dialnet.net:/pub/linux/aic7xxx/7890-Status:
<QUOTE>
-- Wed, July 8, 15:39
OK..I've had one instance of this so far, and this is somewhat of a
religious issue for me, so I'm adding a quick note here. These
pre-patches
and the real patches (when done) are adding new files to the linux
source code tree. There is a well known problem with the patch program
and new files when you don't use the -p option to the patch program. So
here's the recommendation from a kernel hacker on the correct, painless,
religiously tolerable :) method of using patch:
1. Always cd *into* the kernel directory you wish to patch. This way,
if you didn't make your kernel directory named linux, or someone's
patch wasn't made against files in a directory called linux, there
won't be a problem because you are in the directory you want to
be in.
2. While you are there, use the patch program with the switches -p1 and
-E. The -p1 tells the patch program you went on into the 1st
directory and that should be stripped from the filenames in the
patch, and the -E tells patch to remove those files that are totally
empty when the patch is done.
There, follow those two rules, and patching will go very smooth in the
future for you :)
</QUOTE>
--
Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
