Skip to content
  1. Sep 06, 2023
  3. Sep 04, 2023
  5. Sep 01, 2023
  7. Aug 29, 2023
  9. Aug 22, 2023
  11. Aug 21, 2023
  13. Aug 20, 2023
  15. Aug 16, 2023
  17. Aug 13, 2023
  19. Aug 08, 2023
    • Rasmus Villemoes's avatar
      scripts/setlocalversion: also consider annotated tags of the form vx.y.z-${file_localversion} · 01e89a4a
      Rasmus Villemoes authored 
      Commit 6ab7e1f9

 ("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: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      01e89a4a
    • Rasmus Villemoes's avatar
      scripts/setlocalversion: clean up stale comment · 3354c64d
      Rasmus Villemoes authored 
      Nobody has complained since 2a73cce2

 ("scripts/setlocalversion:
remove mercurial, svn and git-svn supports"), so let's also clean up
the header comment accordingly.

Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      3354c64d
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: split debian/rules · d9287ea8
      Masahiro Yamada authored 
      

debian/rules is generated by shell, but the escape sequence (\$) is
unreadable.

debian/rules embeds only two variables (ARCH and KERNELRELEASE).

Split them out to debian/rules.vars, and check-in the rest of Makefile
code to scripts/package/debian/rules.

Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Tested-by: default avatarNathan Chancellor <nathan@kernel.org>
Reviewed-by: default avatarNicolas Schier <nicolas@fjasle.eu>
      d9287ea8
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: use Debian compliant shebang for debian/rules · 4b970e43
      Masahiro Yamada authored 
      Debian Policy "4.9. Main building script: debian/rules" requires
"debian/rules must start with the line #!/usr/bin/make -f". [1]

Currently, Kbuild does not follow this policy.

When Kbuild generates debian/rules, "#!$(command -v $MAKE) -f" is
expanded by shell. The resuling string may not be "#!/usr/bin/make -f".

There was a reason to opt out the Debian policy.

If you run '/path/to/my/custom/make deb-pkg', debian/rules must also be
invoked by the same Make program. If #!/usr/bin/make were hard-coded in
debian/rules, the sub-make would be executed by a possibly different
Make version.

This is problematic due to the MAKEFLAGS incompatibility, especially the
job server flag. Old Make versions used --jobserver-fds to propagate job
server file descriptors, but Make >= 4.2 uses --jobserver-auth. The flag
disagreement between the parent/child Makes would result in a process
fork explosion.

However, having a non-standard path in the shebang causes another issue;
the generated source package is not portable as such a path does not
exist in other build environments.

This commit solves those conflicting demands.

Hard-code '#!/usr/bin/make -f' in debian/rules to create a portable and
Debian-compliant source package.

Pass '--rules-file=$(MAKE) -f debian/rules' when dpkg-buildpackage is
invoked from Makefile so that debian/rules is executed by the same Make
program as used to start Kbuild.

[1] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules



Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
Tested-by: default avatarNathan Chancellor <nathan@kernel.org>
Reviewed-by: default avatarNicolas Schier <nicolas@fjasle.eu>
      4b970e43
  21. Jul 31, 2023
  23. Jul 24, 2023