On Wed, 3 Aug 2005, Jesper Juhl wrote:
> +What is a patch?
> +To correctly apply a patch you need to know what base it was generated from
> +and what new version the patch will change the source tree into. These
> +should both be present in the patch file metadata.
This is usurally not true for kernel patches, the directories are mostly
named a and b. You can however deduce the to-bepatched version and the
patched version from the filename.
> +How do I apply a patch?
> +---
> + You apply a patch with the `patch' program. The patch program reads a diff
> +(or patch) file and makes the changes to the source tree described in it.
> +Patches for the Linux kernel are generated relative to the parent directory
> +holding the kernel source dir. This means that paths to files inside the
> +patch file contain the name of the kernel source directories it was
> +generated against - since this is unlikely to match the name of the kernel
> +source dir on your local machine (but is often useful info to see what
> +version an otherwise unlabeled patch was generated against)
Same issue.
> you should
> +change into your kernel source directory and then strip the first element of
> +the path from filenames in the patch file when applying it (the -p1 argument
> +to `patch' does this). To revert a previously applied patch, use the -R
> +argument to patch.
> +How do I feed a patch/diff file to `patch'?
[...]
Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion && patch -p1)
Finding out if a patch applied correctly
---
A quick check is to search for .rej files. Unfortunately some errors
How do I undo a patch?
---
You can undo a patch by supplying the -R switch to patch. If you patched
using zcat ../patch.gz | patch -p1, zcat ../patch.gz | patch -Rp1 will
undo the changes as long as the patch applied correctly.
Common errors while patching
---
"File to patch:"
Patch could not find a file to be patched. Most probably you forgot to
use -p1 or you're in the wrong directory. Less often, you'll find
patches that need to be applied with -p0 instead (you can't just omit
-p0!). ^^^^^^^^^^^^^^^^^^^
^^^^^ [IIRC]
Sometimes this is the result of an incomplete tarball, a out-of-space
error while unpacking or a fsck.
"Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)."
The patch was applied, but it might be applied to the wrong place
because you patched the "wrong" source. The result might not work
correctly.
"Hunk #3 FAILED at 2387."
The patch could not be applied correctly. This is usurally fatal, except
if you apply external patches to the stable series (e.g. to 2.6.23.42
instead of 2.6.23) and the reject is in the toplevel Makefile.
(You'll have to manually edit the Makefile and change the version string
as recorded in Makefile.rej)
If you apply more than one external patch, the same thing will happen,
but there is no guarantee for a working kernel (the changes may bite
each other).
You can most likely recover the source tree by undoing the patch and
removing the .rej and .orig files. YMMV.
"Reversed (or previously applied) patch detected! Assume -R? [n]"
Either you really applied the patch before, or the patch is for some
other source. If this is not the very first message, the source is
most likely unusable by now.
"patch: **** unexpected end of file in patch"
Your download is broken. Re-get the file.
--
To steal information from a person is called plagiarism. To steal
information from the enemy is called gathering intelligence.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |