When using the headers from the kernel to be built, with the kernel
set to a custom version, and overriding the kernel sources with
LINUX_OVERRIDE_SRCDIR, the linux-headers package is still trying to
download an archive, and fails to validate its hash.
What is going on under the hood is that, with _OVERRIDE_SRCDIR, the
_VERSION of a package is set to 'custom'. Furthermore, the variable
BR_NO_CHECK_HASH_FOR is recursively expanded, so its value is only
evaluated when it is needed.
For linux-headers, we inherit the values from the linux package, and
the LINUX_HEADERS_VERSION takes the value from the configuration.
Thus we end up with the following situation:
LINUX_VERSION=custom
LINUX_HEADERS_VERSION=5.10 # For example
BR_NO_CHECK_HASH_FOR=... linux-custom.tar.gz ...
And thus the archive downloaded by linux-headers will not match any
exclusion, and since there will most probably not be a hash for it,
the download will fail, as was noticed and reported by Jarkko.
But in this case, what we really want is to really use the headers
from the kernel that we build, we do not even want to attempt a
download at all.
So, when using the headers from the kernel to be built, we also
propagate the LINUX_OVERRIDE_SRCDIR to linux-headers, so that we
also use the headers from the overridden sources.
Furthermore, in that configuration, we explicitly disallow
overriding the linux-headers specifically, as it does not make sense
(even though, if they were overridden to the same location, that'd
be OK, but to simplify the condition, we do not even check for that).
Reported-by: Jarkko Sakkinen <jjs@kapsi.fi>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Commit 5b95a5dc2 (support/download: change format of archives generated
from git) changed the way the archives generated from git repositories
are named, adding a "format-version" identifier right between the
package version and the file extension.
Commit c043ecb20 (support/download: change format of archives generated
from svn) did so for archives generated from a subversion checkout.
However, for a few packages, we manually force the _SOURCE variable,
because we want to share the archive with another package, to avoid
downloading and storing those archives twice. This is the case for:
- linux-headers and linux
- barebox-aux and barebox
When the generated tarballs were renamed with the aforementioned
commits, those packages were not updated accordingly.
Fix that by manually propagating the per-site-method format-version.
Reported-by: "Stephane Viau (OSS)" <stephane.viau@oss.nxp.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: "Stephane Viau (OSS)" <stephane.viau@oss.nxp.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Drop 5.9 stable (EOL).
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
[Peter: add Config.in.legacy handling for 5.9]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit c2009e9f75
("package/linux-headers: license files hashes only valid for latest
version"), we introduced BR2_KERNEL_HEADERS_LATEST, which should only
be set for the most recent kernel headers versions.
Indeed, the COPYING file of Linux has changed before/after Linux 5.6,
causing its hash file to be different. Since linux-headers uses
linux/linux.hash as the hash file, and this hash file contains the
COPYING hash of Linux >= 5.6, we cannot use that hash for Linux
versions older than 5.6.
When newer versions of the headers than 5.4 were added, this
BR2_KERNEL_HEADERS_LATEST was not moved as it should have been. We fix
this, which fixes a legal-info failure happening when Linux kernel
headers 5.4 are used:
>>> linux-headers 5.4.63 Patching
>>> linux-headers 5.4.63 Collecting legal info
ERROR: COPYING has wrong sha256 hash:
ERROR: expected: fb5a425bd3b3cd6071a3a9aff9909a859e7c1158d54d32e07658398cd67eb6a0
ERROR: got : ee5808b032a67f587d3541099d46de34f5bec8cd5976114ba07f1299ee6001ff
ERROR: Incomplete download, or man-in-the-middle (MITM) attack
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When the linux-headers are configured to use the same source as the
kernel (BR2_KERNEL_HEADERS_AS_KERNEL), and the kernel is configured
to be one of the two CIP versions (BR2_LINUX_KERNEL_LATEST_CIP_VERSION
or BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION), the build fails if the
kernel sources are not already downloaded:
$ cat defconfig
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_LATEST_CIP_VERSION=y
$ make defconfig BR2_DEFCONFIG=$pwd)/defconfig
$ make linux-headers-source
>>> linux-headers 4.19.118-cip25 Downloading
--2020-05-13 19:28:44-- https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.118-cip25.tar.xz
Resolving cdn.kernel.org (cdn.kernel.org)... 2a04:4e42:1d::432, 151.101.121.176
Connecting to cdn.kernel.org (cdn.kernel.org)|2a04:4e42:1d::432|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-05-13 19:28:45 ERROR 404: Not Found.
make[1]: *** [package/pkg-generic.mk:171: /home/ymorin/dev/buildroot/O/build/linux-headers-4.19.118-cip25/.stamp_downloaded] Error 1
make: *** [Makefile:23: _all] Error 2
We fix that by adding yet another duplication of information out of
the linux.mk, to use the CIP-specific git tree where to get the
archives as snapshots.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Notice: 5.5.x is now EOL, so should be dropped at the next version bump.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
[yann.morin.1998@free.fr:
- bump to 5.5.13
- rebase on top of master
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When Buildroot is released, it knows up to a certain kernel header
version, and no later. However, it is possible that an external
toolchain will be used, that uses headers newer than the latest version
Buildroot knows about.
This may also happen when testing a development, an rc-class, or a newly
released kernel, either in an external toolchain, or with an internal
toolchain with custom headers (same-as-kernel, custom version, custom
git, custom tarball).
In the current state, Buildroot would refuse to use such toolchains,
because the test is for strict equality.
We'd like to make that situation possible, but we also want the user not
to be lenient at the same time, and select the right headers version
when it is known.
So, we add a new Kconfig blind option that the latest kernel headers
version selects. This options is then used to decide whether we do a
strict or loose check of the kernel headers.
Suggested-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
[yann.morin.1998@free.fr:
- only do a loose check for the latest version
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Like we did for the linux kernel, change linux-headers to only check the
license hashes for the latest known version as the content of COPYING has
changed between versions.
To simplify the test, we introduce an intermediate, blind option that get
selected when the latest kernel sources are used.
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
