1. 18 Jul, 2021 1 commit
  2. 26 May, 2021 5 commits
  3. 01 May, 2021 1 commit
  4. 24 Sep, 2020 1 commit
    • Rasmus Villemoes's avatar
      scripts/setlocalversion: make git describe output more reliable · 548b8b51
      Rasmus Villemoes authored
      When building for an embedded target using Yocto, we're sometimes
      observing that the version string that gets built into vmlinux (and
      thus what uname -a reports) differs from the path under /lib/modules/
      where modules get installed in the rootfs, but only in the length of
      the -gabc123def suffix. Hence modprobe always fails.
      The problem is that Yocto has the concept of "sstate" (shared state),
      which allows different developers/buildbots/etc. to share build
      artifacts, based on a hash of all the metadata that went into building
      that artifact - and that metadata includes all dependencies (e.g. the
      compiler used etc.). That normally works quite well; usually a clean
      build (without using any sstate cache) done by one developer ends up
      being binary identical to a build done on another host. However, one
      thing that can cause two developers to end up with different builds
      [and thus make one's vmlinux package incompatible with the other's
      kernel-dev package], which is not captured by the metadata hashing, is
      this `git describe`: The output of that can be affected by
      (1) git version: before 2.11 git defaulted to a minimum of 7, since
      2.11 (git.git commit e6c587) the default is dynamic based on the
      number of objects in the repo
      (2) hence even if both run the same git version, the output can differ
      based on how many remotes are being tracked (or just lots of local
      development branches or plain old garbage)
      (3) and of course somebody could have a core.abbrev config setting in
      So in order to avoid `uname -a` output relying on such random details
      of the build environment which are rather hard to ensure are
      consistent between developers and buildbots, make sure the abbreviated
      sha1 always consists of exactly 12 hex characters. That is consistent
      with the current rule for -stable patches, and is almost always enough
      to identify the head commit unambigously - in the few cases where it
      does not, the v5.4.3-00021- prefix would certainly nail it down.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
  5. 11 Nov, 2019 1 commit
  6. 15 Oct, 2019 1 commit
  7. 05 Oct, 2019 1 commit
    • Masahiro Yamada's avatar
      scripts/setlocalversion: clear local variable to make it work for sh · 7a82e3fa
      Masahiro Yamada authored
      Geert Uytterhoeven reports a strange side-effect of commit 858805b3
      ("kbuild: add $(BASH) to run scripts with bash-extension"), which
      inserts the contents of a localversion file in the build directory twice.
      [Steps to Reproduce]
        $ echo bar > localversion
        $ mkdir build
        $ cd build/
        $ echo foo > localversion
        $ make -s -f ../Makefile defconfig include/config/kernel.release
        $ cat include/config/kernel.release
      This comes down to the behavior change of local variables.
      The 'man sh' on my Ubuntu machine, where sh is an alias to dash,
      explains as follows:
        When a variable is made local, it inherits the initial value and
        exported and readonly flags from the variable with the same name
        in the surrounding scope, if there is one. Otherwise, the variable
        is initially unset.
      [Test Code]
        foo ()
                local res
                echo "res: $res"
        $ sh test.sh
        res: 1
        $ b...
  8. 21 Nov, 2018 1 commit
    • Brian Norris's avatar
      scripts/setlocalversion: Improve -dirty check with git-status --no-optional-locks · ff64dd48
      Brian Norris authored
      git-diff-index does not refresh the index for you, so using it for a
      "-dirty" check can give misleading results. Commit 6147b1cf
      ("scripts/setlocalversion: git: Make -dirty check more robust") tried to
      fix this by switching to git-status, but it overlooked the fact that
      git-status also writes to the .git directory of the source tree, which
      is definitely not kosher for an out-of-tree (O=) build. That is getting
      Fortunately, git-status now supports avoiding writing to the index via
      the --no-optional-locks flag, as of git 2.14. It still calculates an
      up-to-date index, but it avoids writing it out to the .git directory.
      So, let's retry the solution from commit 6147b1cf
       using this new
      flag first, and if it fails, we assume this is an older version of git
      and just use the old git-diff-index method.
      It's hairy to get the 'grep -vq' (inverted matching) correct by stashing
      the output of git-status (you have to be careful about the difference
      betwen "empty stdin" and "blank line on stdin"), so just pipe the output
      directly to grep and use a regex that's good enough for both the
      git-status and git-diff-index version.
      Cc: Christian Kujau <lists@nerdbynature.de>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Suggested-by: default avatarAlexander Kapshuk <alexander.kapshuk@gmail.com>
      Signed-off-by: default avatarBrian Norris <briannorris@chromium.org>
      Tested-by: default avatarGenki Sky <sky@genki.is>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  9. 11 Nov, 2018 1 commit
    • Guenter Roeck's avatar
      Revert "scripts/setlocalversion: git: Make -dirty check more robust" · 8ef14c2c
      Guenter Roeck authored
      This reverts commit 6147b1cf.
      The reverted patch results in attempted write access to the source
      repository, even if that repository is mounted read-only.
      Output from "strace git status -uno --porcelain":
      getcwd("/tmp/linux-test", 129)          = 16
      open("/tmp/linux-test/.git/index.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) =
      	-1 EROFS (Read-only file system)
      While git appears to be able to handle this situation, a monitored
      build environment (such as the one used for Chrome OS kernel builds)
      may detect it and bail out with an access violation error. On top of
      that, the attempted write access suggests that git _will_ write to the
      file even if a build output directory is specified. Users may have the
      reasonable expectation that the source repository remains untouched in
      that situation.
      Fixes: 6147b1cf
       ("scripts/setlocalversion: git: Make -dirty check more robust"
      Cc: Genki Sky <sky@genki.is>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
  10. 31 Aug, 2018 1 commit
  11. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      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...
  12. 20 Jun, 2016 1 commit
    • Wolfram Sang's avatar
      kbuild: setlocalversion: print error to STDERR · 78283edf
      Wolfram Sang authored
      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: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  13. 03 Jan, 2014 1 commit
  14. 23 Jun, 2013 1 commit
    • Christian Kujau's avatar
      scripts/setlocalversion on write-protected source tree · cdf2bc63
      Christian Kujau authored
      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: default avatarChristian Kujau <lists@nerdbynature.de>
      Cc: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  15. 22 Feb, 2013 1 commit
  16. 26 Mar, 2012 1 commit
  17. 14 Jan, 2011 1 commit
  18. 06 Sep, 2010 1 commit
  19. 21 Aug, 2010 1 commit
    • Michal Marek's avatar
      setlocalversion: Ignote SCMs above the linux source tree · 8558f59e
      Michal Marek authored
      Dan McGee <dpmcgee@gmail.com> 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: default avatarDan McGee <dpmcgee@gmail.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  20. 12 Aug, 2010 1 commit
  21. 21 Jul, 2010 1 commit
  22. 20 Jul, 2010 1 commit
    • Michał Górny's avatar
      kbuild: Make the setlocalversion script POSIX-compliant · 6dc0c2f3
      Michał Górny authored
      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: default avatarMichał Górny <gentoo@mgorny.alt.pl>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  23. 18 Jun, 2010 1 commit
    • Michal Marek's avatar
      kbuild: Clean up and speed up the localversion logic · 09155120
      Michal Marek authored
      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: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Greg Thelen <gthelen@google.com>
      Cc: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  24. 14 Jun, 2009 1 commit
  25. 19 May, 2009 1 commit
  26. 01 May, 2009 1 commit
  27. 11 Apr, 2009 1 commit
  28. 15 Feb, 2009 1 commit
  29. 03 Dec, 2008 2 commits
  30. 29 Oct, 2008 2 commits
  31. 25 Jul, 2008 1 commit
  32. 03 Feb, 2008 1 commit
  33. 28 Jan, 2008 2 commits