Hi, Dariqq <dar...@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
