unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: guix-devel@gnu.org, Marius Bakke <mbakke@fastmail.com>
Subject: Re: Linux-libre 5.8 and beyond
Date: Sat, 08 Aug 2020 20:02:48 -0400	[thread overview]
Message-ID: <87o8nk4rek.fsf@netris.org> (raw)
In-Reply-To: <87pn8097po.fsf@ponder>

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


  reply	other threads:[~2020-08-09  0:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-08 20:57 Linux-libre 5.8 and beyond Vagrant Cascadian
2020-08-09  0:02 ` Mark H Weaver [this message]
2020-08-09  3:30 ` Mark H Weaver
2020-08-09  3:43   ` Vagrant Cascadian
2020-08-09 18:09     ` Vagrant Cascadian
2020-08-09 22:17       ` Mark H Weaver
2020-08-10 22:39         ` Bengt Richter
2020-08-11  2:37           ` Tobias Geerinckx-Rice
2020-08-09 18:49   ` Leo Famulari
2020-08-25 21:01 ` Leo Famulari
2020-08-26  3:17   ` Leo Famulari
2020-08-26 15:41     ` Katherine Cox-Buday
  -- strict thread matches above, loose matches on Subject: below --
2020-08-09 20:15 Jason Self
2020-08-13  0:39 ` Mark H Weaver
2020-08-14 13:47   ` Alexandre Oliva
2020-08-15  6:03     ` Mark H Weaver
2020-08-16  1:24       ` Mark H Weaver
2020-08-16 12:43         ` Jason Self
2020-08-16 10:54       ` Jason Self
2020-08-24  3:45       ` Alexandre Oliva
2020-08-25  4:14         ` Mark H Weaver
2020-08-25 11:12           ` Alexandre Oliva
2020-08-24  3:58       ` Alexandre Oliva
2020-08-24  4:12       ` Alexandre Oliva
2020-08-24  4:34       ` Alexandre Oliva
2020-08-24  4:42       ` Alexandre Oliva
2020-08-11  4:07 Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8nk4rek.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=guix-devel@gnu.org \
    --cc=mbakke@fastmail.com \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).