Lines Matching refs:patch
10 a patch to the kernel or, more specifically, what base kernel a patch for
19 What is a patch?
21 A patch is a small text document containing a delta of changes between two
24 To correctly apply a patch you need to know what base it was generated from
25 and what new version the patch will change the source tree into. These
26 should both be present in the patch file metadata or be possible to deduce
30 How do I apply or revert a patch?
32 You apply a patch with the `patch' program. The patch program reads a diff
33 (or patch) file and makes the changes to the source tree described in it.
38 This means that paths to files inside the patch file contain the name of the
43 unlabeled patch was generated against) you should change into your kernel
45 in the patch file when applying it (the -p1 argument to `patch' does this).
47 To revert a previously applied patch, use the -R argument to patch.
48 So, if you applied a patch like this:
49 patch -p1 < ../patch-x.y.z
52 patch -R -p1 < ../patch-x.y.z
55 How do I feed a patch/diff file to `patch'?
59 In all the examples below I feed the file (in uncompressed form) to patch
61 patch -p1 < path/to/patch-x.y.z
64 know of more than one way to use patch, then you can stop reading this
69 patch -p1 -i path/to/patch-x.y.z
71 If your patch file is compressed with gzip or bzip2 and you don't want to
72 uncompress it before applying it, then you can feed it to patch like this
74 zcat path/to/patch-x.y.z.gz | patch -p1
75 bzcat path/to/patch-x.y.z.bz2 | patch -p1
77 If you wish to uncompress the patch file by hand first before applying it
80 gunzip patch-x.y.z.gz
81 bunzip2 patch-x.y.z.bz2
83 Which will leave you with a plain text patch-x.y.z file that you can feed to
84 patch via stdin or the -i argument, as you prefer.
86 A few other nice arguments for patch are -s which causes patch to be silent
88 screen too fast, and --dry-run which causes patch to just print a listing of
90 tells patch to print more information about the work being done.
95 When patch applies a patch file it attempts to verify the sanity of the
97 Checking that the file looks like a valid patch file & checking the code
98 around the bits being modified matches the context provided in the patch are
99 just two of the basic sanity checks patch does.
101 If patch encounters something that doesn't look quite right it has two
103 to find a way to make the patch apply with a few minor changes.
105 One example of something that's not 'quite right' that patch will attempt to
107 line numbers are different. This can happen, for example, if the patch makes
110 everything looks good it has just moved up or down a bit, and patch will
111 usually adjust the line numbers and apply the patch.
113 Whenever patch applies a patch that it had to modify a bit to make it fit
114 it'll tell you about it by saying the patch applied with 'fuzz'.
115 You should be wary of such changes since even though patch probably got it
119 When patch encounters a change that it can't fix up with fuzz it rejects it
127 never see a fuzz or reject message from patch. If you do see such messages
129 patch file is corrupted in some way. In that case you should probably try
130 re-downloading the patch and if things are still not OK then you'd be advised
133 Let's look a bit more at some of the messages patch can produce.
135 If patch stops and presents a "File to patch:" prompt, then patch could not
138 applied with -p0 instead of -p1 (reading the patch file should reveal if
140 the patch but is not fatal).
143 message similar to that, then it means that patch had to adjust the location
148 This often happens if you try to apply a patch that was generated against a
149 different kernel version than the one you are trying to patch.
152 patch could not be applied correctly and the patch program was unable to
154 caused the patch to fail and also a .orig file showing you the original
157 If you get "Reversed (or previously applied) patch detected! Assume -R? [n]"
158 then patch detected that the change contained in the patch seems to have
160 If you actually did apply this patch previously and you just re-applied it
161 in error, then just say [n]o and abort this patch. If you applied this patch
163 then you can say [y]es here to make patch revert it for you.
164 This can also happen if the creator of the patch reversed the source and
165 destination directories when creating the patch, and in that case reverting
166 the patch will in fact apply it.
168 A message similar to "patch: **** unexpected end of file in patch" or "patch
169 unexpectedly ends in middle of line" means that patch could make no sense of
171 patch a compressed patch file without uncompressing it first, or the patch
178 a patch from kernel.org to the correct version of an unmodified source tree.
180 assume that either your patch file or your tree is broken and I'd advise you
181 to start over with a fresh download of a full kernel tree and the patch you
185 Are there any alternatives to `patch'?
190 generate a patch representing the differences between two patches and then
198 interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1
207 patch; lsdiff, which displays a short listing of affected files in a patch
208 file, along with (optionally) the line numbers of the start of each patch;
209 and grepdiff, which displays a list of the files modified by a patch where
210 the patch contains a given regular expression.
243 If regressions or other serious flaws are found, then a -stable fix patch
245 kernel is released, a patch is made available that is a delta between the
248 To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
251 first revert the 2.6.x.y patch).
257 $ patch -p1 < ../patch-2.6.12 # apply the 2.6.12 patch
263 $ patch -p1 -R < ../patch-2.6.11.1 # revert the 2.6.11.1 patch
265 $ patch -p1 < ../patch-2.6.12 # apply new 2.6.12 patch
289 patch does not apply on top of the 2.6.12.2 kernel source, but rather on top
291 So, in order to apply the 2.6.12.3 patch to your existing 2.6.12.2 kernel
292 source you have to first back out the 2.6.12.2 patch (so you are left with a
293 base 2.6.12 kernel source) and then apply the new 2.6.12.3 patch.
298 $ patch -p1 -R < ../patch-2.6.12.2 # revert the 2.6.12.2 patch
299 $ patch -p1 < ../patch-2.6.12.3 # apply the new 2.6.12.3 patch
325 kernel and the patch should be applied on top of the 2.6.12 kernel source.
331 $ patch -p1 < ../patch-2.6.13-rc3 # apply the 2.6.13-rc3 patch
337 $ patch -p1 -R < ../patch-2.6.13-rc3 # revert the 2.6.13-rc3 patch
338 $ patch -p1 < ../patch-2.6.13-rc5 # apply the new 2.6.13-rc5 patch
344 $ patch -p1 -R < ../patch-2.6.12.3 # revert the 2.6.12.3 patch
345 $ patch -p1 < ../patch-2.6.13-rc5 # apply new 2.6.13-rc5 patch
362 A patch named 2.6.12-git1 applies to the 2.6.12 kernel source and a patch
369 $ patch -p1 < ../patch-2.6.12-git1 # apply the 2.6.12-git1 patch
375 $ patch -p1 -R < ../patch-2.6.12-git1 # revert the 2.6.12-git1 patch
377 $ patch -p1 < ../patch-2.6.13-rc2 # apply the 2.6.13-rc2 patch
379 $ patch -p1 < ../patch-2.6.13-rc2-git3 # apply the 2.6.13-rc2-git3 patch
391 Once a patch has proved its worth in -mm for a while Andrew pushes it on to
432 $ patch -p1 < ../2.6.12-mm1 # apply the 2.6.12-mm1 patch
438 $ patch -p1 -R < ../2.6.12-mm1 # revert the 2.6.12-mm1 patch
440 $ patch -p1 < ../patch-2.6.13-rc3 # apply the 2.6.13-rc3 patch
442 $ patch -p1 < ../2.6.13-rc3-mm3 # apply the 2.6.13-rc3-mm3 patch