Re: Linux-libre 5.8 and beyond

[Mark H Weaver]

Hi,

Vagrant Cascadian <vagrant@debian.org> wrote:
> Thanks for updating linux-libre to 5.7!

Yes, many thanks to Leo Famulari for taking care of that (large) job.

> I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
> python indefinitely during the deblobbing process. I also tried
> switching to python 3 instead of python 2, but it had the same
> issue. Apparently this is a known issue:
> 
>   https://lists.gnu.org/archive/html/info-gnu/2020-08/msg00001.html

Thanks for bringing this to our attention.  Until the deblobbing issue
is resolved, in the definition of 'linux-libre-5.8-pristine-source', we
could simply replace the call to 'make-linux-libre-source' with an
ordinary 'origin' form that fetches the deblobbed source tarball from
the linux-libre project, using (linux-libre-urls linux-libre-5.8-version)
as the URI.

The bigger issue is that the default configurations will need to be
updated again before 5.7.x reaches end-of-life, which will be quite
soon.  Otherwise we'll need to revert back to 5.4.x in order to get
upstream security updates.

> So I asked a bit in #linux-libre on freenode and they wondered why we
> don't use the git repository instead of running the deblob scripts again
> in guix.
> 
> One of the issues might be that linux-libre may occasionally remove
> releases that accidentally contained non-free code breaking guix's
> ability to build old versions.

Last I checked, the linux-libre project periodically deletes most of its
older tarballs, even if there are no accidents.  This problem came to my
attention while trying to help someone determine which version of
linux-libre introduced a bug on their system.  I was about to suggest
bisecting point versions before realizing that the relevant linux-libre
tarballs had all been deleted.  Moreover, if we had succeeded in finding
the first buggy release, the next step would have been to do a 'git
bisect' to determine the precise commit that introduced the bug.

Other reasons to run the deblob scripts ourselves include:

* It may be useful for users with newer hardware devices, which are not
  yet well supported by the latest stable release, to use an arbitrary
  commit from either Linus' mainline git repository or some other
  subsystem tree.

* It allows us to update to a new point version (which usually includes
  security fixes) more quickly, before the linux-libre project reacts.

* It allows us to avoid trusting the integrity of the systems used by
  the linux-libre project to produce their deblobbed tarballs.

     Regards,
       Mark