02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

20 Jun, 2016

1 commit

  • I tried to use 'make O=...' from an unclean source tree. This triggered
    the error path of setlocalversion. But by printing to STDOUT, it created
    a broken localversion which then caused another (unrelated) error:

    "4.7.0-rc2Error: kernelrelease not valid - run make prepare to update it" exceeds 64 characters

    After printing to STDERR, the true build error gets displayed later:

    /home/wsa/Kernel/linux is not clean, please run 'make mrproper'
    in the '/home/wsa/Kernel/linux' directory.

    Signed-off-by: Wolfram Sang
    Signed-off-by: Michal Marek

    Wolfram Sang
     

03 Jan, 2014

1 commit

  • setlocalversion script was testing the presence of .git directory in
    order to find out if git is used as SCM to track the current kernel
    project. However in some cases, .git is not a directory but can be a
    file: when the kernel is a git submodule part of a git super project for
    example.

    This patch just fixes this by using 'git rev-parse --show-cdup' to check
    that the current directory is the kernel git topdir. This has the
    advantage to not test and rely on git internal infrastructure directly.

    Signed-off-by: Franck Bui-Huu
    Signed-off-by: Michal Marek

    Franck Bui-Huu
     

24 Jun, 2013

1 commit

  • I just stumbled across another[0] issue when scripts/setlocalversion
    operates on a write-protected source tree. Back then[0] the source tree
    was on an read-only NFS share, so "test -w" was introduced before "git
    update-index" was run.

    This time, the source tree is on read/write NFS share, but the permissions
    are world-readable and only a specific user (or root) can write.
    Thus, "test -w ." returns "0" and then runs "git update-index",
    producing the following message (on a dirty tree):

    fatal: Unable to create '/usr/local/src/linux-git/.git/index.lock': Permission denied

    While it says "fatal", compilation continues just fine.

    However, I don't think a kernel compilation should alter the source
    tree (or the .git directory) in any way and I don't see how removing
    "git update-index" could do any harm. The Mercurial and SVN routines in
    scripts/setlocalversion don't have any tree-modifying commands, AFAICS.
    So, maybe the patch below would be acceptable.

    [0] https://patchwork.kernel.org/patch/29718/

    Signed-off-by: Christian Kujau
    Cc: Nico Schottelius
    Signed-off-by: Michal Marek

    Christian Kujau
     

22 Feb, 2013

1 commit


27 Mar, 2012

1 commit

  • In some circumstances (eg when running a build in an emacs shell
    buffer), I get a spew of messages like

    grep: writing output: Broken pipe

    from setlocalversion, because the "read" subshell apparently exits as
    soon as it reads one line and gives EPIPE to grep. It's not clear to
    me why this way of writing the check was used instead of just using
    grep -q to suppress output, but unless there is some deep reason I
    don't know, this way looks cleaner to me anyway, and gets rid of the
    ugly message spew.

    (I double checked at http://pubs.opengroup.org/onlinepubs/009604499/utilities/grep.html
    and "grep -q" is specified in POSIX / SuS, so hopefully even people
    cross-compiling the kernel on some bizarre host OS can't complain
    about this change)

    Signed-off-by: Roland Dreier
    Signed-off-by: Michal Marek

    Roland Dreier
     

15 Jan, 2011

1 commit


29 Oct, 2010

1 commit

  • * 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
    initramfs: Fix build break on symbol-prefixed archs
    initramfs: fix initramfs size calculation
    initramfs: generalize initramfs_data.xxx.S variants
    scripts/kallsyms: Enable error messages while hush up unnecessary warnings
    scripts/setlocalversion: update comment
    kbuild: Use a single clean rule for kernel and external modules
    kbuild: Do not run make clean in $(srctree)
    scripts/mod/modpost.c: fix commentary accordingly to last changes
    kbuild: Really don't clean bounds.h and asm-offsets.h

    Linus Torvalds
     

06 Sep, 2010

1 commit


21 Aug, 2010

