Lines Matching full:you

12    manually, you'll almost certainly want to look at using Git instead.
17 will explain this to you.
31 To correctly apply a patch you need to know what base it was generated from
40 You apply a patch with the ``patch`` program. The patch program reads a diff
52 unlabeled patch was generated against) you should change into your kernel
58 So, if you applied a patch like this::
62 You can revert (undo) it like this::
78 If you just want to be able to follow the examples below and don't want to
79 know of more than one way to use patch, then you can stop reading this
87 If your patch file is compressed with gzip or xz and you don't want to
88 uncompress it before applying it, then you can feed it to patch like this
94 If you wish to uncompress the patch file by hand first before applying it
95 (what I assume you've done in the examples below), then you simply run
101 Which will leave you with a plain text patch-x.y.z file that you can feed to
102 patch via stdin or the ``-i`` argument, as you prefer.
134 it'll tell you about it by saying the patch applied with **fuzz**.
135 You should be wary of such changes since even though patch probably got it
140 outright and leaves a file with a ``.rej`` extension (a reject file). You can
141 read this file to see exactly what change couldn't be applied, so you can
142 go fix it up by hand if you wish.
144 If you don't have any third-party patches applied to your kernel source, but
145 only patches from kernel.org and you apply the patches in the correct order,
146 and have made no modifications yourself to the source files, then you should
147 never see a fuzz or reject message from patch. If you do see such messages
149 patch file is corrupted in some way. In that case you should probably try
150 re-downloading the patch and if things are still not OK then you'd be advised
156 find a file to be patched. Most likely you forgot to specify -p1 or you are
157 in the wrong directory. Less often, you'll find patches that need to be
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
171 different kernel version than the one you are trying to patch.
173 If you get a message like ``Hunk #3 FAILED at 2387.``, then it means that the
176 caused the patch to fail and also a ``.orig`` file showing you the original
179 If you get ``Reversed (or previously applied) patch detected!  Assume -R? [n]``
183 If you actually did apply this patch previously and you just re-applied it
184 in error, then just say [n]o and abort this patch. If you applied this patch
186 then you can say [**y**]es here to make patch revert it for you.
194 sense of the file you fed to it. Either your download is broken, you tried to
196 file that you are using has been mangled by a mail client or mail transfer
201 As I already mentioned above, these errors should never happen if you apply
203 So if you get these errors with kernel.org patches then you should probably
204 assume that either your patch file or your tree is broken and I'd advise you
205 to start over with a fresh download of a full kernel tree and the patch you
215 You can use the ``interdiff`` program (http://cyberelk.net/tim/patchutils/) to
219 This will let you move from something like 5.7.2 to 5.7.3 in a single
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
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
277 To apply a patch moving from 5.6 to 5.7, you'd do the following (note
279 base 5.x kernel -- if you need to move from 5.x.y to 5.x+1 you need to
326 source you have to first back out the 5.7.2 patch (so you are left with a
359 These kernels are not stable and you should expect occasional breakage if
360 you intend to run them. This is however the most stable of the main
426 sure you have up-to-date backups -- that goes for any experimental kernel but
439 I hope you are now clear on how to apply the various patches and help testing
442 Thank you's to Randy Dunlap, Rolf Eike Beer, Linus Torvalds, Bodo Eggert,