Lines Matching +full:5 +full:a

14 A frequently asked question on the Linux Kernel Mailing List is how to apply
15 a patch to the kernel or, more specifically, what base kernel a patch for
19 In addition to explaining how to apply and revert patches, a brief
24 What is a patch?
27 A patch is a small text document containing a delta of changes between two
28 different versions of a source tree. Patches are created with the ``diff``
31 To correctly apply a patch you need to know what base it was generated from
37 How do I apply or revert a patch?
40 You apply a patch with the ``patch`` program. The patch program reads a diff
48 names like "a/" and "b/").
57 To revert a previously applied patch, use the -R argument to patch.
58 So, if you applied a patch like this::
67 How do I feed a patch/diff file to ``patch``?
101 Which will leave you with a plain text patch-x.y.z file that you can feed to
104 A few other nice arguments for patch are ``-s`` which causes patch to be silent
106 screen too fast, and ``--dry-run`` which causes patch to just print a listing of
114 When patch applies a patch file it attempts to verify the sanity of the
117 Checking that the file looks like a valid patch file and checking the code
123 to find a way to make the patch apply with a few minor changes.
128 a change in the middle of the file but for some reasons a few lines have
130 everything looks good it has just moved up or down a bit, and patch will
133 Whenever patch applies a patch that it had to modify a bit to make it fit
139 When patch encounters a change that it can't fix up with fuzz it rejects it
140 outright and leaves a file with a ``.rej`` extension (a reject file). You can
147 never see a fuzz or reject message from patch. If you do see such messages
148 anyway, then there's a high risk that either your local source tree or the
151 to start with a fresh tree downloaded in full from kernel.org.
153 Let's look a bit more at some of the messages patch can produce.
155 If patch stops and presents a ``File to patch:`` prompt, then patch could not
156 find a file to be patched. Most likely you forgot to specify -p1 or you are
162 If you get ``Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines).`` or a
170 This often happens if you try to apply a patch that was generated against a
173 If you get a message like ``Hunk #3 FAILED at 2387.``, then it means that the
175 fuzz its way through. This will generate a ``.rej`` file with the change that
176 caused the patch to fail and also a ``.orig`` file showing you the original
192 A message similar to ``patch: **** unexpected end of file in patch`` or
195 feed patch a compressed patch file without uncompressing it first, or the patch
196 file that you are using has been mangled by a mail client or mail transfer
197 agent along the way somewhere, e.g., by splitting a long line into two lines.
202 a patch from kernel.org to the correct version of an unmodified source tree.
205 to start over with a fresh download of a full kernel tree and the patch you
216 generate a patch representing the differences between two patches and then
219 This will let you move from something like 5.7.2 to 5.7.3 in a single
224 Here's how you'd go from 5.7.2 to 5.7.3 in a single step::
228 Although interdiff may save you a step or two you are generally advised to
231 Another alternative is ``ketchup``, which is a python script for automatic
234 Other nice tools are diffstat, which shows a summary of changes made by a
235 patch; lsdiff, which displays a short listing of affected files in a patch
237 and grepdiff, which displays a list of the files modified by a patch where
238 the patch contains a given regular expression.
248 The 5.x.y (-stable) and 5.x patches live at
252 The 5.x.y incremental patches live at
266 The 5.x kernels
272 If regressions or other serious flaws are found, then a -stable fix patch
273 will be released (see below) on top of this base. Once a new 5.x base
274 kernel is released, a patch is made available that is a delta between the
275 previous 5.x kernel and the new one.
277 To apply a patch moving from 5.6 to 5.7, you'd do the following (note
278 that such patches do **NOT** apply on top of 5.x.y kernels but on top of the
279 base 5.x kernel -- if you need to move from 5.x.y to 5.x+1 you need to
280 first revert the 5.x.y patch).
301 The 5.x.y kernels
306 in a given 5.x kernel.
312 If no 5.x.y kernel is available, then the highest numbered 5.x kernel is
326 source you have to first back out the 5.7.2 patch (so you are left with a
329 Here's a small example::
341 of base 5.x kernel, they are applied on top of previous stable kernel
342 (5.x.y-1).
357 tool) tree to be in a reasonably sane state adequate for testing.
365 This is a good branch to run for people who want to help out testing
369 The -rc patches are not incremental, they apply to a base 5.x kernel, just
370 like the 5.x.y patches described above. The kernel version before the -rcN
414 The -mm patches serve as a sort of proving ground for new features and other
415 experimental patches that aren't merged via a subsystem tree.
416 Once such patches has proved its worth in -mm for a while Andrew pushes
420 Both are in constant flux and contains many experimental features, a
427 even more so for -mm patches or using a Kernel from the linux-next tree).