Re: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:08, Linus Torvalds wrote: > > On Wed, 3 Aug 2005, Jesper Juhl wrote: > > > > Here's an updated version of my document that attempts to give a short > > explanation of the various kernel trees and how to apply their patches. > > It incorporates all the feedback I've gotten (thanks guys). > > Can we have more whitespace? > [snip] The new version of the document below has more whitespace and also incorporates a lot of feedback I've gotten since the last version I posted. I think this is getting close to the point where it could be included. What do you say? Add a new document describing the major kernel trees and how to apply their patches. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- Documentation/applying-patches.txt | 439 + 1 files changed, 439 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-06 00:46:17.0 +0200 @@ -0,0 +1,439 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + +In addition to explaining how to apply and revert patches, a brief +description of the different kernel trees (and examples of how to apply +their specific patches) is also provided. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata or be possible to deduce +from the filename. + + +How do I apply or revert a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. + +Patches for the Linux kernel are generated relative to the parent directory +holding the kernel source dir. + +This means that paths to files inside the patch file contain the name of the +kernel source directories it was generated against (or some other directory +names like "a/" and "b/"). +Since this is unlikely to match the name of the kernel source dir on your +local machine (but is often useful info to see what version an otherwise +unlabeled patch was generated against) you should change into your kernel +source directory and then strip the first element of the path from filenames +in the patch file when applying it (the -p1 argument to `patch' does this). + +To revert a previously applied patch, use the -R argument to patch. +So, if you applied a patch like this: + patch -p1 < ../patch-x.y.z + +You can revert (undo) it like this: + patch -R -p1 < ../patch-x.y.z + + +How do I feed a patch/diff file to `patch'? +--- + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 < path/to/patch-x.y.z + +If you just want to be able to follow the examples below and don't want to +know of more than one way to use patch, then you can stop reading this +section here. + +Patch can also get the name of the file to use via the -i argument, like +this: + patch -p1 -i path/to/patch-x.y.z + +If your patch file is compressed with gzip or bzip2 and you don't want to +uncompress it before applying it, then you can feed it to patch like this +instead: + zcat path/to/patch-x.y.z.gz | patch -p1 + bzcat path/to/patch-x.y.z.bz2 | patch -p1 + +If you wish to uncompress the patch file by hand first before applying it +(what I assume you've done in the examples below), then you simply run +gunzip or bunzip2 on the file - like this: + gunzip patch-x.y.z.gz + bunzip2 patch-x.y.z.bz2 + +Which will leave you with a plain text patch-x.y.z file that you can feed to +patch via stdin or the -i argument, as you prefer. + +A few other nice arguments for patch are -s which causes patch to be silent +except for errors which is nice to prevent errors from scrolling out of the +screen too fast, and --dry-run which causes patch to just print a listing of +what would happen, but doesn't actually make any changes. Finally --verbose +tells patch to print more information about the work being done. + + +Common errors when patching +--- + When patch applies a
Re: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:08, Linus Torvalds wrote: On Wed, 3 Aug 2005, Jesper Juhl wrote: Here's an updated version of my document that attempts to give a short explanation of the various kernel trees and how to apply their patches. It incorporates all the feedback I've gotten (thanks guys). Can we have more whitespace? [snip] The new version of the document below has more whitespace and also incorporates a lot of feedback I've gotten since the last version I posted. I think this is getting close to the point where it could be included. What do you say? Add a new document describing the major kernel trees and how to apply their patches. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/applying-patches.txt | 439 + 1 files changed, 439 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-06 00:46:17.0 +0200 @@ -0,0 +1,439 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + +In addition to explaining how to apply and revert patches, a brief +description of the different kernel trees (and examples of how to apply +their specific patches) is also provided. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata or be possible to deduce +from the filename. + + +How do I apply or revert a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. + +Patches for the Linux kernel are generated relative to the parent directory +holding the kernel source dir. + +This means that paths to files inside the patch file contain the name of the +kernel source directories it was generated against (or some other directory +names like a/ and b/). +Since this is unlikely to match the name of the kernel source dir on your +local machine (but is often useful info to see what version an otherwise +unlabeled patch was generated against) you should change into your kernel +source directory and then strip the first element of the path from filenames +in the patch file when applying it (the -p1 argument to `patch' does this). + +To revert a previously applied patch, use the -R argument to patch. +So, if you applied a patch like this: + patch -p1 ../patch-x.y.z + +You can revert (undo) it like this: + patch -R -p1 ../patch-x.y.z + + +How do I feed a patch/diff file to `patch'? +--- + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 path/to/patch-x.y.z + +If you just want to be able to follow the examples below and don't want to +know of more than one way to use patch, then you can stop reading this +section here. + +Patch can also get the name of the file to use via the -i argument, like +this: + patch -p1 -i path/to/patch-x.y.z + +If your patch file is compressed with gzip or bzip2 and you don't want to +uncompress it before applying it, then you can feed it to patch like this +instead: + zcat path/to/patch-x.y.z.gz | patch -p1 + bzcat path/to/patch-x.y.z.bz2 | patch -p1 + +If you wish to uncompress the patch file by hand first before applying it +(what I assume you've done in the examples below), then you simply run +gunzip or bunzip2 on the file - like this: + gunzip patch-x.y.z.gz + bunzip2 patch-x.y.z.bz2 + +Which will leave you with a plain text patch-x.y.z file that you can feed to +patch via stdin or the -i argument, as you prefer. + +A few other nice arguments for patch are -s which causes patch to be silent +except for errors which is nice to prevent errors from scrolling out of the +screen too fast, and --dry-run which causes patch to just print a listing of +what would happen, but doesn't actually make any changes. Finally --verbose +tells patch to print more information about the work being done. + + +Common errors when patching +--- + When patch applies a patch file it attempts
Re: Documentation - how to apply patches for various trees
Hi! > How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite > frequently asked question on LKML and elsewhere. > Since so many people seem to be confused by this I gathered it ought to be > properly documented once and for all so we a) get more people testing those > trees and b) get asked this question less often. > So, I sat down and wrote such a document. > > Below is a patch to add a new file "applying-patches.txt" to Documentation/ > This document describes each of the trees and gives examples on how to apply > the various patches. > > Looking forward to your feedback (and possible inclusion). > > I guess this document could also be placed somewhere on kernel.org and linked > to from the front page so that people downloading the various patches will > have this information available at their fingertips. Perhaps including ketchup in linux/scripts makes sense? Places for download slowly change so it needs to be kept up-to-date, and it is *very* nice to use... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
Jesper Juhl wrote: >+The 2.6.x.y (-stable) and 2.6.x patches live at >+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ >+ >+The -rc patches live at >+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ >+ >+The -git patches live at >+ ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ >+ >+The -mm kernels live at >+ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ ^ To be consistent you must add a space here. Eike pgp0fJOY0dFcA.pgp Description: PGP signature
Re: Documentation - how to apply patches for various trees
Jesper Juhl wrote: +The 2.6.x.y (-stable) and 2.6.x patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ + +The -rc patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ + +The -git patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ + +The -mm kernels live at +ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ ^ To be consistent you must add a space here. Eike pgp0fJOY0dFcA.pgp Description: PGP signature
Re: Documentation - how to apply patches for various trees
Hi! How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite frequently asked question on LKML and elsewhere. Since so many people seem to be confused by this I gathered it ought to be properly documented once and for all so we a) get more people testing those trees and b) get asked this question less often. So, I sat down and wrote such a document. Below is a patch to add a new file applying-patches.txt to Documentation/ This document describes each of the trees and gives examples on how to apply the various patches. Looking forward to your feedback (and possible inclusion). I guess this document could also be placed somewhere on kernel.org and linked to from the front page so that people downloading the various patches will have this information available at their fingertips. Perhaps including ketchup in linux/scripts makes sense? Places for download slowly change so it needs to be kept up-to-date, and it is *very* nice to use... Pavel -- teflon -- maybe it is a trademark, but it should not be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
Hi Jesper, On Wed, 3 Aug 2005 23:28:06 +0200, Jesper Juhl <[EMAIL PROTECTED]> wrote: I like it, just a little concerned about confusing new user with too many alternative patching methods up front... >+ This (as usual with Linux and other UNIX like operating systems) can be >+done in several different ways. >+In all the examples below I feed the file (in uncompressed form) to patch >+via stdin using the following syntax: >+ patch -p1 < path/to/patch-x.y.z >+ >+but patch can also get the name of the file to use via the -i argument, like >+this: >+ patch -p1 -i path/to/patch-x.y.z >+ >+If your patch file is compressed with gzip or bzip2 and you don't want to >+uncompress it before applying it, then you can feed it to patch like this >+instead: cat path/to/patch-x.y.z.gz | patch -p1 >+ zcat path/to/patch-x.y.z.gz | patch -p1 >+ bzcat path/to/patch-x.y.z.bz2 | patch -p1 In a howto, I'd prefer _one_ consistent method to reduce the reader's confusion. The above trio of commands serves me well over many years' kernel patching, and it is trivial to up-arrow, home, change compression method, retry ... when my fingers get ahead of my mind :) Experience users recognise the intent of the commands and use their favourite method instead, almost without thinking. Spelling: s/uncompression/decompression/ s/adviced/advised/ s/bandwith/bandwidth/ Cheers, Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wed, Aug 03, 2005 Jesper Juhl wrote: > +How do I feed a patch/diff file to `patch'? > +--- > + This (as usual with Linux and other UNIX like operating systems) can be > +done in several different ways. > +In all the examples below I feed the file (in uncompressed form) to patch > +via stdin using the following syntax: > + patch -p1 < path/to/patch-x.y.z I think you should mention the -s flag. Given the size of an average kernel patch it is otherwise very likely that errors scroll away unnoticed. OTOH you might also want to add a mention of lsdiff and diffstat. Johannes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:46, Bodo Eggert wrote: > On Wed, 3 Aug 2005, Jesper Juhl wrote: > > > +What is a patch? > > > +To correctly apply a patch you need to know what base it was generated from > > +and what new version the patch will change the source tree into. These > > +should both be present in the patch file metadata. > > This is usurally not true for kernel patches, the directories are mostly > named a and b. You can however deduce the to-bepatched version and the > patched version from the filename. > hmm, I'd say the patch filename could be considered "metadata" as well. > [...] > > Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion && patch -p1) > yes, there are many ways, impossible to list them all, but this might be a good example to add, just to show application of several patches in one go. > I need to get some sleep now, but I'll add most of your text to the document tomorrow and post a new patch. Thanks! -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wed, 3 Aug 2005, Jesper Juhl wrote: > +What is a patch? > +To correctly apply a patch you need to know what base it was generated from > +and what new version the patch will change the source tree into. These > +should both be present in the patch file metadata. This is usurally not true for kernel patches, the directories are mostly named a and b. You can however deduce the to-bepatched version and the patched version from the filename. > +How do I apply a patch? > +--- > + You apply a patch with the `patch' program. The patch program reads a diff > +(or patch) file and makes the changes to the source tree described in it. > +Patches for the Linux kernel are generated relative to the parent directory > +holding the kernel source dir. This means that paths to files inside the > +patch file contain the name of the kernel source directories it was > +generated against - since this is unlikely to match the name of the kernel > +source dir on your local machine (but is often useful info to see what > +version an otherwise unlabeled patch was generated against) Same issue. > you should > +change into your kernel source directory and then strip the first element of > +the path from filenames in the patch file when applying it (the -p1 argument > +to `patch' does this). To revert a previously applied patch, use the -R > +argument to patch. > +How do I feed a patch/diff file to `patch'? [...] Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion && patch -p1) Finding out if a patch applied correctly --- A quick check is to search for .rej files. Unfortunately some errors How do I undo a patch? --- You can undo a patch by supplying the -R switch to patch. If you patched using zcat ../patch.gz | patch -p1, zcat ../patch.gz | patch -Rp1 will undo the changes as long as the patch applied correctly. Common errors while patching --- "File to patch:" Patch could not find a file to be patched. Most probably you forgot to use -p1 or you're in the wrong directory. Less often, you'll find patches that need to be applied with -p0 instead (you can't just omit -p0!).^^^ ^ [IIRC] Sometimes this is the result of an incomplete tarball, a out-of-space error while unpacking or a fsck. "Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines)." The patch was applied, but it might be applied to the wrong place because you patched the "wrong" source. The result might not work correctly. "Hunk #3 FAILED at 2387." The patch could not be applied correctly. This is usurally fatal, except if you apply external patches to the stable series (e.g. to 2.6.23.42 instead of 2.6.23) and the reject is in the toplevel Makefile. (You'll have to manually edit the Makefile and change the version string as recorded in Makefile.rej) If you apply more than one external patch, the same thing will happen, but there is no guarantee for a working kernel (the changes may bite each other). You can most likely recover the source tree by undoing the patch and removing the .rej and .orig files. YMMV. "Reversed (or previously applied) patch detected! Assume -R? [n]" Either you really applied the patch before, or the patch is for some other source. If this is not the very first message, the source is most likely unusable by now. "patch: unexpected end of file in patch" Your download is broken. Re-get the file. -- To steal information from a person is called plagiarism. To steal information from the enemy is called gathering intelligence. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:08, Linus Torvalds wrote: > > On Wed, 3 Aug 2005, Jesper Juhl wrote: > > > > Here's an updated version of my document that attempts to give a short > > explanation of the various kernel trees and how to apply their patches. > > It incorporates all the feedback I've gotten (thanks guys). > > Can we have more whitespace? > Certainly. > And since we have a single empty line implying paragraph breaks, feel free > to use multiple empty lines to imply "bigger" breaks (you seem to do this > already). > Here's an updated version with more whitespace. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- Documentation/applying-patches.txt | 323 + 1 files changed, 323 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-03 23:23:24.0 +0200 @@ -0,0 +1,323 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata. + + +How do I apply a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. + +Patches for the Linux kernel are generated relative to the parent directory +holding the kernel source dir. + +This means that paths to files inside the patch file contain the name of the +kernel source directories it was generated against. +Since this is unlikely to match the name of the kernel source dir on your +local machine (but is often useful info to see what version an otherwise +unlabeled patch was generated against) you should change into your kernel +source directory and then strip the first element of the path from filenames +in the patch file when applying it (the -p1 argument to `patch' does this). +To revert a previously applied patch, use the -R argument to patch. + + +How do I feed a patch/diff file to `patch'? +--- + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 < path/to/patch-x.y.z + +but patch can also get the name of the file to use via the -i argument, like +this: + patch -p1 -i path/to/patch-x.y.z + +If your patch file is compressed with gzip or bzip2 and you don't want to +uncompress it before applying it, then you can feed it to patch like this +instead: + zcat path/to/patch-x.y.z.gz | patch -p1 + bzcat path/to/patch-x.y.z.bz2 | patch -p1 + +If you wish to uncompress the patch file by hand first before applying it +(what I assume you've done in the examples below), then you simply run +gunzip or bunzip2 on the file - like this: + gunzip patch-x.y.z.gz + bunzip2 patch-x.y.z.bz2 + +Which will leave you with a plain text patch-x.y.z file that you can feed to +patch via stdin or the -i argument, as you prefer. + + +Are there any alternatives to `patch'? +--- + Yes there are alternatives. You can use the `interdiff' program +(http://cyberelk.net/tim/patchutils/) to generate a patch representing the +differences between two patches and then apply the result. +This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single +step. The -z flag to interdiff will even let you feed it patches in gzip or +bzip2 compressed form directly without the use of zcat or bzcat or manual +uncompression. + +Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step: + interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 + +Although interdiff may save you a step or two you are generally adviced to +do the additional steps since interdiff can get things wrong in some cases. + + Another alternative is `ketchup', which is a python script for automatic +downloading and applying of patches (http://www.selenic.com/ketchup/). + + +Where can I download the patches? +--- +The patches are available at http://kernel.org/ +Most recent patches are linked from the front page, but they also have +specific homes. + +The 2.6.x.y
Re: Documentation - how to apply patches for various trees
On Wed, 3 Aug 2005, Jesper Juhl wrote: > > Here's an updated version of my document that attempts to give a short > explanation of the various kernel trees and how to apply their patches. > It incorporates all the feedback I've gotten (thanks guys). Can we have more whitespace? You either have very long paragraphs, or no whitespace between them: I can't quite decide which one. So leave an empty line between paragraphs (and if you already do, you need to split them ;) because it's very tiring to not have a nice break every once in the flow of text. Long paragraphs may be acceptable in fictional literary work that you read without thinking about what you're reading. There you get into the "flow" of the text, and you hopefully don't need to have very many visual breaks to keep as acnhor-points. However, the same is certainly not true in technical text, especially something like this where you're trying to explain somethign that the recipient doesn't ncessarily know. My rule of thumb is that if you don't have a new paragraph roughly every five or six lines, it's likely problematic. Maybe I have a shorter attention span than most, but I don't think so - I just find it much easier to read text that is nicely broken up, and when it's a "pure ASCII" medium the only break that works well is an empty line (possibly with indentation for further visual help - although in this context indentation tends to be used for a separate issue: examples etc, and is not good for paragraphs). And since we have a single empty line implying paragraph breaks, feel free to use multiple empty lines to imply "bigger" breaks (you seem to do this already). This email was written with an average paragraph length of 4 lines. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wed, 3 Aug 2005, Rolf Eike Beer wrote: > Jesper Juhl wrote: > > >+Where can I download the patches? > > Maybe it would be useful to once again mention that local mirrors should be > used at least for stable releases and */testing/*. > > >+The 2.6.x kernels > [...] > >+# moving from 2.6.11 to 2.6.12 > >+$ cd ~/linux-2.6.11 # change to kernel source dir > >+$ patch -p1 < ../patch-2.6.12 # apply the 2.6.12 patch > > patch also nows "-i": patch -p1 -i ../patch-2.6.12 > > More likely the user will get the patch compressed either with bzip2 or gzip, > so I think it would be useful to tell once more how to apply such a patch: > > bzcat ../patch-2.6.12.bz2 | patch -p1 > > >+The 2.6.x.y kernels > > >+$ cd ~/linux-2.6.12.2 # change into the kernel source > >dir > >+$ patch -p1 -R < ../patch-2.6.12.2 # revert the 2.6.12.2 patch > >+$ patch -p1 < ../patch-2.6.12.3 # apply the new 2.6.12.3 patch > >+$ cd .. > >+$ mv linux-2.6.12.2 linux-2.6.12.3 # rename the kernel source dir > > The better way would probably be to use interdiff. Another goodie is that > interdiff knows about -z: > > cd ~/linux-2.6.12.2 > interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 > > This should only be shown as "another way" to do so. Sometimes interdiff get's > confused and breaks things, although this is very unlikely for the stable > diffs. Another (better IMO) solution is to use 'ketchup'. It knows about all of these revisions/patches and how to download and apply them AFAIK. http://www.selenic.com/ketchup/ > >+The -mm kernels > > >+ These kernels in > >+ addition to all the other experimental patches they contain usually also > >+ contain any changes in the mainline -git kernels available at the time of > >+ release. > > These two "contain"'s that close to each user are likely to confuse. In a > German text I would but a comma before "in addition" and behind the first > "contain", don't know what the rules for this are in English. > > Eike -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
Jesper Juhl wrote: >+Where can I download the patches? Maybe it would be useful to once again mention that local mirrors should be used at least for stable releases and */testing/*. >+The 2.6.x kernels [...] >+# moving from 2.6.11 to 2.6.12 >+$ cd ~/linux-2.6.11 # change to kernel source dir >+$ patch -p1 < ../patch-2.6.12 # apply the 2.6.12 patch patch also nows "-i": patch -p1 -i ../patch-2.6.12 More likely the user will get the patch compressed either with bzip2 or gzip, so I think it would be useful to tell once more how to apply such a patch: bzcat ../patch-2.6.12.bz2 | patch -p1 >+The 2.6.x.y kernels >+$ cd ~/linux-2.6.12.2 # change into the kernel source dir >+$ patch -p1 -R < ../patch-2.6.12.2# revert the 2.6.12.2 patch >+$ patch -p1 < ../patch-2.6.12.3 # apply the new 2.6.12.3 patch >+$ cd .. >+$ mv linux-2.6.12.2 linux-2.6.12.3# rename the kernel source dir The better way would probably be to use interdiff. Another goodie is that interdiff knows about -z: cd ~/linux-2.6.12.2 interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 This should only be shown as "another way" to do so. Sometimes interdiff get's confused and breaks things, although this is very unlikely for the stable diffs. >+The -mm kernels >+ These kernels in >+ addition to all the other experimental patches they contain usually also >+ contain any changes in the mainline -git kernels available at the time of >+ release. These two "contain"'s that close to each user are likely to confuse. In a German text I would but a comma before "in addition" and behind the first "contain", don't know what the rules for this are in English. Eike pgpO3TPl0gsRj.pgp Description: PGP signature
Re: Documentation - how to apply patches for various trees
Jesper Juhl wrote: +Where can I download the patches? Maybe it would be useful to once again mention that local mirrors should be used at least for stable releases and */testing/*. +The 2.6.x kernels [...] +# moving from 2.6.11 to 2.6.12 +$ cd ~/linux-2.6.11 # change to kernel source dir +$ patch -p1 ../patch-2.6.12 # apply the 2.6.12 patch patch also nows -i: patch -p1 -i ../patch-2.6.12 More likely the user will get the patch compressed either with bzip2 or gzip, so I think it would be useful to tell once more how to apply such a patch: bzcat ../patch-2.6.12.bz2 | patch -p1 +The 2.6.x.y kernels +$ cd ~/linux-2.6.12.2 # change into the kernel source dir +$ patch -p1 -R ../patch-2.6.12.2# revert the 2.6.12.2 patch +$ patch -p1 ../patch-2.6.12.3 # apply the new 2.6.12.3 patch +$ cd .. +$ mv linux-2.6.12.2 linux-2.6.12.3# rename the kernel source dir The better way would probably be to use interdiff. Another goodie is that interdiff knows about -z: cd ~/linux-2.6.12.2 interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 This should only be shown as another way to do so. Sometimes interdiff get's confused and breaks things, although this is very unlikely for the stable diffs. +The -mm kernels + These kernels in + addition to all the other experimental patches they contain usually also + contain any changes in the mainline -git kernels available at the time of + release. These two contain's that close to each user are likely to confuse. In a German text I would but a comma before in addition and behind the first contain, don't know what the rules for this are in English. Eike pgpO3TPl0gsRj.pgp Description: PGP signature
Re: Documentation - how to apply patches for various trees
On Wed, 3 Aug 2005, Rolf Eike Beer wrote: Jesper Juhl wrote: +Where can I download the patches? Maybe it would be useful to once again mention that local mirrors should be used at least for stable releases and */testing/*. +The 2.6.x kernels [...] +# moving from 2.6.11 to 2.6.12 +$ cd ~/linux-2.6.11 # change to kernel source dir +$ patch -p1 ../patch-2.6.12 # apply the 2.6.12 patch patch also nows -i: patch -p1 -i ../patch-2.6.12 More likely the user will get the patch compressed either with bzip2 or gzip, so I think it would be useful to tell once more how to apply such a patch: bzcat ../patch-2.6.12.bz2 | patch -p1 +The 2.6.x.y kernels +$ cd ~/linux-2.6.12.2 # change into the kernel source dir +$ patch -p1 -R ../patch-2.6.12.2 # revert the 2.6.12.2 patch +$ patch -p1 ../patch-2.6.12.3 # apply the new 2.6.12.3 patch +$ cd .. +$ mv linux-2.6.12.2 linux-2.6.12.3 # rename the kernel source dir The better way would probably be to use interdiff. Another goodie is that interdiff knows about -z: cd ~/linux-2.6.12.2 interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 This should only be shown as another way to do so. Sometimes interdiff get's confused and breaks things, although this is very unlikely for the stable diffs. Another (better IMO) solution is to use 'ketchup'. It knows about all of these revisions/patches and how to download and apply them AFAIK. http://www.selenic.com/ketchup/ +The -mm kernels + These kernels in + addition to all the other experimental patches they contain usually also + contain any changes in the mainline -git kernels available at the time of + release. These two contain's that close to each user are likely to confuse. In a German text I would but a comma before in addition and behind the first contain, don't know what the rules for this are in English. Eike -- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wed, 3 Aug 2005, Jesper Juhl wrote: Here's an updated version of my document that attempts to give a short explanation of the various kernel trees and how to apply their patches. It incorporates all the feedback I've gotten (thanks guys). Can we have more whitespace? You either have very long paragraphs, or no whitespace between them: I can't quite decide which one. So leave an empty line between paragraphs (and if you already do, you need to split them ;) because it's very tiring to not have a nice break every once in the flow of text. Long paragraphs may be acceptable in fictional literary work that you read without thinking about what you're reading. There you get into the flow of the text, and you hopefully don't need to have very many visual breaks to keep as acnhor-points. However, the same is certainly not true in technical text, especially something like this where you're trying to explain somethign that the recipient doesn't ncessarily know. My rule of thumb is that if you don't have a new paragraph roughly every five or six lines, it's likely problematic. Maybe I have a shorter attention span than most, but I don't think so - I just find it much easier to read text that is nicely broken up, and when it's a pure ASCII medium the only break that works well is an empty line (possibly with indentation for further visual help - although in this context indentation tends to be used for a separate issue: examples etc, and is not good for paragraphs). And since we have a single empty line implying paragraph breaks, feel free to use multiple empty lines to imply bigger breaks (you seem to do this already). This email was written with an average paragraph length of 4 lines. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:08, Linus Torvalds wrote: On Wed, 3 Aug 2005, Jesper Juhl wrote: Here's an updated version of my document that attempts to give a short explanation of the various kernel trees and how to apply their patches. It incorporates all the feedback I've gotten (thanks guys). Can we have more whitespace? Certainly. snip long explanation, which makes sense, of why shorter paragraphs and more whitespace is good And since we have a single empty line implying paragraph breaks, feel free to use multiple empty lines to imply bigger breaks (you seem to do this already). Here's an updated version with more whitespace. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/applying-patches.txt | 323 + 1 files changed, 323 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-03 23:23:24.0 +0200 @@ -0,0 +1,323 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata. + + +How do I apply a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. + +Patches for the Linux kernel are generated relative to the parent directory +holding the kernel source dir. + +This means that paths to files inside the patch file contain the name of the +kernel source directories it was generated against. +Since this is unlikely to match the name of the kernel source dir on your +local machine (but is often useful info to see what version an otherwise +unlabeled patch was generated against) you should change into your kernel +source directory and then strip the first element of the path from filenames +in the patch file when applying it (the -p1 argument to `patch' does this). +To revert a previously applied patch, use the -R argument to patch. + + +How do I feed a patch/diff file to `patch'? +--- + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 path/to/patch-x.y.z + +but patch can also get the name of the file to use via the -i argument, like +this: + patch -p1 -i path/to/patch-x.y.z + +If your patch file is compressed with gzip or bzip2 and you don't want to +uncompress it before applying it, then you can feed it to patch like this +instead: + zcat path/to/patch-x.y.z.gz | patch -p1 + bzcat path/to/patch-x.y.z.bz2 | patch -p1 + +If you wish to uncompress the patch file by hand first before applying it +(what I assume you've done in the examples below), then you simply run +gunzip or bunzip2 on the file - like this: + gunzip patch-x.y.z.gz + bunzip2 patch-x.y.z.bz2 + +Which will leave you with a plain text patch-x.y.z file that you can feed to +patch via stdin or the -i argument, as you prefer. + + +Are there any alternatives to `patch'? +--- + Yes there are alternatives. You can use the `interdiff' program +(http://cyberelk.net/tim/patchutils/) to generate a patch representing the +differences between two patches and then apply the result. +This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single +step. The -z flag to interdiff will even let you feed it patches in gzip or +bzip2 compressed form directly without the use of zcat or bzcat or manual +uncompression. + +Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step: + interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1 + +Although interdiff may save you a step or two you are generally adviced to +do the additional steps since interdiff can get things wrong in some cases. + + Another alternative is `ketchup', which is a python script for automatic +downloading and applying of patches (http://www.selenic.com/ketchup/). + + +Where can I download the patches? +--- +The patches are available at http://kernel.org/ +Most recent patches are linked
Re: Documentation - how to apply patches for various trees
On Wed, 3 Aug 2005, Jesper Juhl wrote: +What is a patch? +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata. This is usurally not true for kernel patches, the directories are mostly named a and b. You can however deduce the to-bepatched version and the patched version from the filename. +How do I apply a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. +Patches for the Linux kernel are generated relative to the parent directory +holding the kernel source dir. This means that paths to files inside the +patch file contain the name of the kernel source directories it was +generated against - since this is unlikely to match the name of the kernel +source dir on your local machine (but is often useful info to see what +version an otherwise unlabeled patch was generated against) Same issue. you should +change into your kernel source directory and then strip the first element of +the path from filenames in the patch file when applying it (the -p1 argument +to `patch' does this). To revert a previously applied patch, use the -R +argument to patch. +How do I feed a patch/diff file to `patch'? [...] Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion patch -p1) Finding out if a patch applied correctly --- A quick check is to search for .rej files. Unfortunately some errors How do I undo a patch? --- You can undo a patch by supplying the -R switch to patch. If you patched using zcat ../patch.gz | patch -p1, zcat ../patch.gz | patch -Rp1 will undo the changes as long as the patch applied correctly. Common errors while patching --- File to patch: Patch could not find a file to be patched. Most probably you forgot to use -p1 or you're in the wrong directory. Less often, you'll find patches that need to be applied with -p0 instead (you can't just omit -p0!).^^^ ^ [IIRC] Sometimes this is the result of an incomplete tarball, a out-of-space error while unpacking or a fsck. Hunk #2 succeeded at 1887 with fuzz 2 (offset 7 lines). The patch was applied, but it might be applied to the wrong place because you patched the wrong source. The result might not work correctly. Hunk #3 FAILED at 2387. The patch could not be applied correctly. This is usurally fatal, except if you apply external patches to the stable series (e.g. to 2.6.23.42 instead of 2.6.23) and the reject is in the toplevel Makefile. (You'll have to manually edit the Makefile and change the version string as recorded in Makefile.rej) If you apply more than one external patch, the same thing will happen, but there is no guarantee for a working kernel (the changes may bite each other). You can most likely recover the source tree by undoing the patch and removing the .rej and .orig files. YMMV. Reversed (or previously applied) patch detected! Assume -R? [n] Either you really applied the patch before, or the patch is for some other source. If this is not the very first message, the source is most likely unusable by now. patch: unexpected end of file in patch Your download is broken. Re-get the file. -- To steal information from a person is called plagiarism. To steal information from the enemy is called gathering intelligence. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wednesday 03 August 2005 23:46, Bodo Eggert wrote: On Wed, 3 Aug 2005, Jesper Juhl wrote: +What is a patch? +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. These +should both be present in the patch file metadata. This is usurally not true for kernel patches, the directories are mostly named a and b. You can however deduce the to-bepatched version and the patched version from the filename. hmm, I'd say the patch filename could be considered metadata as well. [...] Or: bzcat patch1 patch2 patch3 | (cd linux-oldversion patch -p1) yes, there are many ways, impossible to list them all, but this might be a good example to add, just to show application of several patches in one go. snip lots of good stuff I need to get some sleep now, but I'll add most of your text to the document tomorrow and post a new patch. Thanks! -- Jesper - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
On Wed, Aug 03, 2005 Jesper Juhl wrote: +How do I feed a patch/diff file to `patch'? +--- + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 path/to/patch-x.y.z I think you should mention the -s flag. Given the size of an average kernel patch it is otherwise very likely that errors scroll away unnoticed. OTOH you might also want to add a mention of lsdiff and diffstat. Johannes - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
Hi Jesper, On Wed, 3 Aug 2005 23:28:06 +0200, Jesper Juhl [EMAIL PROTECTED] wrote: I like it, just a little concerned about confusing new user with too many alternative patching methods up front... + This (as usual with Linux and other UNIX like operating systems) can be +done in several different ways. +In all the examples below I feed the file (in uncompressed form) to patch +via stdin using the following syntax: + patch -p1 path/to/patch-x.y.z + +but patch can also get the name of the file to use via the -i argument, like +this: + patch -p1 -i path/to/patch-x.y.z + +If your patch file is compressed with gzip or bzip2 and you don't want to +uncompress it before applying it, then you can feed it to patch like this +instead: cat path/to/patch-x.y.z.gz | patch -p1 + zcat path/to/patch-x.y.z.gz | patch -p1 + bzcat path/to/patch-x.y.z.bz2 | patch -p1 In a howto, I'd prefer _one_ consistent method to reduce the reader's confusion. The above trio of commands serves me well over many years' kernel patching, and it is trivial to up-arrow, home, change compression method, retry ... when my fingers get ahead of my mind :) Experience users recognise the intent of the commands and use their favourite method instead, almost without thinking. Spelling: s/uncompression/decompression/ s/adviced/advised/ s/bandwith/bandwidth/ Cheers, Grant. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
Thanks for this wonderful effort! Add one more to the testing team. ~Puneet Jesper Juhl wrote: Hi, How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite frequently asked question on LKML and elsewhere. Since so many people seem to be confused by this I gathered it ought to be properly documented once and for all so we a) get more people testing those trees and b) get asked this question less often. So, I sat down and wrote such a document. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Documentation - how to apply patches for various trees
Thank you! I agree that having a link off of kernel.org makes sense. Richard On 8/2/05, Jesper Juhl <[EMAIL PROTECTED]> wrote: > Hi, > > How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite > frequently asked question on LKML and elsewhere. > Since so many people seem to be confused by this I gathered it ought to be > properly documented once and for all so we a) get more people testing those > trees and b) get asked this question less often. > So, I sat down and wrote such a document. > > Below is a patch to add a new file "applying-patches.txt" to Documentation/ > This document describes each of the trees and gives examples on how to apply > the various patches. > > Looking forward to your feedback (and possible inclusion). > > I guess this document could also be placed somewhere on kernel.org and linked > to from the front page so that people downloading the various patches will > have this information available at their fingertips. > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > --- > > Documentation/applying-patches.txt | 221 > + > 1 files changed, 221 insertions(+) > > diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt > linux-2.6.13-rc5/Documentation/applying-patches.txt > --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 > 01:00:00.0 +0100 > +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-02 > 23:17:13.0 +0200 > @@ -0,0 +1,221 @@ > + > + Applying Patches To The Linux Kernel > + > + > + (Written by Jesper Juhl, August 2005) > + > + > +A frequently asked question on the Linux Kernel Mailing List is how to apply > +a patch to the kernel or, more specifically, what base kernel a patch for > +one of the many trees/branches should be applied to. Hopefully this document > +will explain this to you. > + > + > +What is a patch? > +--- > + A patch is a small text document containing a delta of changes between two > +different versions of a source tree. Patches are created with the `diff' > +program. > +To correctly apply a patch you need to know what base it was generated from > +and what new version the patch will change the source tree into. > + > + > +How do I apply a patch? > +--- > + You apply a patch with the `patch' program. The patch program reads a diff > +(or patch) file and makes the changes to the source tree described in it. > +Patches for the Linux kernel are generated releative to the parent directory > +holding the kernel source dir. This means that paths to files inside the > +patch file contain the name of the kernel source dirs it was generated > +against - since this is unlikely to match the name of the kernel source dir > +on your local machine (but is often useful info to see what version an > +otherwise unlabeled patch was generated against) you should change into your > +kernel source directory and then strip the first element of the path from > +filenames in the patch file when applying it (the -p1 argument to `patch' > +does this). To revert a previously applied patch, use the -R argument to > +patch. > + > + > +Where can I download the patches? > +--- > +The patches are available at http://kernel.org/ > +Most recent patches are linked from the front page, but they also have > +specific homes. > +The 2.6.x.y (-stable) and 2.6.x patches live at > + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ > +The -rc patches live at > + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ > +The -git patches live at > + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ > +The -mm kernels live at > +ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ > + > + > +The 2.6.x kernels > +--- > + These are the base stable releases released by Linus. The highest numbered > +release is the most recent. If regressions or other serious flaws are found > +then a -stable fix patch will be released (see below) on to of this base. > +Once a new 2.6.x base kernel is released, a patch is made available that is > +a delta between the previous 2.6.x kernel and the new one. > +To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note > +that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the > +base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to > +first revert the 2.6.x.y patch). > + > +# moving from 2.6.11 to 2.6.12 > +$ cd ~/linux-2.6.11# change to kernel source dir > +$ patch -p1 < ../patch-2.6.12 # apply the 2.6.12 patch > +$ cd .. > +$ mv linux-2.6.11 linux-2.6.12 # rename source dir > + > +# moving from 2.6.11.1 to 2.6.12 > +$ cd ~/linux-2.6.11.1 # change to kernel source dir > +$ patch -p1 -R < ../patch-2.6.11.1 # revert the 2.6.11.1 patch > + # source dir is now 2.6.11 > +$ patch -p1 < ../patch-2.6.12 # apply new 2.6.12
Re: Documentation - how to apply patches for various trees
On Tue, 2 Aug 2005, Jesper Juhl wrote: > Hi, > > Looking forward to your feedback (and possible inclusion). > > I guess this document could also be placed somewhere on kernel.org and linked > to from the front page so that people downloading the various patches will > have this information available at their fingertips. > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > --- > > Documentation/applying-patches.txt | 221 > + > 1 files changed, 221 insertions(+) > > diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt > linux-2.6.13-rc5/Documentation/applying-patches.txt > --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt 1970-01-01 > 01:00:00.0 +0100 > +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-02 > 23:17:13.0 +0200 > @@ -0,0 +1,221 @@ > + > + Applying Patches To The Linux Kernel > + > + > + (Written by Jesper Juhl, August 2005) > + > + > +A frequently asked question on the Linux Kernel Mailing List is how to apply > +a patch to the kernel or, more specifically, what base kernel a patch for > +one of the many trees/branches should be applied to. Hopefully this document > +will explain this to you. > + > + > +What is a patch? > +--- > + A patch is a small text document containing a delta of changes between two > +different versions of a source tree. Patches are created with the `diff' > +program. > +To correctly apply a patch you need to know what base it was generated from > +and what new version the patch will change the source tree into. +These should both be present in the patch file metadata. > + > + > +How do I apply a patch? > +--- > + You apply a patch with the `patch' program. The patch program reads a diff > +(or patch) file and makes the changes to the source tree described in it. > +Patches for the Linux kernel are generated releative to the parent directory relative > +holding the kernel source dir. This means that paths to files inside the > +patch file contain the name of the kernel source dirs it was generated directories > +against - since this is unlikely to match the name of the kernel source dir > +on your local machine (but is often useful info to see what version an > +otherwise unlabeled patch was generated against) you should change into your > +kernel source directory and then strip the first element of the path from > +filenames in the patch file when applying it (the -p1 argument to `patch' > +does this). To revert a previously applied patch, use the -R argument to > +patch. > + > + > +Where can I download the patches? > +--- > +The patches are available at http://kernel.org/ > +Most recent patches are linked from the front page, but they also have > +specific homes. > +The 2.6.x.y (-stable) and 2.6.x patches live at > + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ or ftp.cc.kernel.org, where cc is a country code. > +The -rc patches live at > + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ > +The -git patches live at > + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ > +The -mm kernels live at > +ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ > + > + > +The 2.6.x kernels > +--- > + These are the base stable releases released by Linus. The highest numbered > +release is the most recent. If regressions or other serious flaws are found > +then a -stable fix patch will be released (see below) on to of this base. top > +Once a new 2.6.x base kernel is released, a patch is made available that is > +a delta between the previous 2.6.x kernel and the new one. > +To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note > +that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the > +base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to > +first revert the 2.6.x.y patch). > + > +# moving from 2.6.11 to 2.6.12 > +$ cd ~/linux-2.6.11 # change to kernel source dir > +$ patch -p1 < ../patch-2.6.12# apply the 2.6.12 patch > +$ cd .. > +$ mv linux-2.6.11 linux-2.6.12 # rename source dir > + > +# moving from 2.6.11.1 to 2.6.12 > +$ cd ~/linux-2.6.11.1# change to kernel source dir > +$ patch -p1 -R < ../patch-2.6.11.1 # revert the 2.6.11.1 patch > + # source dir is now 2.6.11 > +$ patch -p1 < ../patch-2.6.12# apply new 2.6.12 patch > +$ cd .. > +$ mv linux-2.6.11.1 inux-2.6.12 # rename source dir > + > + > +The 2.6.x.y kernels > +--- > + Kernels with 4 digit versions are -stable kernels. They contain small(ish) > +critical fixes for security problems or significant regressions discovered > +in a given 2.6.x kernel. This is the recommended branch for users who
Re: Documentation - how to apply patches for various trees
On Tue, 2 Aug 2005, Jesper Juhl wrote: Hi, Looking forward to your feedback (and possible inclusion). I guess this document could also be placed somewhere on kernel.org and linked to from the front page so that people downloading the various patches will have this information available at their fingertips. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/applying-patches.txt | 221 + 1 files changed, 221 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt 1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-02 23:17:13.0 +0200 @@ -0,0 +1,221 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. +These should both be present in the patch file metadata. + + +How do I apply a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. +Patches for the Linux kernel are generated releative to the parent directory relative +holding the kernel source dir. This means that paths to files inside the +patch file contain the name of the kernel source dirs it was generated directories +against - since this is unlikely to match the name of the kernel source dir +on your local machine (but is often useful info to see what version an +otherwise unlabeled patch was generated against) you should change into your +kernel source directory and then strip the first element of the path from +filenames in the patch file when applying it (the -p1 argument to `patch' +does this). To revert a previously applied patch, use the -R argument to +patch. + + +Where can I download the patches? +--- +The patches are available at http://kernel.org/ +Most recent patches are linked from the front page, but they also have +specific homes. +The 2.6.x.y (-stable) and 2.6.x patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ or ftp.cc.kernel.org, where cc is a country code. +The -rc patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ +The -git patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ +The -mm kernels live at +ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ + + +The 2.6.x kernels +--- + These are the base stable releases released by Linus. The highest numbered +release is the most recent. If regressions or other serious flaws are found +then a -stable fix patch will be released (see below) on to of this base. top +Once a new 2.6.x base kernel is released, a patch is made available that is +a delta between the previous 2.6.x kernel and the new one. +To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note +that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the +base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to +first revert the 2.6.x.y patch). + +# moving from 2.6.11 to 2.6.12 +$ cd ~/linux-2.6.11 # change to kernel source dir +$ patch -p1 ../patch-2.6.12# apply the 2.6.12 patch +$ cd .. +$ mv linux-2.6.11 linux-2.6.12 # rename source dir + +# moving from 2.6.11.1 to 2.6.12 +$ cd ~/linux-2.6.11.1# change to kernel source dir +$ patch -p1 -R ../patch-2.6.11.1 # revert the 2.6.11.1 patch + # source dir is now 2.6.11 +$ patch -p1 ../patch-2.6.12# apply new 2.6.12 patch +$ cd .. +$ mv linux-2.6.11.1 inux-2.6.12 # rename source dir + + +The 2.6.x.y kernels +--- + Kernels with 4 digit versions are -stable kernels. They contain small(ish) +critical fixes for security problems or significant regressions discovered +in a given 2.6.x kernel. This is the recommended branch for users who want +the most recent stable kernel and are not interrested in helping test
Re: Documentation - how to apply patches for various trees
Thank you! I agree that having a link off of kernel.org makes sense. Richard On 8/2/05, Jesper Juhl [EMAIL PROTECTED] wrote: Hi, How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite frequently asked question on LKML and elsewhere. Since so many people seem to be confused by this I gathered it ought to be properly documented once and for all so we a) get more people testing those trees and b) get asked this question less often. So, I sat down and wrote such a document. Below is a patch to add a new file applying-patches.txt to Documentation/ This document describes each of the trees and gives examples on how to apply the various patches. Looking forward to your feedback (and possible inclusion). I guess this document could also be placed somewhere on kernel.org and linked to from the front page so that people downloading the various patches will have this information available at their fingertips. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- Documentation/applying-patches.txt | 221 + 1 files changed, 221 insertions(+) diff -uP linux-2.6.13-rc5-orig/Documentation/applying-patches.txt linux-2.6.13-rc5/Documentation/applying-patches.txt --- linux-2.6.13-rc5-orig/Documentation/applying-patches.txt1970-01-01 01:00:00.0 +0100 +++ linux-2.6.13-rc5/Documentation/applying-patches.txt 2005-08-02 23:17:13.0 +0200 @@ -0,0 +1,221 @@ + + Applying Patches To The Linux Kernel + + + (Written by Jesper Juhl, August 2005) + + +A frequently asked question on the Linux Kernel Mailing List is how to apply +a patch to the kernel or, more specifically, what base kernel a patch for +one of the many trees/branches should be applied to. Hopefully this document +will explain this to you. + + +What is a patch? +--- + A patch is a small text document containing a delta of changes between two +different versions of a source tree. Patches are created with the `diff' +program. +To correctly apply a patch you need to know what base it was generated from +and what new version the patch will change the source tree into. + + +How do I apply a patch? +--- + You apply a patch with the `patch' program. The patch program reads a diff +(or patch) file and makes the changes to the source tree described in it. +Patches for the Linux kernel are generated releative to the parent directory +holding the kernel source dir. This means that paths to files inside the +patch file contain the name of the kernel source dirs it was generated +against - since this is unlikely to match the name of the kernel source dir +on your local machine (but is often useful info to see what version an +otherwise unlabeled patch was generated against) you should change into your +kernel source directory and then strip the first element of the path from +filenames in the patch file when applying it (the -p1 argument to `patch' +does this). To revert a previously applied patch, use the -R argument to +patch. + + +Where can I download the patches? +--- +The patches are available at http://kernel.org/ +Most recent patches are linked from the front page, but they also have +specific homes. +The 2.6.x.y (-stable) and 2.6.x patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/ +The -rc patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/ +The -git patches live at + ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ +The -mm kernels live at +ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/ + + +The 2.6.x kernels +--- + These are the base stable releases released by Linus. The highest numbered +release is the most recent. If regressions or other serious flaws are found +then a -stable fix patch will be released (see below) on to of this base. +Once a new 2.6.x base kernel is released, a patch is made available that is +a delta between the previous 2.6.x kernel and the new one. +To apply a patch moving from 2.6.11 to 2.6.12 you'd do the following (note +that such patches do *NOT* apply on top of 2.6.x.y kernels but on top of the +base 2.6.x kernel - if you need to move from 2.6.x.y to 2.6.x+1 you need to +first revert the 2.6.x.y patch). + +# moving from 2.6.11 to 2.6.12 +$ cd ~/linux-2.6.11# change to kernel source dir +$ patch -p1 ../patch-2.6.12 # apply the 2.6.12 patch +$ cd .. +$ mv linux-2.6.11 linux-2.6.12 # rename source dir + +# moving from 2.6.11.1 to 2.6.12 +$ cd ~/linux-2.6.11.1 # change to kernel source dir +$ patch -p1 -R ../patch-2.6.11.1 # revert the 2.6.11.1 patch + # source dir is now 2.6.11 +$ patch -p1 ../patch-2.6.12 # apply new 2.6.12 patch +$ cd .. +$ mv linux-2.6.11.1 inux-2.6.12# rename source dir + + +The 2.6.x.y kernels +---
Re: Documentation - how to apply patches for various trees
Thanks for this wonderful effort! Add one more to the testing team. ~Puneet Jesper Juhl wrote: Hi, How to apply the -rc, -git, -mm and the 2.6.x.y (-stable) patches is a quite frequently asked question on LKML and elsewhere. Since so many people seem to be confused by this I gathered it ought to be properly documented once and for all so we a) get more people testing those trees and b) get asked this question less often. So, I sat down and wrote such a document. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
