Hello, Mark,
On Aug 12, 2020, Mark H Weaver wrote:
> Mark H Weaver wrote:
>>> the linux-libre project periodically deletes most of its older
>>> tarballs, even if there are no accidents.
> Jason Self responded:
>> Just FYI that git://linux-libre.fsfla.org/releases.git was created
>> mainly to solve that problem. Versions are now pretty much permanent.
> That's helpful, thanks. I didn't know about this. Out of curiosity, is
> this git repository advertised anywhere?
Not much. It was mentioned back in the announcements of 5.7-gnu and a
few subsequent ones on social media; in the 5.7-gnu news entry in the
Linux-libre web site, and in the documentation we wrote for Guix
developers, that was sent to some of you not long ago.
Though it was announced sort of widely, since this move was directed
primarily at satisfying a Guix pain point, I figured I'd add it to
downloads only after making sure it did address Guix's needs, so that,
should it require significant changes, there wouldn't have to be much
concern about backward compatibility with the current status quo.
> One question: Would it solve the problem that I mentioned in my earlier
> email, namely the problem of how to determine which precise commit
> introduced a regression between two stable kernel releases?
No. There are much better (faster and less risky) ways to tend to that
requirement, see #bisecting below.
>>> 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.
>>
>> The cleaning up scripts are version-specific and won't work on an
>> "arbitrary commit from Linus's mainline git repository" (i.e., someone
>> wanting to get today's most recent commit going into 5.9.) The scripts
>> would fall over and die in such a scenario,
> Okay, perhaps this was wishful thinking on my part.
Yup. If you ran a deblob-check in verify mode on the resulting
tarballs, you'd see how error-prone this is. You'd at least stop
non-Free code from silently sneaking in and finding its way into running
on users' machines. That's the *least* someone who runs the
deblob-scripts on their own should do to smoke-test the result WRT
*known* freedom issues.
> I had hoped that the deblob scripts would typically mostly work, even
> if they weren't able to do a comprehensive cleaning.
I'd honestly hope for a much higher standard than that for a
FSDG-compliant distro, especially one that carries the GNU mark.
> I would oppose adding such a partly-cleaned kernel to Guix itself,
But you don't! That's what you get when you jump the gun and use
outdated cleaning up scripts, without waiting for us to verify,
update and release them for a newer version.
> but I wanted to enable users who need to use some other branch of
> Linux on their own systems to make a best-effort cleaning.
Besides the likelihood of something going wrong, that seems like a
backwards goal for a distro that is not expected to as much as point
users at a non-Free package.
I'm sure that's not what you intend, but this arrangement, plus your
mention of hurriedly getting releases out, adds up to an incentive to
disable the deblobbing so as to get a faster build. I hope you'll agree
that this is undesirable. As for how to speed up builds without
sacrificing freedom, see below.
>>> It allows us to update to a new point version (which usually
>>> includes security fixes) more quickly, before the linux-libre
>>> project reacts.
>>
>> Any attempt outrun the Linux-libre project and get updates out sooner
>> is unwise. While major new kernel releases will definitely require
>> updates to the cleanup scripts, even minor patched versions
>> occasionally require changes too. Updating to a new version prior to
>> the Linux-libre project having had time to review that new version and
>> determine if any updates are needed to the scripts risks introducing
>> freedom problems in the corresponding Guix version.
> In my experience, the deblob scripts are very rarely changed after the
> first few point releases of a stable release series.
My personal experience tells me otherwise. 5.7 had only one update at
.8; 5.6, at .6 and .16; 5.5, at .3, .11 and .19; 5.4, at .14, .18, .27,
.34 and .44; 5.3, at .4 and .11; 5.2 at .1, .3 and .11; 5.1 at .2, .18
and .20; 5.0 at .7 and .16. What you describe was true only of 4.17,
4.10, 4.3, 3.13, 3.5, and 3.2, i.e. 6 out of the 50 major releases
starting at 3.0.
> I know this because I always check for updates to the deblob scripts
> whenever I update linux-libre in Guix. In practice, the deblob scripts used
> by
> Guix are never more than 1 or 2 micro versions behind the version of
> Linux they are applied to.
There have been 61 script updates for the 1274 4.*.*-gnu* and 5.*.*-gnu*
stable releases, so Guix has shipped potentially non-FSDG code, that
*would* have been flagged by deblob-check
