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

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

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