kbuild: Fix the breakage caused by "improve version string logic"
in [Kernel]
|
Prev: requires info abt scheduling algo
Next: [PATCH] Documentation/filesystems/xip.txt: clarify the statement: The block device option is mandatory for execute-in-place
From: Boaz Harrosh on 8 Jun 2010 04:40 The patch: 85a256d8e0116c8f5ad276730830f5d4d473344d Author: David Rientjes <rientjes(a)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. Signed-off-by: Boaz Harrosh <bharrosh(a)panasas.com> --- Makefile | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 654c31a..324a413 100644 --- a/Makefile +++ b/Makefile @@ -945,7 +945,9 @@ ifdef CONFIG_LOCALVERSION_AUTO else ifneq ($(scm-identifier),) ifeq ($(LOCALVERSION),) - localver-extra = + + ifeq ($(localver),) + localver-extra = + + endif endif endif endif -- 1.6.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Boaz Harrosh on 8 Jun 2010 06:20 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(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Boaz Harrosh on 8 Jun 2010 06:30 On 06/08/2010 01:14 PM, Boaz Harrosh wrote: > 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(a)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 OK now I get it I need: $ git tag -a v2.6.35-rc2-my-tree I never used the -a before though no one complained. What else am I missing? Boaz > [my_tree] $ cat localversion-my-tree > -my-tree > > I still get: DEPMOD 2.6.35-rc2-my-tree+ > > How to solve? please specify. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Boaz Harrosh on 9 Jun 2010 04:00
On 06/09/2010 09:55 AM, David Rientjes wrote: > On Tue, 8 Jun 2010, Boaz Harrosh wrote: > >> 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. >> > > You need to use git tag -a. > Right, I got that >> In my tree there is 2.6.35-rc2-my-tree so it cannot be mistaken with >> Linus tree. >> > > Just because you have appended "-my-tree" to the version string does not > mean it is not vanilla 2.6.35-rc2. You could append information such as > that just for a different config, for instance. No, this is all naming convention. Just like the '+' is. If it was a config thing then it would be added via CONFIG_LOCALVERSION and *appended* to any compilation using that config. From a git tree you get added the localversion* file that gets pulled by a checkout. and so on. So at a glance I know that the presence of my_tree was added because it is from my tree. They are all chained and ordered so we know exactly what contributed what. > The `+' modifies the base > kernel version (2.6.35-rc2), not the string itself or whatever you choose > to add to it. > Not, correct. As you yourself explained. The `+' modifies any Kernel that is not a "tag -a" and/or modified from the tree it derives from. Base kernel version has nothing to do with it. >>> 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. >> > > If your git repository is publically accessible, it is very simple to tag > commits that you want your users to pull from to indicate it's a > "release". That allows you to determine whether other users have extra > commits on top of your release when they send you bug reports, for > example, which is quite helpful. Sigh, I give up. Let me spell it out for you once more and I'll not mention this again: "For multitude of reasons, there are times that even when running from a git tree, I wish to compile a Kernel as if it's from a tar-ball. .i.e Don't poke in my git tree for this compilation." Because I'm cross compiling, because I'm bisecting, because my scripts and environment demand specific names, because i need to save space and time... But it seems I will not be granted my wish. I'll go damage my scripts/setlocalversion and be done with this. Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |