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> -- If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.