17 Apr, 2019
1 commit
-
[ Upstream commit 02826a6ba301b72461c3706e1cc66d5571cd327e ]
Ard Biesheuvel reports bindeb-pkg with O= option is broken in the
following way:...
LD [M] sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko
LD [M] sound/soc/rockchip/snd-soc-rockchip-pcm.ko
LD [M] sound/soc/rockchip/snd-soc-rockchip-rt5645.ko
LD [M] sound/soc/rockchip/snd-soc-rockchip-spdif.ko
LD [M] sound/soc/sh/rcar/snd-soc-rcar.ko
fakeroot -u debian/rules binary
make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg
/bin/bash /home/ard/linux/scripts/package/builddeb
Makefile:600: include/config/auto.conf: No such file or directory
***
*** Configuration file ".config" not found!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
***
make[12]: *** [syncconfig] Error 1
make[11]: *** [syncconfig] Error 2
make[10]: *** [include/config/auto.conf] Error 2
make[9]: *** [__sub-make] Error 2
...Prior to commit 80463f1b7bf9 ("kbuild: add --include-dir flag only
for out-of-tree build"), both srctree and objtree were added to
--include-dir redundantly, and the wrong code '$MAKE image_name'
was working by relying on that. Now, the potential issue that had
previously been hidden just showed up.'$MAKE image_name' recurses to the generated $(objtree)/Makefile and
ends up with running in srctree, which is incorrect. It should be
invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
in objtree.Fixes: 80463f1b7bf9 ("kbuild: add --include-dir flag only for out-of-tree build")
Reported-by: Ard Biesheuvel
Signed-off-by: Masahiro Yamada
Tested-by: Ard Biesheuvel
Signed-off-by: Sasha Levin
27 Nov, 2018
1 commit
-
[ Upstream commit bbcde0a7241261cd0ca8d8e6b94a4113a4b71443 ]
Since commit b41d920acff8 ("kbuild: deb-pkg: split generating packaging
and build"), the build version of the kernel contained in a deb package
is too low by 1.Prior to the bad commit, the kernel was built first, then the number
in .version file was read out, and written into the debian control file.Now, the debian control file is created before the kernel is actually
compiled, which is causing the version number mismatch.Let the mkdebian script pass KBUILD_BUILD_VERSION=${revision} to require
the build system to use the specified version number.Fixes: b41d920acff8 ("kbuild: deb-pkg: split generating packaging and build")
Reported-by: Doug Smythies
Signed-off-by: Masahiro Yamada
Tested-by: Doug Smythies
Signed-off-by: Sasha Levin
28 Jul, 2018
12 commits
-
Different generations of the SH architecture are not very compatible,
so there are/were separate Debian ports for SH3 and SH4.Move the fallback out of the "case" statement, so that it will also be
used in case we find some SH architecture version without a known
mapping.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
Debian currently only defines "riscv64", but it seems safe to assume
that any 32-bit port will now be called "riscv32", also matching
$UTS_MACHINE.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
We currently label 64-bit kernel packages as sparc (32-bit), mostly
because it was officially supported while sparc64 was not. Now
neither is officially supported, so label these packages as sparc64.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
MIPS R6 is not fully backward-compatible, so Debian has separate
architecture names for userland built for R6. Label kernel
packages accordingly.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
We currently label 64-bit little-endian kernel packages as
mipsel (32-bit little-endian), mostly it was officially supported
while mips64el (64-bit little-endian) was not. Now both are
officially supported, so label these packages as mips64el.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
We currently label 64-bit big-endian kernel packages as
powerpc (32-bit), mostly because it was officially supported while
ppc64 (64-bit big-endian) was not. Now neither is officially
supported, so label these packages as ppc64.Debian also has a powerpcspe (32-bit with SPE) architecture.
Label packages with a suitable configuration as powerpcspe.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
We now have many repetitive greps over the kernel config. Refactor
them into functions.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
s390 now only supports 64-bit configurations.
Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
We currently use dpkg --print-architecture, which reports the
architecture of the build machine. We can make a better guess
than this by asking dpkg-architecture what the host architecture,
i.e. the default architecture for building packages, is. This is
sensitive to environment variables such as CC and DEB_HOST_ARCH,
which should already be set in a cross-build environment.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada -
If KBUILD_DEBARCH is set then we will not use the result of
architecture detection, and we may also warn unnecessarily.
Move the check for KBUILD_DEBARCH further up to avoid this.Signed-off-by: Ben Hutchings
Signed-off-by: Masahiro Yamada
19 Jul, 2018
2 commits
-
Make 'make tar-pkg' work on arm64.
Cc: Will Deacon
Cc: Catalin Marinas
Signed-off-by: Olof Johansson
Signed-off-by: Masahiro Yamada -
ARCH=vax isn't in mainline; it can be added back if/when it shows up.
Signed-off-by: Olof Johansson
Signed-off-by: Masahiro Yamada
17 May, 2018
1 commit
-
There is multiple issues with the genaration of maintainer string
It uses DEBEMAIL and EMAIL enviroment variables, which may contain angle brackets,
creating invalid maintainer strings. The documented KBUILD_BUILD_USER and
KBUILD_BUILD_HOST variables are not used. Undocumented and uncommon NAME
variable is used. Refactor the Maintainer string to:- use EMAIL or DEBEMAIL directly if they are in form "name "
- use KBUILD_BUILD_USER and KBUILD_BUILD_HOST if set before falling
back to autodetection
- no longer use NAME variable or the useless Anonymous stringThe logic is switched from multiline if/then/fi statements to compact
shell variable substition commands.Reported-by: Mathieu Malaterre
Signed-off-by: Riku Voipio
Signed-off-by: Masahiro Yamada
13 Apr, 2018
1 commit
-
The new-kernel-pkg script is only present when grubby is installed, but it
may not always be the case. So if the script isn't present, attempt to use
the kernel-install script as a fallback instead.Signed-off-by: Javier Martinez Canillas
Signed-off-by: Masahiro Yamada
07 Apr, 2018
1 commit
-
Move debian/ directory generation out of builddeb to a new script,
mkdebian. The package build commands are kept in builddeb, which
is now an internal command called from debian/rules.With these changes in place, we can now use dpkg-buildpackage from
deb-pkg and bindeb-pkg removing need for handrolled source/changes
generation.This patch is based on the criticism of the current state of builddeb
discussed on:https://patchwork.kernel.org/patch/9656403/
Signed-off-by: Riku Voipio
Signed-off-by: Masahiro Yamada
28 Mar, 2018
2 commits
-
There is a change in how command line parsing is done in this version.
Excludes and includes are now ordered with the file list. Since
the spec file puts the file list before the exclude list it means newer
tar ignores the excludes and packs all the build output into the
kernel-devel RPM resulting in a huge package.Simple argument re-ordering fixes the problem.
Signed-off-by: Jason Gunthorpe
Signed-off-by: Masahiro Yamada -
Since d5d332d3f7e8, a couple of links in scripts/dtc/include-prefixes
are additionally required in order to build device trees with the header
package.Signed-off-by: Jan Kiszka
Reviewed-by: Riku Voipio
Signed-off-by: Masahiro Yamada
12 Dec, 2017
2 commits
-
We do not support out-of-tree building of rpm-pkg / deb-pkg. If O=
is given, the build should be terminated, but the "false" command is
not effective since it is not the last command in the cmd_src_tar.
Then, rpm-pkg / deb-pkg tries to continue building, and fails for a
different reason.Set -e option so that the "false" terminates the building immediately.
I also put the error messages to stderr, and made it stand out more.
For example, "make O=foo rpm-pkg" will fail as follows:
/bin/bash ../scripts/package/mkspec >./kernel.spec
TAR kernel-4.15.0_rc2+.tar.gzERROR:
Building source tarball is not possible outside the
kernel source tree. Don't set KBUILD_OUTPUT, or use the
binrpm-pkg or bindeb-pkg target instead.../scripts/package/Makefile:53: recipe for target 'rpm-pkg' failed
Signed-off-by: Masahiro Yamada
Tested-by: Jim Davis -
Following in footsteps of other targets like 'deb-pkg, 'rpm-pkg' and 'tar-pkg',
this patch adds a 'snap-pkg' target for the creation of a Linux kernel snap
package using the kbuild infrastructure.A snap, in its general form, is a self contained, sandboxed, universal package
and it is intended to work across multiple distributions and/or devices. A snap
package is distributed as a single compressed squashfs filesystem.A kernel snap is a snap package carrying the Linux kernel, kernel modules,
accessory files (DTBs, System.map, etc) and a manifesto file. The purpose of a
kernel snap is to carry the Linux kernel during the creation of a system image,
eg. Ubuntu Core, and its subsequent upgrades.For more information on snap packages: https://snapcraft.io/docs/
Signed-off-by: Paolo Pisati
Signed-off-by: Masahiro Yamada
23 Nov, 2017
2 commits
-
The "rpm" has been kept for backward compatibility since pre-git era.
I am planning to remove it after the Linux 4.18 release. Annouce the
end of the support, prompting to use "rpm-pkg" instead.If you use "rpm", it will work like "rpm-pkg", but warning messages
will be displayed as follows:WARNING: "rpm" target will be removed after Linux 4.18
Please use "rpm-pkg" instead.Signed-off-by: Masahiro Yamada
-
For rpm-pkg and deb-pkg, a source tar file is created. All paths in
the archive must be prefixed with the base name of the tar so that
everything is contained in the directory when you extract it.Currently, scripts/package/Makefile uses a symlink for that, and
removes it after the tar is created.If you terminate the build during the tar creation, the symlink is
left over. Then, at the next package build, you will see a warning
like follows:ln: '.' and 'kernel-4.14.0+/.' are the same file
It is possible to fix it by adding -n (--no-dereference) option to
the "ln" command, but a cleaner way is to use --transform option
of "tar" command. This option is GNU extension, but it should not
hurt to use it in the Linux build system.The 'S' flag is needed to exclude symlinks from the path fixup.
Without it, symlinks in the kernel are broken.Signed-off-by: Masahiro Yamada
18 Nov, 2017
1 commit
-
…asahiroy/linux-kbuild
Pull Kbuild misc updates from Masahiro Yamada:
- Clean up and fix RPM package build
- Fix a warning in DEB package build
- Improve coccicheck script
- Improve some semantic patches
* tag 'kbuild-misc-v4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
docs: dev-tools: coccinelle: delete out of date wiki reference
coccinelle: orplus: reorganize to improve performance
coccinelle: use exists to improve efficiency
builddeb: Pass the kernel:debarch substvar to dpkg-genchanges
Coccinelle: use false positive annotation
coccinelle: fix verbose message about .cocci file being run
coccinelle: grep Options and Requires fields more precisely
Coccinelle: make DEBUG_FILE option more useful
coccinelle: api: detect identical chip data arrays
coccinelle: Improve setup_timer.cocci matching
Coccinelle: setup_timer: improve messages from setup_timer
kbuild: rpm-pkg: do not force -jN in submake
kbuild: rpm-pkg: keep spec file until make mrproper
kbuild: rpm-pkg: fix jobserver unavailable warning
kbuild: rpm-pkg: replace $RPM_BUILD_ROOT with %{buildroot}
kbuild: rpm-pkg: fix build error when CONFIG_MODULES is disabled
kbuild: rpm-pkg: refactor mkspec with here doc
kbuild: rpm-pkg: clean up mkspec
kbuild: rpm-pkg: install vmlinux.bz2 unconditionally
kbuild: rpm-pkg: remove ppc64 specific image handling
14 Nov, 2017
7 commits
-
At the end of "make bindeb-pkg" I noticed the following warning:
dpkg-genchanges: warning: unknown substitution variable ${kernel:debarch}
It turns out that since dpkg version 1.19.0 dpkg-genchanges honors
substitution variables in the Description field, while earlier
versions silently left them alone, see https://bugs.debian.org/856547.The result is an incomplete description of the linux-headers package
in the generated .changes file. Fix it by passing the kernel:debarch
substitution variable to dpkg-genchanges.Signed-off-by: Sven Joachim
Signed-off-by: Masahiro Yamada -
The spec file always passes %{?_smp_mflags}, but we have two
problems here.[1] "make -jN rpm-pkg" emits the following warning message:
make[2]: warning: -jN forced in submake: disabling jobserver mode.
[2] We can not specify the number of jobs that run in parallel.
Whether we give -jN or not from the top Makefile, the spec file
always passes ${?_smp_mflags} to the build commands.${?_smp_mflags} will be useful when we run rpmbuild by hand. When we
invoke it from Makefile, -jN is propagated down to submake; it should
not be overridden because we want to respect the number of jobs given
by the user. Set _smp_mflags to empty string in this case.Signed-off-by: Masahiro Yamada
-
If build fails during (bin)rpm-pkg, the spec file is not cleaned by
anyone until the next successful build of the package.We do not have to immediately delete the spec file in case somebody
may want to take a look at it. Instead, make them ignored by git,
and cleaned up by make mrproper.Signed-off-by: Masahiro Yamada
-
If "make rpm-pkg" or "make binrpm-pkg" is run with -j[jobs] option,
the following warning message is displayed.warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
Follow the suggestion.
Signed-off-by: Masahiro Yamada
-
$RPM_BUILD_ROOT must be escaped to prevent shell from expanding it
when generating the spec file.%{build_root} is more readable than \$RPM_BUILD_ROOT.
Signed-off-by: Masahiro Yamada
-
When CONFIG_MODULES is disabled, make rpm-pkg / binrpm-pkg fails
with the following message:The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.Do not install modules in the case. Also, omit the devel package.
Signed-off-by: Masahiro Yamada
-
The repeat of echo is unreadable. The here-document is a well-known
device for such scripts. One difficulty is we have a bunch of PREBUILT
conditionals that would split the here-document.My idea is to add "$S" annotatation to lines only for the source package
spec file, then post-process it by sed. I hope it will make our life
easier than repeat of "cat <
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
09 Oct, 2017
3 commits
-
Clean up the mkspec without changing the behavior.
- grep CONFIG_DRM=y more simply
- move "EXCLUDE" out of the "%install" section because it can be
computed when the spec file is generated- remove "BuildRoot:" field, which is now redundant
- do not mkdir $RPM_BUILD_ROOT/lib/modules explicitly because it
is automatically created by "make modules_install"- exclude "%package devel" from source package spec file because
it does not make sense where "%files devel" is already excluded- exclude "%build" from source package spec file
- remove unneeded "make clean" because we had already cleaned
before making tar file- merge two %ifarch ia64 conditionals
- replace KBUILD_IMAGE with direct use of $(make image_name)
- remove trailing empty line from the spec file
Signed-off-by: Masahiro Yamada
-
This conditional was added by commit fc370ecfdb37 ("kbuild: add
vmlinux to kernel rpm"). Its git-log mentioned vmlinux.bz2 was
necessary for debugging, but did not explain why ppc64 was an
exception. I see no problem to copy vmlinux.bz2 all the time.Signed-off-by: Masahiro Yamada
-
This conditional was added by commit 1a0f3d422bb9 ("kbuild: fix
make rpm for powerpc"). Its git-log explains the default kernel
image is zImage, but obviously the current arch/powerpc/Makefile
does not set KBUILD_IMAGE, so the image file is actually vmlinux.Moreover, since commit 09549aa1baa9 ("deb-pkg: Remove the KBUILD_IMAGE
workaround"), all architectures are supposed to set the full path to
the image in KBUILD_IMAGE. I see no good reason to differentiate
ppc64 from others. Rip off the conditional.Signed-off-by: Masahiro Yamada
20 Sep, 2017
3 commits
-
The "Release:" field of the spec file is determined based on the
.version file.However, the .version file is not copied to the source tar file.
So, when we build the kernel from the source package, the UTS_VERSION
always indicates #1. This does not match with "rpm -q".The kernel UTS_VERSION and "rpm -q" do not agree for binrpm-pkg, either.
Please note the kernel has already been built before the spec file is
created. Currently, mkspec invokes mkversion. This script returns an
incremented version. So, the "Release:" field of the spec file is
greater than the version in the kernel by one.For the source package build (where .version file is missing), we can
give KBUILD_BUILD_VERSION=%{release} to the build command.For the binary package build, we can simply read out the .version file
because it contains the version number that was used for building the
kernel image.We can remove scripts/mkversion because scripts/package/Makefile need
not touch the .version file.Signed-off-by: Masahiro Yamada
-
Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including the firmware install command.So, the firmware package does not make sense any more. Remove it.
Signed-off-by: Masahiro Yamada
Reviewed-by: Riku Voipio
Acked-by: Greg Kroah-Hartman -
Commit 5620a0d1aacd ("firmware: delete in-kernel firmware") deleted
in-kernel firmware support, including "make firmware_install".Since then, "make rpm-pkg" / "make binrpm-pkg" fails to build with
the error:make[2]: *** No rule to make target `firmware_install'. Stop.
Commit df85b2d767aa ("firmware: Restore support for built-in firmware")
restored the build infrastructure for CONFIG_EXTRA_FIRMWARE, but this
is out of the scope of "make firmware_install". So, the right thing to
do is to kill the use of "make firmware_install".Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware")
Signed-off-by: Masahiro Yamada
Acked-by: Greg Kroah-Hartman