From: Jason Self <jason@bluehome.net>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
Subject: Re: Linux-libre 5.8 and beyond
Date: Sun, 16 Aug 2020 05:43:54 -0700 [thread overview]
Message-ID: <20200816054354.722d6934@pc> (raw)
In-Reply-To: <87d03rgz70.fsf@netris.org>
[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]
On Sat, 15 Aug 2020 21:24:08 -0400
Mark H Weaver <mhw@netris.org> wrote:
> Hi Alexandre,
>
> I thought about it some more, and I've changed my mind on one point:
> I've decided that for future kernel updates, in order to eliminate the
> risk of unintentionally allowing blobs into Guix, I will either wait
> for Linux-libre to publish updated deblob scripts, or else I will
> manually check for new blobs.
This can be determined by checking for the availability of the new
kernel version in git. The git repository is updated first, prior to
tarballs being created so I assume you'd want to be looking there given
that speed of updates seems important. If the new kernel version
appears without a corresponding script update then you can know that no
script updates were determined to be necessary.
Wouldn't a better setup be to obtain the desired kernel version from
Linux-libre, obtain the desired kernel version from kernel.org,
independently run the clean-up scripts, and then toss out the results
from kernel.org once the source code is determined to be identical?*
I mean, if you're already willing to wait until the analysis of whether
updated cleanup scripts are needed or not has been done, then you're
already at the point of the Linux-libre kernel source code being
available too because once that determination is made, any updated
scripts and the corresponding kernel source code are pushed into git
simultaneously.
Confirming if the results you get from the cleanup scripts are the same
is helpful all around. It is not necessary to trust the Linux-libre
project infrastructure because you're also verifying the integrity and
also gets you access to the double verification steps that are done
which check that the version does in fact correspond to the upstream
version plus the changes that Linux-libre made, and that it also
corresponds to the previous release plus the incremental patches.
* As a disclaimer there may be one difference in that the clean-up
scripts will in some cases delete all of the files in a directory
while leaving the directory itself in place. Git doesn't track empty
directories and so diffing of the entire kernel source code would
reveal that. The diff should otherwise report everything to be
identical.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
next prev parent reply other threads:[~2020-08-16 12:44 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 20:15 Linux-libre 5.8 and beyond Jason Self
2020-08-13 0:39 ` Mark H Weaver
2020-08-13 16:47 ` Linux-libre git repository Vagrant Cascadian
2020-08-14 0:03 ` Jason Self
2020-08-14 14:03 ` Danny Milosavljevic
2020-08-14 13:47 ` Linux-libre 5.8 and beyond 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2020-08-11 4:07 Mark H Weaver
2020-08-08 20:57 Vagrant Cascadian
2020-08-09 0:02 ` Mark H Weaver
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200816054354.722d6934@pc \
--to=jason@bluehome.net \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.