bug#72119: All kernels depend on the latest kernel

bug#72119: All kernels depend on the latest kernel

[Dariqq]

Hi Guix,

Since commit b72b6063cebbcfd64d43f5b05ba8470eb11c3f65 added dwarfes and 
bpf support to our kernel an update to the latest kernel causes a 
rebuild of all kernels.

The reason is

linux-libre-*->dwarfes->libbpf->linux-libre-headers-6.9

as (dependants of) libbpf need newer kernel headers than the default 
ones (5.15.49).

As an example for this you can look at a recent kernel updates job on ci
https://ci.guix.gnu.org/eval/1480123 :
All kernels are being rebuilt despite only the 6.* ones being updated.


This problem will probably only increase in the future as newer versions 
of packages might also require newer headers.

I also encountered this recently when i tried to (unsuccessfully) update 
mutter to 46 where the build would fail as some file utilizes 
DMA_BUF_IOCTL_EXPORT_SYNC_FILE  which (i think) was only added with the 
6.0 kernel headers. Once that is properly packaged in guix using any of 
the "rolling" headers for mutter would then also cause weekly gnome 
rebuilds, etc.

 From the comments in the libbpf package it seems anything >= 6 should 
be enough for that package as well.

As a solution I would propose either
- updating the default 5.14.49 header (there is a big warning next to it 
so probably not a good idea)
- or create a second stable, recent enough header to use for such cases.

This would also reduce maintenance burden of constantly updating these 
inputs when the kernel and thus its headers are removed from guix due to 
becoming eol.
This already caused a problem once when the 6.8 kernel was removed:
https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00181.html

Thanks.

bug#72119: All kernels depend on the latest kernel

[Wilko Meyer]

Hi Dariqq,

> As a solution I would propose either
> - updating the default 5.14.49 header (there is a big warning next to it 
> so probably not a good idea)
> - or create a second stable, recent enough header to use for such cases.

I'm still in favor of the second solution, as previously discussed here:
https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00182.html.

However, I think linux-libre-headers should refer to the latest
header, and for bootstrapping purpose there *should* be a
linux-libre-headers-bootstrap variable or something like that.

I'm not too knowledgable on the entire bootstrapping process, but if I
see that correctly, the headers are only used in
linux-libre-headers-boot0 of commencement.scm? That could be changed,
even though I'm not sure what that implies in terms of rebuilds.

-- 
Kind regards,

Wilko Meyer
w@wmeyer.eu

bug#72119: All kernels depend on the latest kernel

[Dariqq]

Hi Wilko,

On 15.07.24 17:43, Wilko Meyer wrote:
> Hi Dariqq,
> 
>> As a solution I would propose either
>> - updating the default 5.14.49 header (there is a big warning next to it
>> so probably not a good idea)
>> - or create a second stable, recent enough header to use for such cases.
> 
> I'm still in favor of the second solution, as previously discussed here:
> https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00182.html.
> 

Just creating a second newer header package would be relatively easy to 
implement without much rebuilds. (basically only all kernels which are 
already being rebuild weekly).

The more general problem is a bit more tricky though:

> However, I think linux-libre-headers should refer to the latest
> header, and for bootstrapping purpose there *should* be a
> linux-libre-headers-bootstrap variable or something like that.
> 

I agree that it is a bit confusing that there is an unversioned 
linux-libre for the the latest kernel but the unversioned header is some 
arbitrary version.

> I'm not too knowledgable on the entire bootstrapping process, but if I
> see that correctly, the headers are only used in
> linux-libre-headers-boot0 of commencement.scm? That could be changed,
> even though I'm not sure what that implies in terms of rebuilds.
> 

The main part (i can see) where linux-libre-headers are used apart from 
the bootstrapping process is being propagated from glibc and therefore 
being included into *every* build environment (apart from hurd). So in 
terms of rebuilds basically everything.

Have a nice day,
Dariqq

bug#72119: All kernels depend on the latest kernel

[Maxim Cournoyer]

Hi,

Dariqq <dariqq@posteo.net> writes:

> Hi Wilko,
>
> On 15.07.24 17:43, Wilko Meyer wrote:
>> Hi Dariqq,
>> 
>>> As a solution I would propose either
>>> - updating the default 5.14.49 header (there is a big warning next to it
>>> so probably not a good idea)
>>> - or create a second stable, recent enough header to use for such cases.
>> I'm still in favor of the second solution, as previously discussed
>> here:
>> https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00182.html.
>> 
>
> Just creating a second newer header package would be relatively easy
> to implement without much rebuilds. (basically only all kernels which
> are already being rebuild weekly).
>
> The more general problem is a bit more tricky though:
>
>> However, I think linux-libre-headers should refer to the latest
>> header, and for bootstrapping purpose there *should* be a
>> linux-libre-headers-bootstrap variable or something like that.
>> 
>
> I agree that it is a bit confusing that there is an unversioned
> linux-libre for the the latest kernel but the unversioned header is
> some arbitrary version.
>
>> I'm not too knowledgable on the entire bootstrapping process, but if I
>> see that correctly, the headers are only used in
>> linux-libre-headers-boot0 of commencement.scm? That could be changed,
>> even though I'm not sure what that implies in terms of rebuilds.
>> 
>
> The main part (i can see) where linux-libre-headers are used apart
> from the bootstrapping process is being propagated from glibc and
> therefore being included into *every* build environment (apart from
> hurd). So in terms of rebuilds basically everything.

I think that's a correct assessment.  Can be done on a dedicated branch
on ci.guix.gnu.org.  Wilko, if you need admin access to the Cuirass web
interface to set that up, I can provide you with the needed TLS
certificates.

-- 
Thanks,
Maxim