1 commit

  • Dan McGee writes:
    > Note that when in git, you get the appended "+" sign. If
    > LOCALVERSION_AUTO is set, you will get something like
    > "eee-gb01b08c-dirty" (whereas the copy of the tree in /tmp still
    > returns "eee"). It doesn't matter whether the working tree is dirty or
    > clean.
    >
    > Is there a way to disable this? I'm building from a clean tarball that
    > just happens to be unpacked inside a git repository. One would think
    > setting LOCALVERSION_AUTO to false would do it, but no such luck...

    Fix this by checking if the kernel source tree is the root of the git or
    hg repository. No fix for svn: If the kernel source is not tracked in
    the svn repository, it works as expected, otherwise determining the
    'repository root' is not really a defined task.

    Reported-and-tested-by: Dan McGee
    Signed-off-by: Michal Marek

    Michal Marek
     

13 Aug, 2010

1 commit


21 Jul, 2010

1 commit

  • make rpm was broken by commit 0915512:
    make clean
    set -e; cd ..; ln -sf /usr/src/iwlwifi-2.6 kernel-2.6.35rc4wl
    /bin/sh /usr/src/iwlwifi-2.6/scripts/setlocalversion --scm-only >
    /usr/src/iwlwifi-2.6/.scmversion
    cat: .scmversion: input file is output file
    make[1]: *** [rpm] Error 1

    Reported-and-tested-by: "Zheng, Jiajia"
    Signed-off-by: Michal Marek

    Michal Marek
     

20 Jul, 2010

1 commit

  • The 'source' builtin is a bash alias to the '.' (dot) builtin. While the
    former is supported only by bash, the latter is specified in POSIX and
    works fine with all POSIX-compliant shells I am aware of.

    The '$_' special parameter is specific to bash. It is partially
    supported in dash too but it always evaluates to the current script path
    (which causes the script to enter a loop recursively re-executing
    itself). This is why I have replaced the two occurences of '$_' with the
    explicit parameter.

    The 'local' builtin is another example of bash-specific code. Although
    it is supported by all POSIX-compliant shells I am aware of, it is not
    part of POSIX specification and thus the code should not rely on it
    assigning a specific value to the local variable. Moreover, the 'posh'
    shell has a limited version of 'local' builtin not supporting direct
    variable assignments. Thus, I have broken one of the 'local'
    declarations down into a (non-POSIX) 'local' declaration and a plain
    (POSIX-compliant) variable assignment.

    Signed-off-by: Michał Górny
    Signed-off-by: Michal Marek

    Michał Górny
     

18 Jun, 2010

1 commit

  • Now that we run scripts/setlocalversion during every build, it makes
    sense to move all the localversion logic there. This cleans up the
    toplevel Makefile and also makes sure that the script is called only
    once in 'make prepare' (previously, it would be called every time due to
    a variable expansion in an ifneq statement). No user-visible change is
    intended, unless one runs the setlocalversion script directly.

    Reported-by: Dmitry Torokhov
    Cc: David Rientjes
    Cc: Greg Thelen
    Cc: Nico Schottelius
    Signed-off-by: Michal Marek

    Michal Marek
     

15 Jun, 2009

1 commit


20 May, 2009

1 commit


01 May, 2009

1 commit

  • When using trees like wireless-testing, which have untagged tags,
    scripts/setlocalversion does not display any git indication for
    localversion.

    This patch fixes it: If git is available, but no usable tag is found,
    it uses -g${head}. It skips the detection of unanottated tags via
    git name-rev.

    Signed-off-by: Nico Schottelius
    Signed-off-by: Sam Ravnborg

    Nico Schottelius
     

11 Apr, 2009

1 commit


15 Feb, 2009

1 commit


04 Dec, 2008

2 commits


30 Oct, 2008

