Add a new debug package to the PKGBUILD for the pacman-pkg target. The
debug package includes the non-stripped vmlinux file with debug symbols
for kernel debugging and profiling. The file is installed at
/usr/src/debug/${pkgbase}, with a symbolic link at
/usr/lib/modules/$(uname -r)/build/vmlinux. The debug package is built
by default.
Signed-off-by: Jose Fernandez <jose.fernandez@linux.dev>
Reviewed-by: Peter Jung <ptr1337@cachyos.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
objtree is defined and exported by the top-level Makefile. I prefer
not to override it.
There is no need to pass the absolute path of objtree. PKGBUILD can
detect it by itself.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
All build and package functions share the following commands:
export MAKEFLAGS="${KBUILD_MAKEFLAGS}"
cd "${objtree}"
Factor out the common code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
Introduce the PACMAN_EXTRAPACKAGES variable in PKGBUILD to allow users
to specify which additional packages are built by the pacman-pkg target.
Previously, the api-headers package was always included, and the headers
package was included only if CONFIG_MODULES=y. With this change, both
headers and api-headers packages are included by default. Users can now
control this behavior by setting PACMAN_EXTRAPACKAGES to a
space-separated list of desired extra packages or leaving it empty to
exclude all.
For example, to build only the base package without extras:
make pacman-pkg PACMAN_EXTRAPACKAGES=""
Signed-off-by: Jose Fernandez <jose.fernandez@linux.dev>
Reviewed-by: Peter Jung <ptr1337@cachyos.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
Tested-by: Christian Heusel <christian@heusel.eu>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
A long standing issue in the upstream kernel packaging is that the
linux-headers package is not cross-compiled.
For example, you can cross-build Debian packages for arm64 by running
the following command:
$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg
However, the generated linux-headers-*_arm64.deb is useless because the
host programs in it were built for your build machine architecture
(likely x86), not arm64.
The Debian kernel maintains its own Makefiles to cross-compile host
tools without relying on Kbuild. [1]
Instead of adding such full custom Makefiles, this commit adds a small
piece of code to cross-compile host programs located under the scripts/
directory.
A straightforward solution is to pass HOSTCC=${CROSS_COMPILE}gcc, but it
would also cross-compile scripts/basic/fixdep, which needs to be native
to process the if_changed_dep macro. (This approach may work under some
circumstances; you can execute foreign architecture programs with the
help of binfmt_misc because Debian systems enable CONFIG_BINFMT_MISC,
but it would require installing QEMU and libc for that architecture.)
A trick is to use the external module build (KBUILD_EXTMOD=), which
does not rebuild scripts/basic/fixdep. ${CC} needs to be able to link
userspace programs (CONFIG_CC_CAN_LINK=y).
There are known limitations:
- GCC plugins
It would possible to rebuild GCC plugins for the target architecture
by passing HOSTCXX=${CROSS_COMPILE}g++ with necessary packages
installed, but gcc on the installed system emits
"cc1: error: incompatible gcc/plugin versions".
- objtool and resolve_btfids
These are built by the tools build system. They are not covered by
the current solution. The resulting linux-headers package is broken
if CONFIG_OBJTOOL or CONFIG_DEBUG_INFO_BTF is enabled.
I only tested this with Debian, but it should work for other package
systems as well.
[1]: https://salsa.debian.org/kernel-team/linux/-/blob/debian/6.9.9-1/debian/rules.real#L586
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
In the same way as for other similar files, mark as ghost the new file
generated by depmod for configured weak dependencies for modules,
modules.weakdep, so that although it is not included in the package,
claim the ownership on it.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
semicolon separation in LC_ALL is wrong. Either variable needs to be
exported before as a separate commit or set as part of the commit in the
beginning. Used second variant.
This fixes broken build on user's locale setup which makes 'date' binary
to produce invalid characters in rpm changelog (e.g. cs_CZ.UTF-8 'čec'):
$ make binrpm-pkg
GEN rpmbuild/SPECS/kernel.spec
rpmbuild -bb rpmbuild/SPECS/kernel.spec --define='_topdirlinux/rpmbuild' \
--target x86_64-linux --build-in-place --noprep --define='_smp_mflags \
%{nil}' $(rpm -q rpm >/dev/null 2>&1 || echo --nodeps)
Building target platforms: x86_64-linux
Building for target x86_64-linux
error: bad date in %changelog: St čec 24 2024 user <user@somehost>
make[2]: *** [scripts/Makefile.package:71: binrpm-pkg] Error 1
make[1]: *** [linux/Makefile:1546: binrpm-pkg] Error 2
make: *** [Makefile:224: __sub-make] Error 2
Fixes: 301c10908e ("kbuild: rpm-pkg: introduce a simple changelog section for kernel.spec")
Signed-off-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Pull Kbuild updates from Masahiro Yamada:
- Remove tristate choice support from Kconfig
- Stop using the PROVIDE() directive in the linker script
- Reduce the number of links for the combination of CONFIG_KALLSYMS and
CONFIG_DEBUG_INFO_BTF
- Enable the warning for symbol reference to .exit.* sections by
default
- Fix warnings in RPM package builds
- Improve scripts/make_fit.py to generate a FIT image with separate
base DTB and overlays
- Improve choice value calculation in Kconfig
- Fix conditional prompt behavior in choice in Kconfig
- Remove support for the uncommon EMAIL environment variable in Debian
package builds
- Remove support for the uncommon "name <email>" form for the DEBEMAIL
environment variable
- Raise the minimum supported GNU Make version to 4.0
- Remove stale code for the absolute kallsyms
- Move header files commonly used for host programs to scripts/include/
- Introduce the pacman-pkg target to generate a pacman package used in
Arch Linux
- Clean up Kconfig
* tag 'kbuild-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (65 commits)
kbuild: doc: gcc to CC change
kallsyms: change sym_entry::percpu_absolute to bool type
kallsyms: unify seq and start_pos fields of struct sym_entry
kallsyms: add more original symbol type/name in comment lines
kallsyms: use \t instead of a tab in printf()
kallsyms: avoid repeated calculation of array size for markers
kbuild: add script and target to generate pacman package
modpost: use generic macros for hash table implementation
kbuild: move some helper headers from scripts/kconfig/ to scripts/include/
Makefile: add comment to discourage tools/* addition for kernel builds
kbuild: clean up scripts/remove-stale-files
kconfig: recursive checks drop file/lineno
kbuild: rpm-pkg: introduce a simple changelog section for kernel.spec
kallsyms: get rid of code for absolute kallsyms
kbuild: Create INSTALL_PATH directory if it does not exist
kbuild: Abort make on install failures
kconfig: remove 'e1' and 'e2' macros from expression deduplication
kconfig: remove SYMBOL_CHOICEVAL flag
kconfig: add const qualifiers to several function arguments
kconfig: call expr_eliminate_yn() at least once in expr_eliminate_dups()
...
pacman is the package manager used by Arch Linux and its derivates.
Creating native packages from the kernel tree has multiple advantages:
* The package triggers the correct hooks for initramfs generation and
bootloader configuration
* Uninstallation is complete and also invokes the relevant hooks
* New UAPI headers can be installed without any manual bookkeeping
The PKGBUILD file is a modified version of the one used for the
downstream Arch Linux "linux" package.
Extra steps that should not be necessary for a development kernel have
been removed and an UAPI header package has been added.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Fix the following rpmbuild warning:
$ make srcrpm-pkg
...
RPM build warnings:
source_date_epoch_from_changelog set but %changelog is missing
Signed-off-by: Rafael Aquini <aquini@redhat.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
${DEBFULLNAME-${user}} falls back to ${user} when DEBFULLNAME is unset.
It is more reasonable to do so when DEBFULLNAME is unset or null.
Otherwise, the command:
$ DEBFULLNAME= make deb-pkg
will leave the name field blank.
The same applies to KBUILD_BUILD_USER and KBUILD_BUILD_HOST.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Set -e to make these scripts fail on the first error.
Set -u because these scripts are invoked by Makefile, and do not work
properly without necessary variables defined.
I tweaked mkdebian to cope with optional environment variables.
Remove the explicit "test -n ..." from install-extmod-build.
Both options are described in POSIX. [1]
[1]: https://pubs.opengroup.org/onlinepubs/009604499/utilities/set.html
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Commit d5940c60e0 ("kbuild: deb-pkg improve maintainer address
generation") supported the "name <email>" form for DEBEMAIL, with
behavior slightly different from devscripts.
In Kbuild, if DEBEMAIL is given in the form "name <email>", it is used
as-is, and DEBFULLNAME is ignored.
In contrast, debchange takes the name from DEBFULLNAME (or NAME) if set,
as described in 'man debchange':
If this variable has the form "name <email>", then the maintainer name
will also be taken from here if neither DEBFULLNAME nor NAME is set.
This commit removes support for the "name <email> form for DEBEMAIL,
as the current behavior is already different from debchange, and the
Debian manual suggests setting the email address and name separately in
DEBEMAIL and DEBFULLNAME. [1]
If there are any complaints about this removal, we can re-add it,
with better alignment with the debchange implementation. [2]
[1]: https://www.debian.org/doc/manuals/debmake-doc/ch03.en.html#email-setup
[2]: https://salsa.debian.org/debian/devscripts/-/blob/v2.23.7/scripts/debchange.pl#L802
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Commit edec611db0 ("kbuild, deb-pkg: improve maintainer
identification") added the EMAIL and NAME environment variables.
Commit d5940c60e0 ("kbuild: deb-pkg improve maintainer address
generation") removed support for NAME, but kept support for EMAIL.
The EMAIL and NAME environment variables are supported by some tools
(see 'man debchange'), but not by all.
We should support both of them, or neither of them. We should not stop
halfway.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Fix the following rpmbuild warning:
$ make srcrpm-pkg
...
RPM build warnings:
line 34: It's not recommended to have unversioned Obsoletes: Obsoletes: kernel-headers
Signed-off-by: Rafael Aquini <aquini@redhat.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
At first, I thought this script would be needed only in init/Makefile.
However, commit 5db8face97 ("kbuild: Restore .version auto-increment
behaviour for Debian packages") and commit 1789fc9125 ("kbuild:
rpm-pkg: invoke the kernel build from rpmbuild for binrpm-pkg")
revealed that it was actually needed for scripts/package/mk* as well.
After all, scripts/ is a better place for it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
After 8d1001f7bd (kbuild: rpm-pkg: fix build error with CONFIG_MODULES=n),
the following warning "warning: File listed twice: *.dtb" is appearing for
every dtb file that is included.
The reason is that the commented commit already adds the folder
/lib/modules/%{KERNELRELEASE} in kernel.list file so the folder
/lib/modules/%{KERNELRELEASE}/dtb is no longer necessary, just remove it.
Fixes: 8d1001f7bd ("kbuild: rpm-pkg: fix build error with CONFIG_MODULES=n")
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
When CONFIG_MODULES is disabled, 'make (bin)rpm-pkg' fails:
$ make allnoconfig binrpm-pkg
[ snip ]
error: File not found: .../linux/rpmbuild/BUILDROOT/kernel-6.10.0_rc3-1.i386/lib/modules/6.10.0-rc3/kernel
error: File not found: .../linux/rpmbuild/BUILDROOT/kernel-6.10.0_rc3-1.i386/lib/modules/6.10.0-rc3/modules.order
To make it work irrespective of CONFIG_MODULES, this commit specifies
the directory path, /lib/modules/%{KERNELRELEASE}, instead of individual
files.
However, doing so would cause new warnings:
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.alias
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.alias.bin
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.builtin.alias.bin
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.builtin.bin
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.dep
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.dep.bin
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.devname
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.softdep
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.symbols
warning: File listed twice: /lib/modules/6.10.0-rc3-dirty/modules.symbols.bin
These files exist in /lib/modules/%{KERNELRELEASE} and are also explicitly
marked as %ghost.
Suppress depmod because depmod-generated files are not packaged.
Fixes: 615b3a3d2d ("kbuild: rpm-pkg: do not include depmod-generated files")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Use the KBUILD_IMAGE variable to determine the right kernel image to
install and install compressed images to /boot/vmlinuz-$version like the
'make install' target already does.
Signed-off-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Given KBUILD_IMAGE properly set in arch/*/Makefile, the default case
should work in most scenarios. The only oddity is the naming of the
copy destination, vmlinux-kbuild-${KERNELRELEASE}. Let's rename it
to vmlinuz-${KERNELRELEASE} because the kernel is often compressed.
Remove the warning to avoid unnecessary patch submissions when the
default case suffices.
Remove the x86 case, which is now equivalent to the default.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
scripts/package/buildtar checks some kernel packages, and copies the
first image found. This may potentially produce an inconsistent (and
possibly wrong) package.
For instance, the for-loop for arm64 checks Image.{bz2,gz,lz4,lzma,lzo},
and vmlinuz.efi, then copies the first image found, which might be a
stale image created in a previous build.
When CONFIG_EFI_ZBOOT is enabled in the pristine source tree,
'make ARCH=arm64 tar-pkg' will build and copy vmlinuz.efi. This is the
expected behavior.
If you build the kernel with CONFIG_EFI_ZBOOT disabled, Image.gz will
be created, which will remain in the tree until you run 'make clean'.
Even if CONFIG_EFI_ZBOOT is turned on later, 'make ARCH=arm64 tar-pkg'
will copy stale Image.gz instead of the latest vmlinuz.efi, as Image.gz
takes precedence over vmlinuz.efi.
In summary, the code "[ -f ... ] && cp" does not consistently produce
the desired outcome.
Other packaging targets are deterministic; deb-pkg and rpm-pkg copies
${KBUILD_IMAGE}, which is determined by CONFIG options.
I removed [ -f ... ] checks from x86, alpha, parisc, and the default
because they have a single kernel image to copy. If it is missing, it
should be an error.
I did not modify the code for mips, arm64, riscv. Instead, I left some
comments. Eventually, someone may fix the code, or at the very least,
it may discourage the copy-pasting of incorrect code to another
architecture.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Some architectures, like aarch64 ones, need a dtb file to configure the
hardware. The default dtb file can be preloaded from u-boot, but the final
and/or more complete dtb file needs to be able to be loaded later from
rootfs.
Add the possible dtb files to the kernel rpm and mimic Fedora shipping
process, storing the dtb files in the module directory. These dtb files
will be copied to /boot directory by the install scripts, but add fallback
just in case, checking if the content in /boot directory is correct.
Mark the files installed to /boot as %ghost to make sure they will be
removed when the package is uninstalled.
Tested with Fedora Rawhide (x86_64 and aarch64) with dnf and rpm tools.
In addition, fallback was also tested after modifying the install scripts.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This reverts commit 6ef41e22a3.
If this is still needed, we can bring it back.
However, I'd like to understand why 'new-kernel-pkg --remove' is
needed for uninstallation, while 'new-kernel-pkg --install' was not
called during the installation.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
This reverts commit 27c3bffd23.
If this is still needed, we can bring it back.
However, I'd like to understand why 'update-bootloader --remove' is
needed for uninstallation, while 'update-bootloader --add' was not
called during the installation.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
