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 <[email protected]>
> Cc: Bruce Ashfield <[email protected]>
> Cc: Martin Jansa <[email protected]>
> Cc: Trevor Woerner <[email protected]>
> ---
> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#136943):
https://lists.openembedded.org/g/openembedded-core/message/136943
Mute This Topic: https://lists.openembedded.org/mt/72709639/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
