GNU Linux-libre 5.14-gnu, and earlier -gnu1 respins

Tue Aug 31 07:34:03 UTC 2021

Apologies for the delay in getting this announcement out.  It's been a
very busy couple of days, and this announcement had a lot of ground to
cover.  Thanks for your patience.

GNU Linux-libre 5.14-gnu cleaning-up scripts, cleaned-up sources, and
cleaning-up logs (including tarball signatures) are now available from
our git-based release archive git://linux-libre.fsfla.org/releases.git/
tags {scripts,sources,logs}/v5.14-gnu.

Tarballs and incremental patches will shortly be available at
<https://www.fsfla.org/selibre/linux-libre/download/releases/5.14-gnu/>.
Freesh .debs are probably ready by now, and Freed-ora rpms are yet to be
built.  BTW, Freed-ora still needs new maintainers.  Please let me know
in case you're interested, and whether you'd like to share that task
with others.

The cleaning up scripts have been changed in very significant ways since
the last -rc.  But first, the regular stuff.

Cleaning up of i915 was adjusted on account of a renamed file; drivers
for sp8870 and for other av7110 cards got moved in the upstream tree and
cleaning up had to be adjusted.  An r8188eu file we used to clean up was
removed, and documentation for the btqca driver got renamed upstream and
cleaning up needed adjusting.  Upstream added a dts file specifying
blobs to load for a new Qualcomm arm64 variant, and we've cleaned them
up.

Emulex Fibre Channel Target, eftc, is a new driver that seems to have
inherited a blob-loading feature from its sibling lpfc.  Both build blob
names from data read from the device, and then attempt to load them.
That attempt is disabled in our distribution.

New blob names were also found in btrtl, amdgpu, and adreno, and they
have been cleaned up.

Between rc7 and final, the Renesas xHCI driver got a change in the API
used to load blobs, and our cleaning up scripts had to be adjusted to
match.

On to the unusual stuff.  A little over a week ago, Legimet raised flags
on some potential nonfree code in GNU Linux-libre.

Though some of the issues were about different standards (we don't
generally regard poorly documented code or pure data as object code over
speculation about the existence of an alternate, preferrable source
form), but a couple of the issues turned out to be sourceless object
code, and so we started the process of cleaning them up, and of
respinning earlier releases that contained them.

So now we clean up a firmware patch for vs6624 sensors, and several
microcode relocation patches for powerpc 8xx.  Both are encoded as
arrays of numbers in upstream Linux releases.  The latter had long
seemed suspicious to me, but I had assumed those who started cleaning up
Linux before I inherited Linux-libre had good reasons to leave it in.
The former was entirely my own mistake.  I was likely fooled by
apparently discontiguous address ranges, a pattern that suggests
register initialization, but the multiple small fragments are actually
larger contiguous ranges (thanks, Juca!), shuffled for reasons unknown.

Thanks, Legimet, for reporting the issues.

Back in the old days, when our releases were identified by -libre rather
than by -gnu, it was not uncommon to respin older releases.  Sometimes
we changed the cleaning up machinery and wanted to use it in earier
active branches, for uniformity; sometimes Free firmware became
available and drivers no longer needed to be cleaned up; other times we
found or were told of errors as above.

For such respins, we'd increment the -libre release counter, first to
-libre1, then -libre2, and so on.  We hadn't had reason to do so since
we became a GNU subproject, but the day was bound to come.  We now have
-gnu1 releases for all of the active stable and longterm upstream
branches: 5.13, 5.10, 5.4, 4.19, 4.14, 4.9, and 4.4.

I've used the same deblob-check (our "database" of patterns to accept,
flag or clean up) that went in 5.14-gnu, and backported various
cleaning-up improvements that had been introduced over the years since
4.4 first came up.  This took some back-and-forth testing and verifying
and adjusting until I thought all of them had got cleaned up properly.

While making the adjustments and hitting some differences in earlier
versions, I've improved the cleaning up of x86 microcode documentation,
and split various cleanup directions that used to be grouped under
MICROCODE or similar.  These cleaned-up files are now listed under the
actual configuration keys that enable them, even though the cleanups are
conceptually related with microcode updates.

After nearly 22 hours non-stop of cleaning up and backporting and
adjusting and respinning and fixing and repeating, I had all of the base
releases ready, so I pushed them to the git repo, and went for some
sleep.  As I woke up, 5.14-gnu, 5.13-gnu1, 5.10-gnu1, 5.4-gnu1,
4.19-gnu1, 4.14-gnu1, 4.9-gnu1, and 4.4-gnu1 tarballs had finished
compressing, and I started respinning the latest patch release of each
branch.

Alas, I did not catch a cleaning up error in 4.4-gnu1's b43 and
b43legacy drivers, caused by my failure to backport some long forgotten
custom cleaning up directions from the deblob-4.9 script to deblob-4.4,
that still carried a more limited form of cleaning up.  Without those
directions, deblob-check dropped quotes along with b43's blob names, and
syntax errors ensued when attempting to build those modules.  Jason Self
hit and reported the build error, and so we got b43 fixed in
4.4.282-gnu1.

This was very important: b43 is one of the few WiFi drivers that works
with Free firmware on some cards, and it was the need for retaining the
code to load the Free firmware available for some variants, while
disabling the code that loads the non-Free firmware that other variants
require, that made its cleaning-up code so unusual, and deserving of a
major rewrite with custom code between 4.4-gnu and 4.9-gnu.

As soon as the respins were done, I pushed 5.13.13-gnu1, 5.10.61-gnu1,
5.4.143-gnu1, 4.19.205-gnu1, 4.14.245-gnu1, 4.9.281-gnu1, 4.4.282-gnu1
to the git repository.

I also prepared erratum patches for 4.4-gnu1 scripts and sources; I've
dubbed that 4.4-gnu1a.  It's not a release proper, just some patch files
that will appear in releases/4.4-gnu1/errata-a/ in the download
repository.  I figured I should get them in git too, even though they
didn't go through the release process, so I applied the patches onto
scripts/4.4-gnu1 and sources/4.4-gnu1, and tagged them as 4.4-gnu1a.
There's a logs/4.4-gnu1a as well, with an ERRATUM.txt instead of
README.txt, and no logs nor tarball signatures, but rather the patches
and their signatures.

Alas, I didn't notice the same problem affected b43legacy, and shortly
after I pushed 4.4.282-gnu1 out, Jason reported the b43legacy problem
was still there.  Ugh.  Unlike b43, that works on some cards with Free
firmware, b43legacy doesn't work on any freedom-compatible cards, so if
you hit the issue and wish to work around it before a fix is out, you
might as well disable that module.  I expect to put out 4.4-gnu1b and
4.4.282-gnu1b errata along with 4.4.283-gnu1, shortly after 4.4.283
comes out upstream.  Hopefully this will be the end of it.

Or maybe not.  If you'd have use for a respin of any of the other major
releases (and latest stable/longterm patch release), please let me know.
If you ask politely :-) I can try and give it a respin too.

It will be eventually take over by the Linux git history librewrite
(short for libre rewrite :-) project I've finally got going, that will
greatly simplify and speed up the release process (just progressively
integrate commits from upstream, fixing any freedom issues at point of
the commit that introduces it), but it's still going to be a while till
it catches up with active branches.

(Incidentally, respins will become even more laborious under this
arrangement, so let's hope they remain rare events, or that they're
justified by newly-available Free firmware)

The -gnu tarballs of past releases, that contain the newly-removed
non-Free Software bits, are going away in a not-too-distant future (say
from a couple of weeks to a month, when our infinite hunger for disk
space gets close to filling up again the storage kindly provided by the
FSF (thanks! :-).  At that point, only scripts and patches are going to
remain within releases/old/gen6.

The git tags are also going away, probably at about the same time: they
aren't anywhere as space-hungry as tarballs, but those that contain
non-Free Software don't belong in our git repository.

In yet another news, we've been hanging out in the #gnu-linux-libre
channel on libera.chat for a while now.  Unlike #linux-libre on
freenode, that we'd used long before becoming a GNU subproject, the new
channel is in the GNU namespace.

I don't know whether there are still people on #linux-libre on freenode,
but I haven't been hanging there any more, after being locked out by
one-too-many server configuration changes.

What I do know is that there are still people on #linux-libre on
libera.chat.  We used that channel for a few days, but couldn't get it
registered under that namespace, so it has a topic that follows the
right pattern (I put it there myself, a while ago), but we lost ops and
can't update it any longer.  I'm told this has got some people confused,
so if you are one of the few people who are still keeping it alive,
would you please vacate it, and join us on #gnu-linux-libre on
libera.chat instead?  Thanks, talk to you there, ;-)

For up-to-the-minute news, join us on IRC, or follow me on P2P or
federated social media.  Check the link in the signature for directions.

Be Free! with GNU Linux-libre.

What is GNU Linux-libre?
------------------------

  GNU Linux-libre is a Free version of the kernel Linux (see below),
  suitable for use with the GNU Operating System in 100% Free
  GNU/Linux-libre System Distributions.
  http://www.gnu.org/distros/

  It removes non-Free components from Linux, that are disguised as
  source code or distributed in separate files.  It also disables
  run-time requests for non-Free components, shipped separately or as
  part of Linux, and documentation pointing to them, so as to avoid
  (Free-)baiting users into the trap of non-Free Software.
  http://www.fsfla.org/anuncio/2010-11-Linux-2.6.36-libre-debait

  Linux-libre started within the gNewSense GNU/Linux distribution.
  It was later adopted by Jeff Moe, who coined its name, and in 2008
  it became a project maintained by FSF Latin America.  In 2012, it
  became part of the GNU Project.

  The GNU Linux-libre project takes a minimal-changes approach to
  cleaning up Linux, making no effort to substitute components that
  need to be removed with functionally equivalent Free ones.
  Nevertheless, we encourage and support efforts towards doing so.
  http://libreplanet.org/wiki/LinuxLibre:Devices_that_require_non-free_firmware

  Our mascot is Freedo, a light-blue penguin that has just come out
  of the shower.  Although we like penguins, GNU is a much greater
  contribution to the entire system, so its mascot deserves more
  promotion.  See our web page for their images.
  http://linux-libre.fsfla.org/

  If you are the author of an awesome program and want to join us in
  writing Free (libre) Software, please consider making it an official
  GNU program and become a GNU Maintainer.  You can find instructions
  on how to do so at https://www.gnu.org/help/evaluation.  We look
  forward to hacking with you! :)

What is Linux?
--------------

  Linux is a clone of the Unix kernel [...]

(snipped from Documentation/admin-guide/README.rst)

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>