Linux Libre in Debian

[John Scott]

Ahoy,

I've been lurking on both this thread and discussion on debian-devel so far and hadn't found the time to respond until now, so I'd like to share my thoughts for whatever they're worth. I'm a Debian Maintainer and my chief achievement so far is getting the carl9170 and ath9k_htc firmware projects (for 802.11n USB wireless adapters) to build from upstream sources, and packaging the esoteric cross compilers needed to do that. To my surprise, those were the main hurdles to getting the entirety of src:firmware-free to build without pre-shipped blobs. If either of you—or anyone else on this list—would like to help, that'd be most welcome.

> [Simon] I have published Debian Libre installer images, built without any non-free software, and that sparked an idea on how to get linux-libre into Debian.
I really admire this and the https://libre.debian.net web page explains things well. I'll be looking at how I can help going forward.

> [Simon] Specifically, what do you think about running deblob from within a 'linux-libre' Debian package debian/rules script, using Debian's linux-source as a build dependency for the Linux source code? To produce a binary linux-image binary.
From experience packaging bare-metal cross-compilers using binutils-source and gcc-*-source, I think this is viable. There may have been a misunderstanding however I would like to clear up: whatever steps would be needed to transform linux-source into a linux-libre source tree (whether that be a deblob script or some successor), it must not be applied to a newer version of linux-source than what it was designed to work with. Perhaps this is where some of Jason's reservations are coming from; but in fact I think keeping them in sync will be fairly practical. Debian Stable is the main product of the project and it's very well-known how limited changes are after release. For the kernel that's mostly just picking up minor updates on an LTS branch.
A versioned build dependency would actually work well here, I think. For example [Build-Depends: linux-source-6.12 (= 6.12.57-*)] or its equivalent in legal dpkg syntax would work. Even during the development cycle, new kernel uploads to Debian unstable are customarily preceded by an announcement to key stakeholders like the Release Team before they occur, as in https://lists.debian.org/msgid-search/aTV2o71NFOqTIyBa%40eldamar.lan/firsthit and this would allow time to prepare a new linux-libre source package upload.

Aside from time race concerns, this looks good and even if the linux-libre packages continue to be distributed only through non-Debian channels, using their source package as a base is a great idea. Proving the concept before soliciting opinions from the Kernel Team would be extra nice.

> [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.

> [Jason] The Trisquel people for example modify the deblob scripts to work on their kernel, which comes from Ubuntu with added modifications that the Trisquel people also make. Those changes are what cause the scripts to fail when things aren't in the expected location and when Ubuntu adds more blobs that the scripts don't expect - they don't clean them up. I don't know how well they will work on a kernel from Debian but it's probably wise to expect some modification if you go that route.
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.

> [Jason] It's also not enough to just run the deblob scripts; a follow up with deblob-check is also needed along with a human review to determine if there's anything left behind that the scripts didn't catch.
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? 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? If a user were to follow the same steps, with the same original tarball version and deblob script version as what was used to make the linux-libre tarball, and follow the exact same procedure, how could there be known blobs left in the source tree at the end?
Perhaps you've implicitly made the assumption that the deblobbing script/process (or its equivalent) will be automatically carried over to newer upstream kernel versions when they get into Debian, those newer versions possibly being ones that the deblob script isn't known to work with. With a versioned build dependency as I mentioned before, this need not be the case. A linux-libre source package can be kept in lockstep with linux-source as tightly as we may need.

> [Jason] In the future, the only thing that will exist is the Linux-libre kernel source code and the deblob-check program to look for blobs and requests for blobs, but the automated tools that you're talking about using will be gone. How will you do the converting when there are no converting tools anymore?
If there are no converting tools anymore, how will the Linux-libre kernel source code on linux-libre.fsfla.org be created to begin with? As an exaggerated example, it would be absurd if you or a Linux-libre maintainer were to merely memorize what files are problematic and remove them each time.

> [Jason] I don't know that either of them [Trisquel and Guix] have a plan but the recommended method is to use the Linux-libre source code tarballs and/or git repository to get the kernel source code.
Maybe we could use the Linux-libre tarball in a way that's fine for Debian: maybe we can use real linux-libre tarballs and move the Debian bits (including patches) over. The resulting source tree ought to be basically the same.

In summary, I think Debian has the tooling—even if it's lesser-known and requires some more esoteric tricks—to do this right. I will do some serious thinking about how I can help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: This is a digitally signed message part
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20251207/c6d6b04b/attachment.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6270 bytes
Desc: not available
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20251207/c6d6b04b/attachment.bin>