lkml.org 
[lkml]   [2010]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kbuild: Fix the breakage caused by "improve version string logic"
On 06/08/2010 12:13 PM, David Rientjes wrote:
> On Tue, 8 Jun 2010, Boaz Harrosh wrote:
>
>>
>> The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d
>> Author: David Rientjes <rientjes@google.com>
>> Title: kbuild: improve version string logic
>>
>> Broke none Linus trees that supply their own version string and
>> tag system via a presence of a localversion* file at the Kernel's
>> root subdirectory.
>>
>> After This patch. The "+" (plus) is not added if a localversion*
>> file is present or a CONFIG_LOCALVERSION is configured.
>>
>
> The only reason the `+' is being appended to your version string is
> because your scm is reporting that there have been commits to the tree
> since the last release; for git, that means anything that isn't at a
> tagged commit.
>

What is a tagged commit:

[my_tree] $ git branch
*master
[my_tree] $ git tag v2.6.35-rc2-my-tree
[my_tree] $ cat localversion-my-tree
-my-tree

I still get: DEPMOD 2.6.35-rc2-my-tree+

How to solve? please specify.

> If you were to create a tarball of your tree, for instance, and distribute
> it to someone else, there would be no appended `+' because there is no
> revision history. The `+' being appended simply implies that you're
> beyond the base kernel version in an scm. The motivation is to be more
> descriptive about what kernel is being run: the most common case where
> this comes into play is when someone is running a kernel off of Linus'
> tree and a bug report incorrectly shows that it is a vanilla 2.6.35-rc2
> kernel, for instance.
>

In the Linus case there is CONFIG_LOCALVERSION_AUTO=y by default for this.

In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with
Linus tree.

CONFIG_LOCALVERSION_AUTO=n was: "Even if I have an SCM, please do not
inspect it."

I need that back

> When we discussed adding this indicator of revision history, we explicitly
> noted that the `+' is a modification of the base kernel version, not the
> entire string.
>

My base "kernel version" is 2.6.35-rc2-my-tree. There cannot be any mistake
where this tree came from. How do I get rid of the "+"?

> As mentioned previously, you can easily suppress that from being added by
> using "make LOCALVERSION=-foo" to create a 2.6.35-rc2-foo kernel when you
> do not have CONFIG_LOCALVERSION_AUTO enabled. You already found that you
> cannot pass an empty LOCALVERSION string, so it must be something to
> identify itself as unique from vanilla 2.6.35-rc2.
>

As mentioned previously this is not an option I do not have git control
over how this gets compiled.

> The usecase that you've cited before is your colleagues pulling your git
> tree and then getting this `+' appended when they really don't want it.

Yes

> Although localversion* files are better than (ab)using the EXTRAVERSION
> variable in the Makefile, they won't suppress the `+' because your
> revision history shows that you're beyond a released (tagged) kernel.

I'm now using localversion-my-tree file. It is much better thanks.

What else do I need to do so clean checkout of my tree will not have
the "+" appended. It already have the my-tree appended to it.

> The solution is to use git-tag to indicate your particular version of Linux
> that differentiates it from vanilla 2.6.35-rc2 and pass along your version
> information with either localversion*

I tried that. Only with my patch it works. Hence the patch.

files or CONFIG_LOCALVERSION if you
> package your .config as well.

Again not an option .config is derived from a distro one and is not managed
by git.

Please find me a solution? this breaks lots of stuff un-necessarily and with
no apparent gain.

Thanks
Boaz


\
 
 \ /
  Last update: 2010-06-08 12:17    [W:0.115 / U:0.624 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site