From: Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
Randy Dunlap <rdunlap@infradead.org>,
Brian Norris <briannorris@chromium.org>,
Bhaskar Chowdhury <unixbhaskar@gmail.com>,
Nico Schottelius <nico-linuxsetlocalversion@schottelius.org>,
Guenter Roeck <linux@roeck-us.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] scripts/setlocalversion: make git describe output more reliable
Date: Thu, 17 Sep 2020 14:22:57 +0200 [thread overview]
Message-ID: <87pn6k384e.fsf@ungleich.ch> (raw)
In-Reply-To: <20200917065615.18843-1-linux@rasmusvillemoes.dk>
Thanks for the patch Rasmus. Overall it looks good to me, be aligned to
the stable patch submission rules makes sense. A tiny thing though:
I did not calculate the exact collision probability with 12 characters
and it does not make sense to even discuss this, if this is a current
rule for stable patches. However we have a couple of 12's scattered in
the code. And if the submission rule changes in the future, we should
have a single location to update it.
So I suggest you introduce something on the line of:
...
num_chars=12
...
--abbrev=$num_chars
...
I guess you get the picture.
Greetings from the sunny mountains,
Nico
Rasmus Villemoes <linux@rasmusvillemoes.dk> writes:
> When building for an embedded target using Yocto, we're sometimes
> observing that the version string that gets built into vmlinux (and
> thus what uname -a reports) differs from the path under /lib/modules/
> where modules get installed in the rootfs, but only in the length of
> the -gabc123def suffix. Hence modprobe always fails.
>
> The problem is that Yocto has the concept of "sstate" (shared state),
> which allows different developers/buildbots/etc. to share build
> artifacts, based on a hash of all the metadata that went into building
> that artifact - and that metadata includes all dependencies (e.g. the
> compiler used etc.). That normally works quite well; usually a clean
> build (without using any sstate cache) done by one developer ends up
> being binary identical to a build done on another host. However, one
> thing that can cause two developers to end up with different builds
> [and thus make one's vmlinux package incompatible with the other's
> kernel-dev package], which is not captured by the metadata hashing, is
> this `git describe`: The output of that can be affected by
>
> (1) git version: before 2.11 git defaulted to a minimum of 7, since
> 2.11 (git.git commit e6c587) the default is dynamic based on the
> number of objects in the repo
> (2) hence even if both run the same git version, the output can differ
> based on how many remotes are being tracked (or just lots of local
> development branches or plain old garbage)
> (3) and of course somebody could have a core.abbrev config setting in
> ~/.gitconfig
>
> So in order to avoid `uname -a` output relying on such random details
> of the build environment which are rather hard to ensure are
> consistent between developers and buildbots, make sure the abbreviated
> sha1 always consists of exactly 12 hex characters. That is consistent
> with the current rule for -stable patches, and is almost always enough
> to identify the head commit unambigously - in the few cases where it
> does not, the v5.4.3-00021- prefix would certainly nail it down.
>
> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
> ---
> v2: use 12 instead of 15, and ensure that the result does have exactly
> 12 hex chars.
>
> scripts/setlocalversion | 21 ++++++++++++++++-----
> 1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index 20f2efd57b11..bb709eda96cd 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -45,7 +45,7 @@ scm_version()
>
> # Check for git and a git repo.
> if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
> - head=$(git rev-parse --verify --short HEAD 2>/dev/null); then
> + head=$(git rev-parse --verify HEAD 2>/dev/null); then
>
> # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
> # it, because this version is defined in the top level Makefile.
> @@ -59,11 +59,22 @@ scm_version()
> fi
> # If we are past a tagged commit (like
> # "v2.6.30-rc5-302-g72357d5"), we pretty print it.
> - if atag="$(git describe 2>/dev/null)"; then
> - echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
> -
> - # If we don't have a tag at all we print -g{commitish}.
> + #
> + # Ensure the abbreviated sha1 has exactly 12
> + # hex characters, to make the output
> + # independent of git version, local
> + # core.abbrev settings and/or total number of
> + # objects in the current repository - passing
> + # --abbrev=12 ensures a minimum of 12, and the
> + # awk substr() then picks the 'g' and first 12
> + # hex chars.
> + if atag="$(git describe --abbrev=12 2>/dev/null)"; then
> + echo "$atag" | awk -F- '{printf("-%05d-%s", $(NF-1),substr($(NF),0,13))}'
> +
> + # If we don't have a tag at all we print -g{commitish},
> + # again using exactly 12 hex chars.
> else
> + head="$(echo $head | cut -c1-12)"
> printf '%s%s' -g $head
> fi
> fi
--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
next prev parent reply other threads:[~2020-09-17 13:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 11:26 [PATCH] scripts/setlocalversion: make git describe output more reliable Rasmus Villemoes
2020-09-10 14:28 ` Guenter Roeck
2020-09-10 14:34 ` Masahiro Yamada
2020-09-10 19:05 ` Brian Norris
2020-09-11 8:28 ` Rasmus Villemoes
2020-09-16 14:28 ` Masahiro Yamada
2020-09-16 15:23 ` Rasmus Villemoes
2020-09-16 18:01 ` Masahiro Yamada
2020-09-16 19:31 ` Rasmus Villemoes
2020-09-17 0:48 ` Masahiro Yamada
2020-09-10 22:56 ` Bhaskar Chowdhury
2020-09-16 8:48 ` Rasmus Villemoes
2020-09-17 6:56 ` [PATCH v2] " Rasmus Villemoes
2020-09-17 12:22 ` Nico Schottelius [this message]
2020-09-17 12:58 ` Rasmus Villemoes
2020-09-21 9:35 ` Nico Schottelius
2020-09-24 17:27 ` Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87pn6k384e.fsf@ungleich.ch \
--to=nico-linuxsetlocalversion@schottelius.org \
--cc=briannorris@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=linux@roeck-us.net \
--cc=rdunlap@infradead.org \
--cc=unixbhaskar@gmail.com \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.