04 Apr, 2011

1 commit

  • Silence a remaining annoying (or worse, irritating - "is my entire patched tree
    broken now!?") bashism-related message that occurs when /bin/sh is configured
    to instead deploy dash, a POSIX-compliant shell, as is the pretty much
    standard case on e.g. Debian.

    Current kernel version is 2.6.38 ( Flesh-Eating Bats with Fangs)
    ===> linux-2.6.38.patch-kernel_test/scripts/patch-kernel: line 253: [: =: unary operator expected
    Signed-off-by: Michal Marek

    Andreas Mohr
     

07 Aug, 2008

1 commit


29 Jan, 2008

1 commit

  • 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
    Acked-by: Randy Dunlap
    Signed-off-by: Sam Ravnborg

    Andreas Mohr
     

03 Jan, 2006

1 commit


06 May, 2005

1 commit

  • 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
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy.Dunlap
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds