GNU bug report logs -
#72119
All kernels depend on the latest kernel
Previous Next
To reply to this bug, email your comments to 72119 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#72119
; Package
guix
.
(Sun, 14 Jul 2024 21:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dariqq <dariqq <at> posteo.net>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Sun, 14 Jul 2024 21:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#72119
; Package
guix
.
(Mon, 15 Jul 2024 15:44:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 72119 <at> debbugs.gnu.org (full text, mbox):
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 <at> wmeyer.eu
Information forwarded
to
bug-guix <at> gnu.org
:
bug#72119
; Package
guix
.
(Mon, 15 Jul 2024 17:25:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 72119 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 54 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.