[PATCH] kernel.bbclass: Stop creating empty .scmversion files

[PATCH] kernel.bbclass: Stop creating empty .scmversion files

[paulburton]

The kernel_do_configure() function creates empty .scmversion files
within both the source & build directories. The presence of these files
causes the scm_version function within the kernel's
scripts/setlocalversion to always output the empty string, breaking the
kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
string to the kernel version. Rather than appending the git commit hash
or another SCM revision to the kernel version, the empty string is
appended causing CONFIG_LOCALVERSION_AUTO to do nothing.

This behavior was introduced for the build directory by commit
c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
extended to the source directory by commit cafb94f57123
("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
entirely clear since these commits contain no meaningful descriptions
and the former links to a mailing list archive that is no longer online,
but the '+' character referenced would be appended if the kernel were
built from a dirty working tree. This in itself is useful information;
hiding that fact can only serve to muddy a user's understanding of what
kernel they're actually running. I have verified that building a kernel
from a clean working tree does not result in a spurious '+' character.

Remove the creation of the empty .scmversion files in order to restore
the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
of kernels built from non-tagged source & configured with
CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
actually running.

Signed-off-by: Paul Burton <paulburton@google.com>
---
 meta/classes/kernel.bbclass | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a724645466..46e24a19e2 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
 do_configure[prefuncs] += "check_oldest_kernel"
 
 kernel_do_configure() {
-	# fixes extra + in /lib/modules/2.6.37+
-	# $ scripts/setlocalversion . => +
-	# $ make kernelversion => 2.6.37
-	# $ make kernelrelease => 2.6.37+
-	touch ${B}/.scmversion ${S}/.scmversion
-
 	if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
 		mv "${S}/.config" "${B}/.config"
 	fi
-- 
2.26.0.rc2.310.g2932bb562d-goog

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Bruce Ashfield]

On Tue, Mar 31, 2020 at 7:56 PM Paul Burton via Lists.Openembedded.Org
<paulburton=google.com@lists.openembedded.org> wrote:
>
> The kernel_do_configure() function creates empty .scmversion files
> within both the source & build directories. The presence of these files
> causes the scm_version function within the kernel's
> scripts/setlocalversion to always output the empty string, breaking the
> kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
> string to the kernel version. Rather than appending the git commit hash
> or another SCM revision to the kernel version, the empty string is
> appended causing CONFIG_LOCALVERSION_AUTO to do nothing.
>
> This behavior was introduced for the build directory by commit
> c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
> extended to the source directory by commit cafb94f57123
> ("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
> entirely clear since these commits contain no meaningful descriptions
> and the former links to a mailing list archive that is no longer online,
> but the '+' character referenced would be appended if the kernel were
> built from a dirty working tree. This in itself is useful information;
> hiding that fact can only serve to muddy a user's understanding of what
> kernel they're actually running. I have verified that building a kernel
> from a clean working tree does not result in a spurious '+' character.

I have all the original email from 2011 on the topic, Martin probably does
as well.

A snippet from the conversation is this, and it is about moving some kernel
build steps into oe-core from meta-oe:

------
"If you're working on shared linux.inc in meta-oe, could you please
integrate this:

do_configure_prepend() {
#otherwise it gets extra '+' "2.6.37+"
#because:
#$ scripts/setlocalversion . => +
#$ make kernelversion => 2.6.37
#$ make kernelrelease => 2.6.37+
  rm -rf ${S}/.git
}

I have to do this in every git recipe as I don't like dirs like
/lib/modules/2.6.37+

Maybe it should be fixed on kernel.bbclass level, because linux-yocto
suffers the same ie /lib/modules/3.0.12-yocto-standard+

Ccing oe-core for that.."
------

I didn't make any of the changes, but looking at the thread, if you aren't
getting a + added to the localversion or directories, then I can't see how
it would break anything.

Cheers,

Bruce

>
> Remove the creation of the empty .scmversion files in order to restore
> the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> of kernels built from non-tagged source & configured with
> CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> actually running.
>
> Signed-off-by: Paul Burton <paulburton@google.com>
> ---
>  meta/classes/kernel.bbclass | 6 ------
>  1 file changed, 6 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index a724645466..46e24a19e2 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
>  do_configure[prefuncs] += "check_oldest_kernel"
>
>  kernel_do_configure() {
> -       # fixes extra + in /lib/modules/2.6.37+
> -       # $ scripts/setlocalversion . => +
> -       # $ make kernelversion => 2.6.37
> -       # $ make kernelrelease => 2.6.37+
> -       touch ${B}/.scmversion ${S}/.scmversion
> -
>         if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
>                 mv "${S}/.config" "${B}/.config"
>         fi
> --
> 2.26.0.rc2.310.g2932bb562d-goog
>
> 



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Bruce Ashfield]

On Tue, Mar 31, 2020 at 9:29 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
> On Tue, Mar 31, 2020 at 7:56 PM Paul Burton via Lists.Openembedded.Org
> <paulburton=google.com@lists.openembedded.org> wrote:
> >
> > The kernel_do_configure() function creates empty .scmversion files
> > within both the source & build directories. The presence of these files
> > causes the scm_version function within the kernel's
> > scripts/setlocalversion to always output the empty string, breaking the
> > kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
> > string to the kernel version. Rather than appending the git commit hash
> > or another SCM revision to the kernel version, the empty string is
> > appended causing CONFIG_LOCALVERSION_AUTO to do nothing.
> >
> > This behavior was introduced for the build directory by commit
> > c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
> > extended to the source directory by commit cafb94f57123
> > ("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
> > entirely clear since these commits contain no meaningful descriptions
> > and the former links to a mailing list archive that is no longer online,
> > but the '+' character referenced would be appended if the kernel were
> > built from a dirty working tree. This in itself is useful information;
> > hiding that fact can only serve to muddy a user's understanding of what
> > kernel they're actually running. I have verified that building a kernel
> > from a clean working tree does not result in a spurious '+' character.
>
> I have all the original email from 2011 on the topic, Martin probably does
> as well.

Also note that in 2017 Trevor Woerner tried exactly the same fix that
you are doing, but ended up retracting it when he found a test case
that was still adding a + to the version.

see: [OE-core] [PATCH] meta/classes/kernel.bbclass: revert 56fe5300ab5

It might be worth checking with Trevor to see if he recalls what case
it was where the + snuck back in.

Cheers,

Bruce

Bruce

>
> A snippet from the conversation is this, and it is about moving some kernel
> build steps into oe-core from meta-oe:
>
> ------
> "If you're working on shared linux.inc in meta-oe, could you please
> integrate this:
>
> do_configure_prepend() {
> #otherwise it gets extra '+' "2.6.37+"
> #because:
> #$ scripts/setlocalversion . => +
> #$ make kernelversion => 2.6.37
> #$ make kernelrelease => 2.6.37+
>   rm -rf ${S}/.git
> }
>
> I have to do this in every git recipe as I don't like dirs like
> /lib/modules/2.6.37+
>
> Maybe it should be fixed on kernel.bbclass level, because linux-yocto
> suffers the same ie /lib/modules/3.0.12-yocto-standard+
>
> Ccing oe-core for that.."
> ------
>
> I didn't make any of the changes, but looking at the thread, if you aren't
> getting a + added to the localversion or directories, then I can't see how
> it would break anything.
>
> Cheers,
>
> Bruce
>
> >
> > Remove the creation of the empty .scmversion files in order to restore
> > the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> > of kernels built from non-tagged source & configured with
> > CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> > actually running.
> >
> > Signed-off-by: Paul Burton <paulburton@google.com>
> > ---
> >  meta/classes/kernel.bbclass | 6 ------
> >  1 file changed, 6 deletions(-)
> >
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index a724645466..46e24a19e2 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
> >  do_configure[prefuncs] += "check_oldest_kernel"
> >
> >  kernel_do_configure() {
> > -       # fixes extra + in /lib/modules/2.6.37+
> > -       # $ scripts/setlocalversion . => +
> > -       # $ make kernelversion => 2.6.37
> > -       # $ make kernelrelease => 2.6.37+
> > -       touch ${B}/.scmversion ${S}/.scmversion
> > -
> >         if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
> >                 mv "${S}/.config" "${B}/.config"
> >         fi
> > --
> > 2.26.0.rc2.310.g2932bb562d-goog
> >
> > 
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5611 bytes --]

Another piece of this puzzle might also be that in 2012 I was still using
minimalistic gentoo chroot, which was shared across all builders as git
repository, so even when you were building some kernel from tarball it
might have incorrectly assume that the kernel repo is dirty (even when it
was the git repo in top level rootfs directory which was dirty).

But I agree that my commit message in:
https://git.openembedded.org/meta-openembedded/commit/?id=ef29620a796fc3004afaf998c875ad76c533652c

sucks considering that the ML archives were changed at least 2 times since
this commit.

On Wed, Apr 1, 2020 at 2:32 AM Bruce Ashfield <bruce.ashfield@gmail.com>
wrote:

> On Tue, Mar 31, 2020 at 9:29 PM Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
> >
> > On Tue, Mar 31, 2020 at 7:56 PM Paul Burton via Lists.Openembedded.Org
> > <paulburton=google.com@lists.openembedded.org> wrote:
> > >
> > > The kernel_do_configure() function creates empty .scmversion files
> > > within both the source & build directories. The presence of these files
> > > causes the scm_version function within the kernel's
> > > scripts/setlocalversion to always output the empty string, breaking the
> > > kernel's CONFIG_LOCALVERSION_AUTO=y functionality which appends that
> > > string to the kernel version. Rather than appending the git commit hash
> > > or another SCM revision to the kernel version, the empty string is
> > > appended causing CONFIG_LOCALVERSION_AUTO to do nothing.
> > >
> > > This behavior was introduced for the build directory by commit
> > > c73e50a91e02 ("kernel.bbclass: fix extra + in kernelrelease") and
> > > extended to the source directory by commit cafb94f57123
> > > ("kernel.bbclass: touch .scmversion also in ${S}"). The motive isn't
> > > entirely clear since these commits contain no meaningful descriptions
> > > and the former links to a mailing list archive that is no longer
> online,
> > > but the '+' character referenced would be appended if the kernel were
> > > built from a dirty working tree. This in itself is useful information;
> > > hiding that fact can only serve to muddy a user's understanding of what
> > > kernel they're actually running. I have verified that building a kernel
> > > from a clean working tree does not result in a spurious '+' character.
> >
> > I have all the original email from 2011 on the topic, Martin probably
> does
> > as well.
>
> Also note that in 2017 Trevor Woerner tried exactly the same fix that
> you are doing, but ended up retracting it when he found a test case
> that was still adding a + to the version.
>
> see: [OE-core] [PATCH] meta/classes/kernel.bbclass: revert 56fe5300ab5
>
> It might be worth checking with Trevor to see if he recalls what case
> it was where the + snuck back in.
>
> Cheers,
>
> Bruce
>
> Bruce
>
> >
> > A snippet from the conversation is this, and it is about moving some
> kernel
> > build steps into oe-core from meta-oe:
> >
> > ------
> > "If you're working on shared linux.inc in meta-oe, could you please
> > integrate this:
> >
> > do_configure_prepend() {
> > #otherwise it gets extra '+' "2.6.37+"
> > #because:
> > #$ scripts/setlocalversion . => +
> > #$ make kernelversion => 2.6.37
> > #$ make kernelrelease => 2.6.37+
> >   rm -rf ${S}/.git
> > }
> >
> > I have to do this in every git recipe as I don't like dirs like
> > /lib/modules/2.6.37+
> >
> > Maybe it should be fixed on kernel.bbclass level, because linux-yocto
> > suffers the same ie /lib/modules/3.0.12-yocto-standard+
> >
> > Ccing oe-core for that.."
> > ------
> >
> > I didn't make any of the changes, but looking at the thread, if you
> aren't
> > getting a + added to the localversion or directories, then I can't see
> how
> > it would break anything.
> >
> > Cheers,
> >
> > Bruce
> >
> > >
> > > Remove the creation of the empty .scmversion files in order to restore
> > > the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> > > of kernels built from non-tagged source & configured with
> > > CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> > > actually running.
> > >
> > > Signed-off-by: Paul Burton <paulburton@google.com>
> > > ---
> > >  meta/classes/kernel.bbclass | 6 ------
> > >  1 file changed, 6 deletions(-)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index a724645466..46e24a19e2 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -521,12 +521,6 @@ check_oldest_kernel[vardepsexclude] +=
> "OLDEST_KERNEL KERNEL_VERSION"
> > >  do_configure[prefuncs] += "check_oldest_kernel"
> > >
> > >  kernel_do_configure() {
> > > -       # fixes extra + in /lib/modules/2.6.37+
> > > -       # $ scripts/setlocalversion . => +
> > > -       # $ make kernelversion => 2.6.37
> > > -       # $ make kernelrelease => 2.6.37+
> > > -       touch ${B}/.scmversion ${S}/.scmversion
> > > -
> > >         if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f
> "${B}/.config" ]; then
> > >                 mv "${S}/.config" "${B}/.config"
> > >         fi
> > > --
> > > 2.26.0.rc2.310.g2932bb562d-goog
> > >
> > >
> >
> >
> >
> > --
> > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > thee at its end
> > - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> 
>

[-- Attachment #2: Type: text/html, Size: 7331 bytes --]

Re: [OE-core] [PATCH] kernel.bbclass: Stop creating empty .scmversion files

[Paul Burton]

Hi Martin & Bruce,

Thanks for your responses & filling in some of the background here.

On Tue, Mar 31, 2020 at 6:32 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> Also note that in 2017 Trevor Woerner tried exactly the same fix that
> you are doing, but ended up retracting it when he found a test case
> that was still adding a + to the version.
>
> see: [OE-core] [PATCH] meta/classes/kernel.bbclass: revert 56fe5300ab5
>
> It might be worth checking with Trevor to see if he recalls what case
> it was where the + snuck back in.

Absolutely - Trevor if you recall any details they'd be very much
appreciated. I have my fingers crossed it might have been a case like
the one Martin describes below :)

On Tue, Mar 31, 2020 at 7:03 PM Martin Jansa <martin.jansa@gmail.com> wrote:
> Another piece of this puzzle might also be that in 2012 I was still using minimalistic gentoo chroot, which was shared across all builders as git repository, so even when you were building some kernel from tarball it might have incorrectly assume that the kernel repo is dirty (even when it was the git repo in top level rootfs directory which was dirty).

Interesting - I think we should be able to deal with that case by
setting the GIT_CEILING_DIRECTORIES environment variable, I'll give
that a go.

Thanks,
    Paul

[PATCH v2] kernel.bbclass: Stop creating empty .scmversion files

[Paul Burton]

The kernel_do_configure() task creates empty .scmversion files within
both the source & build directories. The presence of these files causes
the scm_version function within the kernel's scripts/setlocalversion to
always output the empty string, breaking the kernel's
CONFIG_LOCALVERSION_AUTO=y functionality which appends that string to
the kernel version. Rather than appending the git commit hash or another
SCM revision to the kernel version, the empty string is appended causing
CONFIG_LOCALVERSION_AUTO to do nothing.

Remove the creation of the empty .scmversion files in order to restore
the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
of kernels built from non-tagged source & configured with
CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
actually running.

The .scmversion behavior was introduced for the build directory by
commit 56fe5300ab5a ("kernel.bbclass: fix extra + in kernelrelease") and
extended to the source directory by commit e3bf54731973
("kernel.bbclass: touch .scmversion also in ${S}"). The '+' character
referenced would be appended if the kernel believed it were being built
from a dirty working tree. If that is genuinely the case then this in
itself is useful information; hiding that fact can only serve to muddy a
user's understanding of what kernel they're actually running.

One case that Martin suggests may have been the original motivation for
these commits is building a kernel whose source is not coming from git,
but is a subdirectory of a larger git working tree. In that case git
will ascend through the parent directories of the kernel source until it
finds the .git directory of that larger repository & report version
information that is nonsensical with regards to the kernel. As such,
prevent this from happening by setting the GIT_CEILING_DIRECTORIES
environment variable such that git will not ascend outside of the kernel
source directory and therefore won't pick up on version information that
doesn't relate to the kernel.

Signed-off-by: Paul Burton <paulburton@google.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Martin Jansa <martin.jansa@gmail.com>
Cc: Trevor Woerner <twoerner@gmail.com>
---
 meta/classes/kernel.bbclass | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a724645466..bf0b14285e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -171,6 +171,17 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
 KERNEL_IMAGEDEST ?= "boot"
 
+# The kernel's scripts/setlocalversion invokes git to determine whether we're
+# building from source that isn't clean or isn't tagged, and append that
+# information to the kernel version if CONFIG_LOCALVERSION_AUTO is enabled. If
+# we're building kernel source that isn't directly from git, but is a
+# subdirectory of a larger git repository, then we need to ensure the kernel's
+# script doesn't pick up on the state of that larger git repository to prevent
+# it reporting incorrect version information. We do that by ensuring git won't
+# ascend above the kernel source directory whilst searching for a .git
+# directory.
+export GIT_CEILING_DIRECTORIES = "${@os.path.dirname('${S}')}"
+
 #
 # configuration
 #
@@ -521,12 +532,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
 do_configure[prefuncs] += "check_oldest_kernel"
 
 kernel_do_configure() {
-	# fixes extra + in /lib/modules/2.6.37+
-	# $ scripts/setlocalversion . => +
-	# $ make kernelversion => 2.6.37
-	# $ make kernelrelease => 2.6.37+
-	touch ${B}/.scmversion ${S}/.scmversion
-
 	if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
 		mv "${S}/.config" "${B}/.config"
 	fi
-- 
2.26.0.rc2.310.g2932bb562d-goog

Re: [OE-core] [PATCH v2] kernel.bbclass: Stop creating empty .scmversion files

[Richard Purdie]

On Wed, 2020-04-01 at 12:41 -0700, Paul Burton via lists.openembedded.org wrote:
> The kernel_do_configure() task creates empty .scmversion files within
> both the source & build directories. The presence of these files causes
> the scm_version function within the kernel's scripts/setlocalversion to
> always output the empty string, breaking the kernel's
> CONFIG_LOCALVERSION_AUTO=y functionality which appends that string to
> the kernel version. Rather than appending the git commit hash or another
> SCM revision to the kernel version, the empty string is appended causing
> CONFIG_LOCALVERSION_AUTO to do nothing.
> 
> Remove the creation of the empty .scmversion files in order to restore
> the kernel's CONFIG_LOCALVERSION_AUTO functionality. This allows users
> of kernels built from non-tagged source & configured with
> CONFIG_LOCALVERSION_AUTO=y to better determine what kernel they're
> actually running.
> 
> The .scmversion behavior was introduced for the build directory by
> commit 56fe5300ab5a ("kernel.bbclass: fix extra + in kernelrelease") and
> extended to the source directory by commit e3bf54731973
> ("kernel.bbclass: touch .scmversion also in ${S}"). The '+' character
> referenced would be appended if the kernel believed it were being built
> from a dirty working tree. If that is genuinely the case then this in
> itself is useful information; hiding that fact can only serve to muddy a
> user's understanding of what kernel they're actually running.
> 
> One case that Martin suggests may have been the original motivation for
> these commits is building a kernel whose source is not coming from git,
> but is a subdirectory of a larger git working tree. In that case git
> will ascend through the parent directories of the kernel source until it
> finds the .git directory of that larger repository & report version
> information that is nonsensical with regards to the kernel. As such,
> prevent this from happening by setting the GIT_CEILING_DIRECTORIES
> environment variable such that git will not ascend outside of the kernel
> source directory and therefore won't pick up on version information that
> doesn't relate to the kernel.
> 
> Signed-off-by: Paul Burton <paulburton@google.com>
> Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
> Cc: Martin Jansa <martin.jansa@gmail.com>
> Cc: Trevor Woerner <twoerner@gmail.com>
> ---
>  meta/classes/kernel.bbclass | 17 +++++++++++------
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index a724645466..bf0b14285e 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -171,6 +171,17 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
>  KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
>  KERNEL_IMAGEDEST ?= "boot"
>  
> +# The kernel's scripts/setlocalversion invokes git to determine whether we're
> +# building from source that isn't clean or isn't tagged, and append that
> +# information to the kernel version if CONFIG_LOCALVERSION_AUTO is enabled. If
> +# we're building kernel source that isn't directly from git, but is a
> +# subdirectory of a larger git repository, then we need to ensure the kernel's
> +# script doesn't pick up on the state of that larger git repository to prevent
> +# it reporting incorrect version information. We do that by ensuring git won't
> +# ascend above the kernel source directory whilst searching for a .git
> +# directory.
> +export GIT_CEILING_DIRECTORIES = "${@os.path.dirname('${S}')}"
> +
>  #
>  # configuration
>  #
> @@ -521,12 +532,6 @@ check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
>  do_configure[prefuncs] += "check_oldest_kernel"
>  
>  kernel_do_configure() {
> -	# fixes extra + in /lib/modules/2.6.37+
> -	# $ scripts/setlocalversion . => +
> -	# $ make kernelversion => 2.6.37
> -	# $ make kernelrelease => 2.6.37+
> -	touch ${B}/.scmversion ${S}/.scmversion
> -
>  	if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ ! -f "${B}/.config" ]; then
>  		mv "${S}/.config" "${B}/.config"
>  	fi

I get very nervous about patches like this that come in a day before
the final release build. I'm not 100% certain its this patch but a
build with this patch in resulted in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/1747
https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1749
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1753
https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/649

and a ton of other similar failures.

I'm starting a retest without it.

Cheers,

Richard

Re: [OE-core] [PATCH v2] kernel.bbclass: Stop creating empty .scmversion files

[Paul Burton]

Hi Richard,

On Wed, Apr 1, 2020 at 4:54 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I get very nervous about patches like this that come in a day before
> the final release build.

Absolutely - I would too; I didn't realize a release was imminent &
certainly had no expectation this would be part of it.

> I'm not 100% certain its this patch but a
> build with this patch in resulted in:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/1747
> https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/1749
> https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/1753
> https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/649
>
> and a ton of other similar failures.
>
> I'm starting a retest without it.

Thanks for the pointers, I'll do some digging.

Paul