Lines Matching +full:broken +full:- +full:turn +full:- +full:around
54 in the patch file when applying it (the ``-p1`` argument to ``patch`` does
57 To revert a previously applied patch, use the -R argument to patch.
60 patch -p1 < ../patch-x.y.z
64 patch -R -p1 < ../patch-x.y.z
76 patch -p1 < path/to/patch-x.y.z
82 Patch can also get the name of the file to use via the -i argument, like
85 patch -p1 -i path/to/patch-x.y.z
91 xzcat path/to/patch-x.y.z.xz | patch -p1
92 bzcat path/to/patch-x.y.z.gz | patch -p1
96 gunzip or xz on the file -- like this::
98 gunzip patch-x.y.z.gz
99 xz -d patch-x.y.z.xz
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.
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
107 what would happen, but doesn't actually make any changes. Finally ``--verbose``
118 around the bits being modified matches the context provided in the patch are
144 If you don't have any third-party patches applied to your kernel source, but
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
158 applied with ``-p0`` instead of ``-p1`` (reading the patch file should reveal if
159 this is the case -- if so, then this is an error by the person who created
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
185 previously and actually intended to revert it, but forgot to specify -R,
194 sense of the file you fed to it. Either your download is broken, you tried to
204 assume that either your patch file or your tree is broken and I'd advise you
220 step. The -z flag to interdiff will even let you feed it patches in gzip or
226 interdiff -z ../patch-5.7.2.gz ../patch-5.7.3.gz | patch -p1
248 The 5.x.y (-stable) and 5.x patches live at
252 The -rc patches are not stored on the webserver but are generated on
255 https://git.kernel.org/torvalds/p/v5.1-rc1/v5.0
257 The stable -rc patches live at
259 https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/
268 If regressions or other serious flaws are found, then a -stable fix patch
275 base 5.x kernel -- if you need to move from 5.x.y to 5.x+1 you need to
282 $ cd ~/linux-5.6 # change to kernel source dir
283 $ patch -p1 < ../patch-5.7 # apply the 5.7 patch
285 $ mv linux-5.6 linux-5.7 # rename source dir
289 $ cd ~/linux-5.6.1 # change to kernel source dir
290 $ patch -p1 -R < ../patch-5.6.1 # revert the 5.6.1 patch
292 $ patch -p1 < ../patch-5.7 # apply new 5.7 patch
294 $ mv linux-5.6.1 linux-5.7 # rename source dir
300 Kernels with 3-digit versions are -stable kernels. They contain small(ish)
313 The -stable team usually do make incremental patches available as well
315 non-incremental ones below. The incremental ones can be found at
328 $ cd ~/linux-5.7.2 # change to the kernel source dir
329 $ patch -p1 -R < ../patch-5.7.2 # revert the 5.7.2 patch
330 $ patch -p1 < ../patch-5.7.3 # apply the new 5.7.3 patch
332 $ mv linux-5.7.2 linux-5.7.3 # rename the kernel source dir
334 The -rc kernels
337 These are release-candidate kernels. These are development kernels released
343 development branches and is also what will eventually turn into the next
349 stuff (such people should see the sections about -next and -mm kernels below).
351 The -rc patches are not incremental, they apply to a base 5.x kernel, just
352 like the 5.x.y patches described above. The kernel version before the -rcN
353 suffix denotes the version of the kernel that this -rc kernel will eventually
354 turn into.
356 So, 5.8-rc5 means that this is the fifth release candidate for the 5.8
361 # first an example of moving from 5.7 to 5.8-rc3
363 $ cd ~/linux-5.7 # change to the 5.7 source dir
364 $ patch -p1 < ../patch-5.8-rc3 # apply the 5.8-rc3 patch
366 $ mv linux-5.7 linux-5.8-rc3 # rename the source dir
368 # now let's move from 5.8-rc3 to 5.8-rc5
370 $ cd ~/linux-5.8-rc3 # change to the 5.8-rc3 dir
371 $ patch -p1 -R < ../patch-5.8-rc3 # revert the 5.8-rc3 patch
372 $ patch -p1 < ../patch-5.8-rc5 # apply the new 5.8-rc5 patch
374 $ mv linux-5.8-rc3 linux-5.8-rc5 # rename the source dir
376 # finally let's try and move from 5.7.3 to 5.8-rc5
378 $ cd ~/linux-5.7.3 # change to the kernel source dir
379 $ patch -p1 -R < ../patch-5.7.3 # revert the 5.7.3 patch
380 $ patch -p1 < ../patch-5.8-rc5 # apply new 5.8-rc5 patch
382 $ mv linux-5.7.3 linux-5.8-rc5 # rename the kernel source dir
385 The -mm patches and the linux-next tree
388 The -mm patches are experimental patches released by Andrew Morton.
390 In the past, -mm tree were used to also test subsystem patches, but this
392 `linux-next <https://www.kernel.org/doc/man-pages/linux-next.html>`
393 tree. The Subsystem maintainers push their patches first to linux-next,
396 The -mm patches serve as a sort of proving ground for new features and other
398 Once such patches has proved its worth in -mm for a while Andrew pushes
401 The linux-next tree is daily updated, and includes the -mm patches.
408 sure you have up-to-date backups -- that goes for any experimental kernel but
409 even more so for -mm patches or using a Kernel from the linux-next tree).
411 Testing of -mm patches and linux-next is greatly appreciated since the whole
416 But testers of -mm and linux-next should be aware that breakages are