Lines Matching refs:you

12 will explain this to you.
24 To correctly apply a patch you need to know what base it was generated from
43 unlabeled patch was generated against) you should change into your kernel
48 So, if you applied a patch like this:
63 If you just want to be able to follow the examples below and don't want to
64 know of more than one way to use patch, then you can stop reading this
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
77 If you wish to uncompress the patch file by hand first before applying it
78 (what I assume you've done in the examples below), then you simply run
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.
114 it'll tell you about it by saying the patch applied with 'fuzz'.
121 read this file to see exactly what change couldn't be applied, so you can
122 go fix it up by hand if you wish.
124 If you don't have any third-party patches applied to your kernel source, but
125 only patches from kernel.org and you apply the patches in the correct order,
126 and have made no modifications yourself to the source files, then you should
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
136 find a file to be patched. Most likely you forgot to specify -p1 or you are
137 in the wrong directory. Less often, you'll find patches that need to be
142 If you get "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." or a
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.
151 If you get a message like "Hunk #3 FAILED at 2387.", then it means that the
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]"
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.
170 the file you fed to it. Either your download is broken, you tried to feed
172 file that you are using has been mangled by a mail client or mail transfer
177 As I already mentioned above, these errors should never happen if you apply
179 So if you get these errors with kernel.org patches then you should probably
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
192 This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single
193 step. The -z flag to interdiff will even let you feed it patches in gzip or
197 Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step:
200 Although interdiff may save you a step or two you are generally advised to
231 In place of ftp.kernel.org you can use ftp.cc.kernel.org, where cc is a
232 country code. This way you'll be downloading from a mirror site that's most
233 likely geographically closer to you, resulting in faster downloads for you,
248 To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
250 base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to
292 source you have to first back out the 2.6.12.2 patch (so you are left with a
310 These kernels are not stable and you should expect occasional breakage if
311 you intend to run them. This is however the most stable of the main
361 a base 2.6.x-rc kernel -- you can see which from their name.
409 sure you have up-to-date backups -- that goes for any experimental kernel but
448 I hope you are now clear on how to apply the various patches and help testing
451 Thank you's to Randy Dunlap, Rolf Eike Beer, Linus Torvalds, Bodo Eggert,