Skip to content

GitLab

Switch branch/tag
  1. 20 Feb, 2013 2 commits
    • Stephen Boyd's avatar
      setlocalversion: Fix version when built/synced on a tag · 0e7e93da
      Stephen Boyd authored 
      
If building on a tag we check to make sure the version in the
Makefile matches the tag we're building at. That would be a
string comparison and not an integer comparison. Change the test
accordingly. Right now we'll just see 3.0.8 or 3.0.8-dirty if the
kernel is built on a tag.

Similarly if we're synced to a tag we may have two references to
the same object, 1 in the local repo and one in the remote. Force
the show-ref to only look at tags so we only ever describe on
ref instead of two.

Change-Id: I694947b434db8f95d4c0b9f6e68702c65a1ee281
Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
(cherry picked from commit cf76837260758073496ce6325bcb20e657eb2066)
      0e7e93da
    • Stephen Boyd's avatar
      setlocalversion: Prevent tags from overflowing version string · aade7123
      Stephen Boyd authored 
      
Some post Linus tags are very long and they exceed the character
limit on the version string. This leads to compile errors like

 3.0.8-insert-your-reallllly-long-tag-name-here-13-g4b4e960-dirty
 exceeds 64 characters

Instead of putting the pretty printed name of the closest post
Linus tag, place the tag's object hash in the version string.
This should allow developers to easily run a git show on the
first hash to see what tag the build is based on. The version
will look like:

	3.0.8-gb080168-00006-g41f3bb3-dirty

meaning the kernel is based on v3.0.8 at the tag b080168 with 6
patches applied on top of that tag resulting in a commit with the
hash 41f3bb3 plus a dirty tree. Running "git show b080168"
should show the closest tag the tree was based on.

Change-Id: I8a26532f76aadf31654cb420ab789e90bd2fe828
Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
(cherry picked from commit cd7c0ee4d018b96fa540a29aa31452c3455f6e20)

Conflicts:

	scripts/setlocalversion
      aade7123
  3. 26 Mar, 2012 1 commit
  5. 14 Jan, 2011 1 commit
  7. 06 Sep, 2010 1 commit
  9. 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>
      8558f59e
  11. 12 Aug, 2010 1 commit
  13. 21 Jul, 2010 1 commit
  15. 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>
      6dc0c2f3
  17. 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>
      09155120
  19. 14 Jun, 2009 1 commit
  21. 19 May, 2009 1 commit
  23. 01 May, 2009 1 commit
  25. 11 Apr, 2009 1 commit
  27. 15 Feb, 2009 1 commit
  29. 03 Dec, 2008 2 commits
  31. 29 Oct, 2008 2 commits
  33. 25 Jul, 2008 1 commit
  35. 03 Feb, 2008 1 commit
  37. 28 Jan, 2008 4 commits
  39. 16 Jun, 2006 2 commits
  41. 08 Jan, 2006 1 commit
  43. 06 Jan, 2006 1 commit
    • Rene Scharfe's avatar
      kbuild: Use git in scripts/setlocalversion · 117a93db
      Rene Scharfe authored 
      
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: default avatarRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Acked-by: default avatarRyan Anderson <ryan@michonline.com>
Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      117a93db
  45. 10 Aug, 2005 1 commit