kernel/linux.git/scripts/setlocalversion, branch v6.19.11

setlocalversion: add -e option

2024-11-27T23:11:56+00:00

Set the -e option to ensure this script fails on any unexpected errors. Without this change, the kernel build may continue running with an incorrect string in include/config/kernel.release. Currently, try_tag() returns 1 when the expected tag is not found as an ancestor, but this is a case where the script should continue. Signed-off-by: Masahiro Yamada

setlocalversion: work around "git describe" performance

2024-11-27T23:11:56+00:00

Contrary to expectations, passing a single candidate tag to "git describe" is slower than not passing any --match options. $ time git describe --debug ... traversed 10619 commits ... v6.12-rc5-63-g0fc810ae3ae1 real 0m0.169s $ time git describe --match=v6.12-rc5 --debug ... traversed 1310024 commits v6.12-rc5-63-g0fc810ae3ae1 real 0m1.281s In fact, the --debug output shows that git traverses all or most of history. For some repositories and/or git versions, those 1.3s are actually 10-15 seconds. This has been acknowledged as a performance bug in git [1], and a fix is on its way [2]. However, no solution is yet in git.git, and even when one lands, it will take quite a while before it finds its way to a release and for $random_kernel_developer to pick that up. So rewrite the logic to use plumbing commands. For each of the candidate values of $tag, we ask: (1) is $tag even an annotated tag? (2) Is it eligible to describe HEAD, i.e. an ancestor of HEAD? (3) If so, how many commits are in $tag..HEAD? I have tested that this produces the same output as the current script for ~700 random commits between v6.9..v6.10. For those 700 commits, and in my git repo, the 'make -s kernelrelease' command is on average ~4 times faster with this patch applied (geometric mean of ratios). For the commit mentioned in Josh's original report [3], the time-consuming part of setlocalversion goes from $ time git describe --match=v6.12-rc5 c1e939a21eb1 v6.12-rc5-44-gc1e939a21eb1 real 0m1.210s to $ time git rev-list --count --left-right v6.12-rc5..c1e939a21eb1 0 44 real 0m0.037s [1] https://lore.kernel.org/git/20241101113910.GA2301440@coredump.intra.peff.net/ [2] https://lore.kernel.org/git/20241106192236.GC880133@coredump.intra.peff.net/ [3] https://lore.kernel.org/lkml/309549cafdcfe50c4fceac3263220cc3d8b109b2.1730337435.git.jpoimboe@kernel.org/ Reported-by: Sean Christopherson Closes: https://lore.kernel.org/lkml/ZPtlxmdIJXOe0sEy@google.com/ Reported-by: Josh Poimboeuf Closes: https://lore.kernel.org/lkml/309549cafdcfe50c4fceac3263220cc3d8b109b2.1730337435.git.jpoimboe@kernel.org/ Tested-by: Josh Poimboeuf Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada

scripts/setlocalversion: also consider annotated tags of the form vx.y.z-${file_localversion}

2023-08-07T16:08:54+00:00

Commit 6ab7e1f95e96 ("setlocalversion: use only the correct release tag for git-describe") was absolutely correct to limit which annotated tags would be used to compute the -01234-gabcdef suffix. Otherwise, if some random annotated tag exists closer to HEAD than the vX.Y.Z one, the commit count would be too low. However, since the version string always includes the ${file_localversion} part, now the problem is that the count can be too high. For example, building an 6.4.6-rt8 kernel with a few patches on top, I currently get $ make -s kernelrelease 6.4.6-rt8-00128-gd78b7f406397 But those 128 commits include the 100 commits that are in v6.4.6..v6.4.6-rt8, so this is somewhat misleading. Amend the logic so that, in addition to the linux-next consideration, the script also looks for a tag corresponding to the 6.4.6-rt8 part of what will become the `uname -r` string. With this patch (so 29 patches on top of v6.4.6-rt8), one instead gets $ make -s kernelrelease 6.4.6-rt8-00029-gd533209291a2 While there, note that the line git describe --exact-match --match=$tag $tag 2>/dev/null obviously asks if $tag is an annotated tag, but it does not actually tell if the commit pointed to has any relation to HEAD. So remove both uses of --exact-match, and instead just ask if the description generated is identical to the tag we provided. Since we then already have the result of git describe --match=$tag we also end up reducing the number of times we invoke "git describe". Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada

