* bug#72119: All kernels depend on the latest kernel
@ 2024-07-14 21:07 Dariqq
2024-07-15 15:43 ` Wilko Meyer
0 siblings, 1 reply; 4+ messages in thread
From: Dariqq @ 2024-07-14 21:07 UTC (permalink / raw)
To: 72119
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#72119: All kernels depend on the latest kernel
2024-07-14 21:07 bug#72119: All kernels depend on the latest kernel Dariqq
@ 2024-07-15 15:43 ` Wilko Meyer
2024-07-15 17:24 ` Dariqq
0 siblings, 1 reply; 4+ messages in thread
From: Wilko Meyer @ 2024-07-15 15:43 UTC (permalink / raw)
To: 72119; +Cc: Dariqq, Leo Famulari
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#72119: All kernels depend on the latest kernel
2024-07-15 15:43 ` Wilko Meyer
@ 2024-07-15 17:24 ` Dariqq
2024-10-11 2:27 ` Maxim Cournoyer
0 siblings, 1 reply; 4+ messages in thread
From: Dariqq @ 2024-07-15 17:24 UTC (permalink / raw)
To: Wilko Meyer; +Cc: 72119, Leo Famulari
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#72119: All kernels depend on the latest kernel
2024-07-15 17:24 ` Dariqq
@ 2024-10-11 2:27 ` Maxim Cournoyer
0 siblings, 0 replies; 4+ messages in thread
From: Maxim Cournoyer @ 2024-10-11 2:27 UTC (permalink / raw)
To: Dariqq; +Cc: Wilko Meyer, Leo Famulari, 72119
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-10-11 2:45 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-14 21:07 bug#72119: All kernels depend on the latest kernel Dariqq
2024-07-15 15:43 ` Wilko Meyer
2024-07-15 17:24 ` Dariqq
2024-10-11 2:27 ` Maxim Cournoyer
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).