All kernels depend on the latest kernel

  • Open
  • quality assurance status badge
Details
3 participants
  • Dariqq
  • Maxim Cournoyer
  • Wilko Meyer
Owner
unassigned
Submitted by
Dariqq
Severity
normal
D
D
Dariqq wrote on 14 Jul 23:07 +0200
(address . bug-guix@gnu.org)
f85650b1-3e1c-418e-85d5-450810b41aba@posteo.net
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
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:

Thanks.
W
W
Wilko Meyer wrote on 15 Jul 17:43 +0200
(address . 72119@debbugs.gnu.org)
874j8qacep.fsf@wmeyer.eu
Hi Dariqq,

Toggle quote (5 lines)
> 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:

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
D
D
Dariqq wrote on 15 Jul 19:24 +0200
(name . Wilko Meyer)(address . w@wmeyer.eu)
7e4afd90-73c1-4794-9a23-d78672bf63a4@posteo.net
Hi Wilko,

On 15.07.24 17:43, Wilko Meyer wrote:
Toggle quote (11 lines)
> 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:

Toggle quote (5 lines)
> 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.

Toggle quote (6 lines)
> 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
M
M
Maxim Cournoyer wrote on 11 Oct 04:27 +0200
Re: bug#72119: All kernels depend on the latest kernel
(name . Dariqq)(address . dariqq@posteo.net)
87frp374sp.fsf@gmail.com
Hi,

Dariqq <dariqq@posteo.net> writes:

Toggle quote (40 lines)
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 72119@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72119
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch