1. 20 Aug, 2023 2 commits
  2. 16 Aug, 2023 1 commit
  3. 13 Aug, 2023 2 commits
  4. 07 Aug, 2023 4 commits
    • 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-rulesSigned-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
  5. 31 Jul, 2023 4 commits
  6. 24 Jul, 2023 24 commits
  7. 23 Jul, 2023 3 commits