user/sven/linux.git/scripts/Makefile.package, branch v6.6.14

kbuild: deb-pkg: support DEB_BUILD_OPTIONS=parallel=N in debian/rules

2023-08-29T13:29:35Z

'make srcdeb-pkg' generates a source package, which you can build later by using dpkg-buildpackage. In older dpkg versions, 'dpkg-buildpackage --jobs=N' sets not only DEB_BUILD_OPTIONS but also MAKEFLAGS. Hence, passing -j or --jobs to dpkg-buildpackage was enough for kicking the parallel execution. The behavior was changed by commit 1d0ea9b2ba3f ("dpkg-buildpackage: Change -j, --jobs semantics to non-force mode") of dpkg project. [1] Since then, 'dpkg-buildpackage --jobs=N' sets only DEB_BUILD_OPTIONS, which is not parsed by the current debian/rules. To build the package in parallel, you need to pass the alternative --jobs-force option or set the MAKEFLAGS environment variable. Debian policy [2] suggests the following code snippet for debian/rules. ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) endif I tweaked the code to filter out parallel=1 and passed --jobs=1 to dpkg-buildpackage from scripts/Makefile.package. It is needed to force 'make deb-pkg' without the -j option to run in serial. Please note that dpkg-buildpackage sets parallel= in DEB_BUILD_OPTIONS by default (that is, --jobs=auto is the default) and --jobs=1 is needed to restore the serial execution. When dpkg-buildpackage is invoked from Kbuild, the number of jobs is inherited from the top level Makefile. Passing --jobs=1 to dpkg-buildpackage allows debian/rules to skip parsing DEB_BUILD_OPTIONS. [1] https://salsa.debian.org/dpkg-team/dpkg/-/commit/1d0ea9b2ba3f6a2de5b1a6ff55f3df7b71f73db6 [2] https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options Reported-by: Bastian Germann Signed-off-by: Masahiro Yamada

kbuild: deb-pkg: use Debian compliant shebang for debian/rules

2023-08-07T16:08:54Z

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: Masahiro Yamada Tested-by: Nathan Chancellor Reviewed-by: Nicolas Schier

kbuild: rpm-pkg: skip build dependency check on non-rpm systems

2023-07-24T15:59:33Z

Commit 8818039f959b ("kbuild: add ability to make source rpm buildable using koji") added the BuildRequires: field. Checking the build dependency is fine, but one annoyance is that 'make (bin)rpm-pkg' fails on non-rpm systems [1]. For example, Debian provides rpmbuild via 'apt install rpm', but of course cannot meet the requirement listed in the BuildRequires: field. It is possible to pass RPMOPTS=--nodeps to work around it, but it is reasonable to do it automatically. If 'rpm -q rpm' fails, it is not an RPM-managed system. (The command 'rpm' is not installed at all, or was installed by other means.) In that case, pass --nodeps to skip the build dependency check. [1]: https://lore.kernel.org/linux-kbuild/Y6mkdYQYmjUz7bqV@li-4a3a4a4c-28e5-11b2-a85c-a8d192c6f089.ibm.com/ Signed-off-by: Masahiro Yamada

kbuild: rpm-pkg: refactor *rpm-pkg targets

2023-07-24T15:59:33Z

Merge the similar build targets. Also, make the output location consistent. Previously, source packages were created in the build directory, while binary packages under ~/rpmbuild/RPMS/. Now, Kbuild creates the rpmbuild/ directory in the build directory, and saves all packages under it. Signed-off-by: Masahiro Yamada

kbuild: rpm-pkg: build the kernel in-place for rpm-pkg

2023-07-24T15:59:33Z

Currently, 'make rpm-pkg' always builds the kernel from the pristine source tree in the ~/rpmbuild/BUILD/ directory. Build the kernel incrementally just like 'make binrpm-pkg'. Signed-off-by: Masahiro Yamada

kbuild: rpm-pkg: rename binkernel.spec to kernel.spec

2023-07-24T15:59:33Z

Now kernel.spec and binkernel.spec have the exactly same contents. Use kernel.spec for binrpm-pkg as well. Signed-off-by: Masahiro Yamada

kbuild: rpm-pkg: introduce %{with_devel} switch to select devel package

2023-07-24T15:59:33Z

scripts/package/mkspec preprocesses the spec file by sed, but it is unreadable. This commit removes the last portion of the sed scripting. Remove the $S$M prefixes from the conditionally generated lines. Instead, surround the code with %if %{with_devel} ... %endif. Signed-off-by: Masahiro Yamada

kbuild: rpm-pkg: invoke the kernel build from rpmbuild for binrpm-pkg

2023-07-24T15:59:33Z

To reduce the preprocess of the spec file, invoke the kernel build from rpmbuild. Run init/build-version to increment the release number not only for binrpm-pkg but also for srcrpm-pkg and rpm-pkg. Signed-off-by: Masahiro Yamada

kbuild: add a phony target to run a command with Kbuild env vars

2023-07-24T15:59:32Z

There are some cases where we want to run a command with the same environment variables as Kbuild uses. For example, 'make coccicheck' invokes scripts/coccicheck from the top Makefile so that the script can reference to ${LINUXINCLUDE}, ${KBUILD_EXTMOD}, etc. The top Makefile defines several phony targets that run a script. We do it also for an internally used script, which results in a somewhat complex call graph. One example: debian/rules binary-arch -> make intdeb-pkg -> scripts/package/builddeb It is also tedious to add a dedicated target like 'intdeb-pkg' for each use case. Add a generic target 'run-command' to run an arbitrary command in an environment with all Kbuild variables set. The usage is: $ make run-command KBUILD_RUN_COMMAND= The concept is similar to: $ dpkg-architecture -c This executes in an environment which has all DEB_* variables defined. Convert the existing 'make intdeb-pkg'. Another possible usage is to interrogate a Make variable. $ make run-command KBUILD_RUN_COMMAND='echo $(KBUILD_CFLAGS)' might be useful to see KBUILD_CFLAGS set by the top Makefile. Signed-off-by: Masahiro Yamada

kbuild: rpm-pkg: do not hard-code $MAKE in spec file

2023-07-24T15:59:32Z

Currently, $MAKE will expand to the GNU Make program that created the source RPM. This is problematic if you carry it to a different build host to run 'rpmbuild' there. Consider this command: $ /path/to/my/custom/make srcrpm-pkg The spec file in the SRPM will record '/path/to/my/custom/make', which exists only on that build environment. To create a portable SRPM, the spec file should avoid hard-coding $MAKE. Signed-off-by: Masahiro Yamada