Linux Libre in Debian

[Alexandre Oliva]

On Dec  7, 2025, John Scott <jscott at posteo.net> wrote:

>> [Jason] The deblob scripts eventually won't exist as we move to a
>> different method, so relying on them isn't maintainable long-term
>> and will likely affect Trisquel's process as well.
> What could such a "different method" look like? If it's no longer in
> the form of a shell script named 'deblob' but can still be done
> programmatically, that seems like an unimportant difference.

Currently, most changes are made through deblob-check, that can only
replace undesirable strings with /*(DEBLOBBED)*/, and a few other
changes made with sed scriptlets and rm, as driven by deblob-<kver>.

The plan for the future is to rewrite the commit history from the Linux
git repositories (Torvalds' and -stable), detecting and cleaning up the
blobs at the point of their insertion, so that the end result is a
repository with a free history with corresponding commits, branches and
tags, and a commit-id mapping.  Instead of cleaning up releases
mechanically, we'll have upstream commits mechanically verified instead,
and incrementally added to this repository, with required cleanups made
manually rather than mechanically, so that the resulting code looks more
like something that was written that way, rather than a blotch over
objectionable parts.

> Most Debian packages use a system called Quilt to keep patches that
> should be applied to upstream sources after they're unpacked. Although
> the Debian kernel packages have to do this a little more elaborately,
> it's my understanding they have this same workflow. Thus it ought to
> be possible to unapply or "pop" those patches if the liberation
> tooling needs a pristine source, and then add the kernel team's
> packages back after.

*nod*, but that doesn't solve the problem of publishing objectionable
(nonfree or non-FSDG) bits as corresponding sources.

It also involves checking the patches themselves for objectionable bits.
deblob-check can do that, but it's not always as straightforward if the
patchfile matches only part of a recognized pattern.  I used to deal
with that back when maintaining Freed-ora, and sometimes I had to tweak
deblob-check or the patchfiles themselves to get to a desirable outcome.

> Is this really true if taken literally? I'd expect that running a
> suitably-recent version of deblob-6.12 on an upstream Linux 6.12.60
> tarball would create an almost-identical source tree to the
> linux-libre-6.12.60-gnu tarball. That is how it's made, isn't it?

We occasionally need to adjust both deblob-check and deblob-<kver>,
because stable releases sometimes bring in new bits that need to be
cleaned up.  Running deblob-check on the supposedly cleaned-up tree is
one of the ways we can detect such problems, because deblob-check has
patterns to detect various unknown problems.  If you were to go your own
way, you should really take similar care to avoid distributing obnoxious
bits as if they were free.

> Also, if the linux-libre-6.12.60-gnu tarball is available for download
> on linux-libre.fsfla.org, doesn't that imply that someone here ran the
> deblob script (making changes if necessary) on the corresponding
> upstream kernel source, decided it looks good, and uploaded that?

Yes, and if you use the same scripts on the same upstream tarball, you
should get the same resulting tree.  It doesn't hurt much to check
(consider the possibility of awk/python/sed bugs, running out of memory
or otherwise failing to clean things up), *especially* if you're
cleaning up a modified tree.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
Learn the truth about Richard Stallman at https://stallmansupport.org/