scripts/setlocalversion: clean up stale comment

2023-08-07T16:08:54+00:00

Nobody has complained since 2a73cce2dad3 ("scripts/setlocalversion: remove mercurial, svn and git-svn supports"), so let's also clean up the header comment accordingly. Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada

kbuild: use git-archive for source package creation

2023-03-16T13:46:12+00:00

Commit 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git") added a new tool, scripts/list-gitignored. My intention was to create source packages without cleaning the source tree, without relying on git. Linus strongly objected to it, and suggested using 'git archive' instead. [1] [2] [3] This commit goes in that direction - Remove scripts/list-gitignored.c and rewrites Makefiles and scripts to use 'git archive' for building Debian and RPM source packages. It also makes 'make perf-tar*-src-pkg' use 'git archive' again. Going forward, building source packages is only possible in a git-managed tree. Building binary packages does not require git. [1]: https://lore.kernel.org/lkml/CAHk-=wi49sMaC7vY1yMagk7eqLK=1jHeHQ=yZ_k45P=xBccnmA@mail.gmail.com/ [2]: https://lore.kernel.org/lkml/CAHk-=wh5AixGsLeT0qH2oZHKq0FLUTbyTw4qY921L=PwYgoGVw@mail.gmail.com/ [3]: https://lore.kernel.org/lkml/CAHk-=wgM-W6Fu==EoAVCabxyX8eYBz9kNC88-tm9ExRQwA79UQ@mail.gmail.com/ Fixes: 5c3d1d0abb12 ("kbuild: add a tool to list files ignored by git") Fixes: e0ca16749ac3 ("kbuild: make perf-tar*-src-pkg work without relying on git") Suggested-by: Linus Torvalds Signed-off-by: Masahiro Yamada

setlocalversion: use only the correct release tag for git-describe

2023-02-14T17:56:27+00:00

Currently, setlocalversion uses any annotated tag for git-describe. If we are at a tagged commit, it will not append the commit hash. $ git checkout v6.2-rc1^ $ make -s defconfig kernelrelease 6.1.0-14595-g292a089d78d3 $ git tag -a foo -m foo $ make -s kernelrelease 6.1.0 If a local tag 'foo' exists, it pretends to be a released version '6.1.0', while there are many commits on top of it. The output should be consistent irrespective of such a local tag. Pass the correct release tag to --match option of git-describe. In the mainline kernel, the SUBLEVEL is always '0', which is omitted from the tag. KERNELVERSION annotated tag 6.1.0 -> v6.1 (mainline) 6.2.0-rc5 -> v6.2-rc5 (mainline, release candidate) 6.1.7 -> v6.1.7 (stable) To preserve the behavior in linux-next, use the tag derived from localversion* files if exists. In linux-next, the local version is specified by the localversion-next file. Signed-off-by: Masahiro Yamada

setlocalversion: clean up the construction of version output

2023-02-05T12:18:23+00:00

Concatenate all components in the last line instead of accumulating them into the 'res' variable. No functional change is intended. A preparation for the next change. Signed-off-by: Masahiro Yamada

setlocalversion: absorb $(KERNELVERSION)

2023-02-05T09:51:20+00:00

Print $(KERNELVERSION) in setlocalversion so that the callers get simpler. Signed-off-by: Masahiro Yamada

setlocalversion: make indentation shallower

2023-02-05T09:34:20+00:00

Return earlier if we are not in the correct git repository. This makes the code more readable. Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier

setlocalversion: simplify the construction of the short version

2023-02-05T09:34:11+00:00

With the --short option given, scm_version() prints "+". Just append it. Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier