summaryrefslogtreecommitdiff
path: root/scripts/patch-kernel
AgeCommit message (Collapse)Author
2008-01-28kbuild: eradicate bashisms in scripts/patch-kernelAndreas Mohr
Make the patch-kernel shell script sufficiently compatible with POSIX shells, i.e., remove bashisms from scripts/patch-kernel. This means that it now also works on dash 0.5.3-5 and still works on bash 3.1dfsg-8. Full changelog: - replaced non-standard "==" by standard "=" - replaced non-standard "source" statement by POSIX "dot" command - use leading ./ on mktemp filename to force the tempfile to a local directory, so that the search path is not used - replace bash syntax to remove leading dot by similar POSIX syntax - added missing (optional/not required) $ signs to shell variable names Signed-off-by: Andreas Mohr <andi@lisas.de> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
2006-01-03update the email address of Randy DunlapAdrian Bunk
This patch removes all references to the bouncing address rddunlap@osdl.org and one dead web page from the kernel. Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
2005-05-05[PATCH] patch-kernel: support non-incremental 2.6.x.y 'stable' patchesRandy.Dunlap
Add better support for (non-incremental) 2.6.x.y patches; If an ending version number if not specified, the script automatically increments the SUBLEVEL (x in 2.6.x.y) until no more patch files are found; however, EXTRAVERSION (y in 2.6.x.y) is never automatically incremented but must be specified fully. patch-kernel does not normally support reverse patching, but does so when applying EXTRAVERSION (x.y) patches, so that moving from 2.6.11.y to 2.6.11.z is easy and handled by the script (reverse 2.6.11.y and apply 2.6.11.z). Signed-off-by: Randy Dunlap <rddunlap@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!