On 2026-05-01, Ludovic Courtès wrote:
> Vagrant Cascadian <[email protected]> skribis:
>
>> I really wonder if we should ship so many versions concurrently... when
>> most users probably use the default version or default lts version (I am
>> guessing, anyways)... rolling out updates for that many kernel versions
>> at once takes a full calendar day or more to have substitutes available
>> for all versions (and not even all architectures, bordeaux does not
>> usually build until it lands on guix master branch; I have not seen CI
>> build an aarch64-linux kernel in ages)...
>
> Yeah we could probably trim those versions a bit.

All versions but 5.10.x are updated to at least resolve the copy.fail
issue. So that begs the question ... can/should we just deprecate and
eventually drop 5.10 before it is end-of-"life"/EOL (December 2026)?

I think typically guix has kept them around until the EOL and then a bit
longer... to give people a chance to migrate. Though a more aggressive
policy might serve us well with out limited resources.

This conversation sems a bit much for help-guix, but on the other hand,
maybe appropriate if anyone is using old kernels ... but maybe should
also be brought up on guix-devel...


>> I think the vast majority of the time is applying and verifying the
>> linux-libre patchsets to generate the cleaned source tarball;
>
> I’m curious: Debian has a cleanup mechanism probably similar to that of
> Linux-libre, no?  How does it compare, both in terms of accuracy and
> speed?

As I understand it, mostly Debian historically did not ship any of the
non-free firmware files with or alongside the kernel itself, but also
did not disable the capacity to load it.

So simply putting any distributable but non-free firmware files in
Debian's non-free section of the archive (and more recently, the
non-free-firmware section, which is enabled by default, but possible to
disable) ... but did not for the most part modify the source code very
much.

So people could opt-in/opt-out to the non-free bits by enabling the
totally-not-officially-part-of-debian non-free(-firmware) section(s), or
rummage around on the internet and place the firmware files in the right
place and the kernel would load them at boot.

A quick glance at the current packaging and I cannot find many things
that get removed at the source code level, see the Files-Excluded field:

  
https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/copyright?ref_type=heads

There are a few relevent patches applied as well:

  
https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/patches/series?ref_type=heads#L3
  
https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/patches/series?ref_type=heads#L31


By contrast, linux-libre does actually modify the source code to disable
loading of known non-free firmwares, which touches a lot more code
overall. They release a linux-libre tarball (which guix does not
currently use) and scripts to produce that tarball from upstream (which
guix does use).


So, it is two fundamentally different approaches, not sure if Debian's
approach would comply with the Free System Distribution Guidelines, as
the code still points at non-free stuff...


live well,
  vagrant

Attachment: signature.asc
Description: PGP signature

Reply via email to