linux-toradex.git/scripts/setlocalversion, branch v6.11-rc7

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

kbuild: do not put .scmversion into the source tarball

2023-01-30T04:00:30+00:00

.scmversion is used by (src)rpm-pkg and deb-pkg to carry KERNELRELEASE.

In fact, deb-pkg does not rely on it any more because the generated
debian/rules specifies KERNELRELEASE from the command line.

Do likwise for (src)rpm-pkg, and remove this feature.
For the same reason, you do not need to save LOCALVERSION in the
spec file.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nicolas Schier

kbuild: do not quote string values in include/config/auto.conf

2022-01-08T09:03:57+00:00

The previous commit fixed up all shell scripts to not include
include/config/auto.conf.

Now that include/config/auto.conf is only included by Makefiles,
we can change it into a more Make-friendly form.

Previously, Kconfig output string values enclosed with double-quotes
(both in the .config and include/config/auto.conf):

    CONFIG_X="foo bar"

Unlike shell, Make handles double-quotes (and single-quotes as well)
verbatim. We must rip them off when used.

There are some patterns:

  [1] $(patsubst "%",%,$(CONFIG_X))
  [2] $(CONFIG_X:"%"=%)
  [3] $(subst ",,$(CONFIG_X))
  [4] $(shell echo $(CONFIG_X))

These are not only ugly, but also fragile.

[1] and [2] do not work if the value contains spaces, like
   CONFIG_X=" foo bar "

[3] does not work correctly if the value contains double-quotes like
   CONFIG_X="foo\"bar"

[4] seems to work better, but has a cost of forking a process.

Anyway, quoted strings were always PITA for our Makefiles.

This commit changes Kconfig to stop quoting in include/config/auto.conf.

These are the string type symbols referenced in Makefiles or scripts:

    ACPI_CUSTOM_DSDT_FILE
    ARC_BUILTIN_DTB_NAME
    ARC_TUNE_MCPU
    BUILTIN_DTB_SOURCE
    CC_IMPLICIT_FALLTHROUGH
    CC_VERSION_TEXT
    CFG80211_EXTRA_REGDB_KEYDIR
    EXTRA_FIRMWARE
    EXTRA_FIRMWARE_DIR
    EXTRA_TARGETS
    H8300_BUILTIN_DTB
    INITRAMFS_SOURCE
    LOCALVERSION
    MODULE_SIG_HASH
    MODULE_SIG_KEY
    NDS32_BUILTIN_DTB
    NIOS2_DTB_SOURCE
    OPENRISC_BUILTIN_DTB
    SOC_CANAAN_K210_DTB_SOURCE
    SYSTEM_BLACKLIST_HASH_LIST
    SYSTEM_REVOCATION_KEYS
    SYSTEM_TRUSTED_KEYS
    TARGET_CPU
    UNUSED_KSYMS_WHITELIST
    XILINX_MICROBLAZE0_FAMILY
    XILINX_MICROBLAZE0_HW_VER
    XTENSA_VARIANT_NAME

I checked them one by one, and fixed up the code where necessary.

Signed-off-by: Masahiro Yamada