2 commits

  • setlocalversion used to use an abbreviated git commit sha1 to generate the
    tag. This was changed in commit d882421f4e08ddf0a94245cdbe516db260aa6f41
    "kbuild: change CONFIG_LOCALVERSION_AUTO to use a git-describe-ish format"
    to use git describe to come up with a tag. Which is nice, but git describe
    sometimes can't describe the revision.
    Commit 56b2f0706d82535fd8d85503f2dcc0be40c8e55d ("setlocalversion: do not
    describe if there is nothing to describe") addressed this, but there is still
    no tag generated.

    So, generate a plain abbreviated sha1 tag like setlocalversion used to when
    git describe comes up short.

    Signed-off-by: Trent Piepho
    CC: Jan Engelhardt
    Signed-off-by: Sam Ravnborg

    Trent Piepho
     
  • The number of pending changes is pretty useless, so encoding it into the
    version is just annoying by the constant shuffle in corresponding modules.

    Signed-off-by: Mike Frysinger
    Signed-off-by: Sam Ravnborg

    Mike Frysinger
     

26 Jul, 2008

1 commit

  • Jan Engelhardt wrote:
    > Just a note that when you run git-describe, you should probably quiten it.
    >
    > fatal: cannot describe 'bd7364a0fd5a4a2878fe4a224be1b142a4e6698e'
    >
    > This happens when tags are not present, which can happen if Linus's tree
    > is sent upwards again, IOW:
    >
    > machine1$ git-clone torvalds/linux-2.6.git
    > machine1$ git push elsewhere master
    >
    > machine2$ git-clone elsewhere:/linux
    > machine2$ git-describe HEAD
    > fatal: cannot describe that

    Signed-off-by: Sebastian Siewior
    Acked-by: Jan Engelhardt
    Signed-off-by: Sam Ravnborg

    Sebastian Siewior
     

03 Feb, 2008

1 commit


29 Jan, 2008

4 commits

  • make-kpkg modifies scripts/package/Makefile and deletes
    scripts/package/builddeb as part of its build process. Ignore these
    changes so the tree isn't marked as -dirty, when it is just an
    artifact of make-kpkg. (make-kpkg clean restores the files to their
    original state, and these helper scripts won't affect the final
    compiled kernel in any way.)

    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Sam Ravnborg

    Theodore Ts'o
     
  • If git's index file is out of date, and some files have been touched
    such that their timestamp doesn't what is in the index, "git
    diff-index HEAD" may show that a particular file is dirty, when in
    fact it really isn't. Running "git update-index" will update the
    index to avoid these false positives.

    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Sam Ravnborg

    Theodore Ts'o
     
  • Change the automatic local version to have the form -nnnnn-gSHA1SUMID,
    where 'nnnnn' is the number of commits since the last tag (i.e.,
    2.6.21-rc7). This makes it much more likely that the package names created
    for the kernel will look "newer" to a package manager.

    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Sam Ravnborg

    Theodore Ts'o
     
  • This represents mercurial changesets similarly to git. For untagged
    revisions, append the changeset id. If there are uncommitted changes,
    append -dirty. For example, -hgc60016ba6237-dirty

    Signed-off-by: Aron Griffis
    Signed-off-by: Sam Ravnborg

    Aron Griffis
     

17 Jun, 2006

2 commits


09 Jan, 2006

1 commit


07 Jan, 2006

1 commit

  • Currently scripts/setlocalversion is a Perl script that tries to figure
    out the current git commit ID of a repo without using git. It also
    imports Digest::MD5 without using it and generally is too big for the
    small task it does. :] And it always reports a git ID, even when the
    HEAD is tagged -- this is a bug.

    This patch replaces it with a Bourne Shell script that uses git
    commands to do the same. I can't come up with a scenario where someone
    would use a git repo and refuse to install git core at the same time,
    so I think it's reasonable to assume git is available.

    The new script also reports uncommitted changes by adding -git_dirty to
    the version string. Obviously you can't see from that _what_ has been
    changed from the last commit, so it's more of a reminder that you
    forgot to commit something.

    The script is easily extensible: simply add a check for Mercurial (or
    whatever) below the git check.

    Note: the script doesn't print a newline char anymore. That's only
    because it was easier to implement it that way, not a feature (or bug).
    'make kernelrelease' doesn't care.

    Signed-off-by: Rene Scharfe
    Acked-by: Ryan Anderson
    Signed-off-by: Sam Ravnborg

    Rene Scharfe
     

11 Aug, 2005

1 commit