1. 10 Jan, 2024 1 commit
  2. 05 Jan, 2024 6 commits
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: do not search for 'scripts' directory under arch/ · 358c3f8c
      Masahiro Yamada authored
      The 'scripts' directory was searched under arch/${SRCARCH} to copy
      arch/ia64/scripts, but commit cf8e8658 ("arch: Remove Itanium
      (IA-64) architecture") removed arch/ia64/ entirely.
      
      There is another 'scripts' directory in arch/um/, but this script
      is never executed with SRCARCH=um because UML does not support the
      linux-headers package.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      358c3f8c
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: use build ID instead of debug link for dbg package · 16c36f88
      Masahiro Yamada authored
      There are two ways of managing separate debug info files:
      
       [1] The executable contains the .gnu_debuglink section, which specifies
           the name and the CRC of the separate debug info file.
      
       [2] The executable contains a build ID, and the corresponding debug info
           file is placed in the .build-id directory.
      
      We could do both, but the former, which 'make deb-pkg' currently does,
      results in complicated installation steps because we need to manually
      strip the debug sections, create debug links, and re-sign the modules.
      Besides, it is not working with module compression.
      
      This commit abandons the approach [1], and instead opts for [2].
      
      Debian kernel commit de26137e2a9f ("Drop not needed extra step to add
      debug links") also stopped adding debug links.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      16c36f88
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: use more debhelper commands in builddeb · 5e73758b
      Masahiro Yamada authored
      Commit 36862e14 ("kbuild: deb-pkg: use dh_listpackages to know
      enabled packages") started to require the debhelper tool suite.
      
      Use more dh_* commands in create_package():
      
       - dh_installdocs to install copyright
       - dh_installchangelogs to install changelog
       - dh_compress to compress changelog
       - dh_fixperms to replace the raw chmod command
       - dh_gencontrol to replace the raw dpkg-gencontrol command
       - dh_md5sums to record the md5sum of included files
       - dh_builddeb to replace the raw dpkg-deb command
      
      Set DEB_RULES_REQUIRES_ROOT to 'no' in case debian/rules is executed
      directly.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      5e73758b
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: remove unneeded '-f $srctree/Makefile' in debian/rules · 68e262f8
      Masahiro Yamada authored
      This is unneeded because the Makefile in the output directory wraps
      the top-level Makefile in the srctree.
      
      Just run $(MAKE) irrespective of the build location.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      68e262f8
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: allow to run debian/rules from output directory · eaf80f7f
      Masahiro Yamada authored
      'make O=... deb-pkg' creates the debian directory in the output
      directory. However, currently it is impossible to run debian/rules
      created in the separate output directory.
      
      This commit delays the $(srctree) expansion by escaping '$' and by
      quoting the entire command, making it possible to run debian/rules in
      the output directory.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      eaf80f7f
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: set DEB_* variables if debian/rules is directly executed · 159956f3
      Masahiro Yamada authored
      Since commit 491b146d ("kbuild: builddeb: Eliminate debian/arch
      use"), direct execution of debian/rules results in the following error:
      
        dpkg-architecture: error: unknown option 'DEB_HOST_MULTIARCH'
      
      The current code:
      
        dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH
      
      ... does not look sensible because:
      
       - For this code to work correctly, DEB_HOST_ARCH must be pre-defined,
         which is true when the packages are built via dpkg-buildpackage.
         In this case, DEB_HOST_MULTIARCH is also likely defined, hence there
         is no need to query DEB_HOST_MULTIARCH in the first place.
      
       - If DEB_HOST_MULTIARCH is undefined, DEB_HOST_ARCH is likely undefined
         too. So, you cannot query DEB_HOST_MULTIARCH in this way. This is
         mostly the case where debian/rules is directly executed.
      
      When debian/rules is directly executed, querying DEB_HOST_MUCHARCH is
      not enough because we need to know DEB_{BUILD,HOST}_GNU_TYPE as well.
      
      All DEB_* variables are defined when the package build is initiated by
      dpkg-buildpackage, but otherwise, let's call dpkg-architecture to set
      all DEB_* environment variables.
      
      This requires dpkg 1.20.6 or newer because --print-format option
      was added in dpkg commit 7c54fa2b232e ("dpkg-architecture: Add a
      --print-format option").
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      159956f3
  3. 29 Dec, 2023 10 commits
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: squash scripts/package/deb-build-option to debian/rules · 7d4f07d5
      Masahiro Yamada authored
      The binary-arch target needs to use the same CROSS_COMPILE as used in
      build-arch; otherwise, 'make run-command' may attempt to resync the
      .config file.
      
      Squash scripts/package/deb-build-option into debian/rules, as it is a
      small amount of code.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      7d4f07d5
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: factor out common Make options in debian/rules · 466e6fc4
      Masahiro Yamada authored
      This avoids code duplication between binary-arch and built-arch.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      466e6fc4
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: hard-code Build-Depends · b88365b6
      Masahiro Yamada authored
      The condition to require libelf-dev:native is stale because objtool is
      now enabled by CONFIG_OBJTOOL instead of CONFIG_UNWINDER_ORC. Not only
      objtool but also resolve_btfids requires libelf-dev:native; therefore,
      CONFIG_DEBUG_INFO_BTF should be checked as well.
      
      Similarly, CONFIG_SYSTEM_TRUSTED_KEYRING is not the only case that
      requires libssl-dev:native.
      
      Perhaps, the following code would provide better coverage, but it is
      hard to maintain (and may still be imperfect).
      
        if is_enabled CONFIG_OBJTOOL ||
           is_enabled CONFIG_DEBUG_INFO_BTF; then
                build_depends="${build_depends}, libelf-dev:native"
        fi
      
        if is_enabled CONFIG_SYSTEM_TRUSTED_KEYRING ||
           is_enabled CONFIG_SYSTEM_REVOCATION_LIST ||
           is_enabled CONFIG_MODULE_SIG_FORMAT; then
                build_depends="${build_depends}, libssl-dev:native"
        fi
      
      Let's hard-code the build dependency.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      b88365b6
    • Masahiro Yamada's avatar
      kbuild: deb-pkg: split debian/copyright from the mkdebian script · 9c65810c
      Masahiro Yamada authored
      Copy debian/copyright instead of generating it by the 'cat' command.
      
      I also updated '2018' to '2023' while I was here.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      9c65810c
    • Dmitry Safonov's avatar
      gen_init_cpio: Apply mtime supplied by user to all file types · f3b2306b
      Dmitry Safonov authored
      Currently gen_init_cpio -d <timestamp> is applied to symlinks,
      directories and special files. These files are created by
      gen_init_cpio from their description. Without <timestamp> option
      current time(NULL) is used. And regular files that go in initramfs
      are created before cpio generation, so their mtime(s) are preserved.
      
      This is usually not an issue as reproducible builds should rebuild
      everything in the distribution, including binaries, configs and whatever
      other regular files may find their way into kernel's initramfs.
      
      On the other hand, gen_initramfs.sh usage claims:
      >	-d <date>      Use date for all file mtime values
      
      Ar Arista initramfs files are managed with version control system
      that preserves mtime. Those are configs, boot parameters, init scripts,
      version files, platform-specific files, probably some others, too.
      
      While it's certainly possible to work this around by copying the file
      into temp directory and adjusting mtime prior to gen_init_cpio call,
      I don't see why it needs workarounds.
      
      The intended user of -d <date> option is the one that needs to create
      a reproducible build, see commit a8b8017c ("initramfs: Use
      KBUILD_BUILD_TIMESTAMP for generated entries"). If a user wants
      the build reproduction, they use -d <date>, which can be set on all
      types of files, without surprising exceptions and workarounds.
      Let's KISS here and just apply the time that user specified
      with -d option.
      Based-on-a-patch-by: default avatarBaptiste Covolato <baptiste@arista.com>
      Link: https://lore.kernel.org/lkml/20181025215133.20138-1-baptiste@arista.com/Signed-off-by: default avatarDmitry Safonov <dima@arista.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      f3b2306b
    • Masahiro Yamada's avatar
      kbuild: resolve symlinks for O= properly · 7beba04e
      Masahiro Yamada authored
      Currently, Kbuild follows the logical chain of directories for the O=
      option, just like 'cd' (or 'realpath --logical') does.
      
      Example:
      
          $ mkdir -p /tmp/a /tmp/x/y
          $ ln -s /tmp/x/y /tmp/a/b
          $ realpath /tmp/a/b/..
          /tmp/x
          $ realpath --logical /tmp/a/b/..
          /tmp/a
          $ make O=/tmp/a/b/.. defconfig
          make[1]: Entering directory '/tmp/a'
            [snip]
          make[1]: Leaving directory '/tmp/a'
      
      'make O=/tmp/a/b/.. defconfig' creates the kernel configuration in
      /tmp/a instead of /tmp/x despite /tmp/a/b/.. resolves to /tmp/x.
      
      This is because Kbuild internally uses the 'cd ... && pwd' for the
      path resolution, but this behavior is not predictable for users.
      Additionally, it is not consistent with how the Kbuild handles the
      M= option or GNU Make works with 'make -C /tmp/a/b/..'.
      
      Using the physical directory structure for the O= option seems more
      reasonable.
      
      The comment says "expand a shell special character '~'", but it has
      already been expanded to the home directory in the command line.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNicolas Schier <n.schier@avm.de>
      7beba04e
    • John Moon's avatar
      docs: dev-tools: Add UAPI checker documentation · 8c88bc5b
      John Moon authored
      Add detailed documentation for scripts/check-uapi.sh.
      Signed-off-by: default avatarJohn Moon <quic_johmoo@quicinc.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      8c88bc5b
    • John Moon's avatar
      check-uapi: Introduce check-uapi.sh · 1f7f31bf
      John Moon authored
      While the kernel community has been good at maintaining backwards
      compatibility with kernel UAPIs, it would be helpful to have a tool
      to check if a commit introduces changes that break backwards
      compatibility.
      
      To that end, introduce check-uapi.sh: a simple shell script that
      checks for changes to UAPI headers using libabigail.
      
      libabigail is "a framework which aims at helping developers and
      software distributors to spot some ABI-related issues like interface
      incompatibility in ELF shared libraries by performing a static
      analysis of the ELF binaries at hand."
      
      The script uses one of libabigail's tools, "abidiff", to compile the
      changed header before and after the commit to detect any changes.
      
      abidiff "compares the ABI of two shared libraries in ELF format. It
      emits a meaningful report describing the differences between the two
      ABIs."
      
      The script also includes the ability to check the compatibility of
      all UAPI headers across commits. This allows developers to inspect
      the stability of the UAPIs over time.
      Signed-off-by: default avatarJohn Moon <quic_johmoo@quicinc.com>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      1f7f31bf
    • Leonardo Bras's avatar
      scripts: Introduce a default git.orderFile · 67f8f1e7
      Leonardo Bras authored
      When reviewing patches, it looks much nicer to have some changes shown
      before others, which allow better understanding of the patch before the
      the .c files reviewing.
      
      Introduce a default git.orderFile, in order to help developers getting the
      best ordering easier.
      Signed-off-by: default avatarLeonardo Bras <leobras@redhat.com>
      Acked-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      67f8f1e7
    • Sergey Senozhatsky's avatar
      kconfig: WERROR unmet symbol dependency · 15d3f766
      Sergey Senozhatsky authored
      When KCONFIG_WERROR env variable is set treat unmet direct
      symbol dependency as a terminal condition (error).
      Suggested-by: default avatarStefan Reinauer <reinauer@google.com>
      Signed-off-by: default avatarSergey Senozhatsky <senozhatsky@chromium.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      15d3f766
  4. 28 Dec, 2023 6 commits
  5. 10 Dec, 2023 11 commits
  6. 03 Dec, 2023 4 commits
  7. 28 Nov, 2023 2 commits