| Message ID | 20210127212413.2046623-1-yann.morin.1998@free.fr |
|---|---|
| State | Accepted |
| Headers | show |
| Series | package/linux-headers: with headers from kernel, also override srcdir | expand |
On 27/01/2021 22:24, Yann E. MORIN wrote: > 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). It's likely that some people that are currently using this configuration will have explicitly set LINUX_HEADERS_OVERRIDE_SRCDIR as well to overcome this problem, so this error will cause a regression for them. That said, it's easy enough to fix and the error message is clear, so I guess it's OK. Applied to master, thanks. Regards, Arnout PS: No spelling errors, congratulations! :-) > > 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> > --- > package/linux-headers/linux-headers.mk | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk > index 807e574f4d..a8d1c2ccaf 100644 > --- a/package/linux-headers/linux-headers.mk > +++ b/package/linux-headers/linux-headers.mk > @@ -18,6 +18,10 @@ LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION)) > LINUX_HEADERS_CUSTOM_TARBALL_LOCATION = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION)) > LINUX_HEADERS_REPO_URL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL)) > LINUX_HEADERS_CIP = $(BR2_LINUX_KERNEL_LATEST_CIP_VERSION)$(BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION) > +ifneq ($(LINUX_HEADERS_OVERRIDE_SRCDIR),) > +$(error LINUX_HEADERS_OVERRIDE_SRCDIR must not be set when BR2_KERNEL_HEADERS_AS_KERNEL=y) > +endif > +LINUX_HEADERS_OVERRIDE_SRCDIR = $(LINUX_OVERRIDE_SRCDIR) > else # ! BR2_KERNEL_HEADERS_AS_KERNEL > LINUX_HEADERS_CUSTOM_TARBALL = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL)) > LINUX_HEADERS_CUSTOM_GIT = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_GIT)) >
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes: > On 27/01/2021 22:24, Yann E. MORIN wrote: >> 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). Committed to 2020.02.x and 2020.11.x, thanks.
diff --git a/package/linux-headers/linux-headers.mk b/package/linux-headers/linux-headers.mk index 807e574f4d..a8d1c2ccaf 100644 --- a/package/linux-headers/linux-headers.mk +++ b/package/linux-headers/linux-headers.mk @@ -18,6 +18,10 @@ LINUX_HEADERS_VERSION = $(call qstrip,$(BR2_LINUX_KERNEL_VERSION)) LINUX_HEADERS_CUSTOM_TARBALL_LOCATION = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION)) LINUX_HEADERS_REPO_URL = $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_REPO_URL)) LINUX_HEADERS_CIP = $(BR2_LINUX_KERNEL_LATEST_CIP_VERSION)$(BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION) +ifneq ($(LINUX_HEADERS_OVERRIDE_SRCDIR),) +$(error LINUX_HEADERS_OVERRIDE_SRCDIR must not be set when BR2_KERNEL_HEADERS_AS_KERNEL=y) +endif +LINUX_HEADERS_OVERRIDE_SRCDIR = $(LINUX_OVERRIDE_SRCDIR) else # ! BR2_KERNEL_HEADERS_AS_KERNEL LINUX_HEADERS_CUSTOM_TARBALL = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_TARBALL)) LINUX_HEADERS_CUSTOM_GIT = $(call qstrip,$(BR2_KERNEL_HEADERS_CUSTOM_GIT))
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> --- package/linux-headers/linux-headers.mk | 4 ++++ 1 file changed, 4 insertions(+)