Linux Libre in Debian

Simon Josefsson simon at josefsson.org
Mon Dec 1 15:57:14 UTC 2025


Jason Self <j at jxself.org> writes:

> After reviewing the options, I believe #1 is the best approach. 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.

I agree #1 is the better approach.  However, I think this has lower
chances of making it into Debian proper, or at least it may trigger more
objections.  Instead of taking on that fight (and possibly lose, since
the concern with security patching of multiple linux source code
archives seems reasonable), I want to consider other approaches.

What I think may be acceptable is taking the Debian 'linux-source'
package as a Build-Depends, apply whatever deblob techniques are
necessary to patch that into a linux-libre-alike source code, and then
build that.

> Currently, the freesh sources are at
> https://linux-libre.fsfla.org/pub/linux-libre/freesh/. The .deb files
> are generated using a modified version of the kernel's own build
> scripts (found in scripts/package) via make bindeb-pkg at compile time,
> but this isn’t ideal for producing distro-quality packages. It's likely
> more sustainable to reuse Debian's kernel packaging instead so that
> Linux-libre on debian incorporates the same configs, patches, etc.
>
> https://salsa.debian.org/kernel-team/linux
>
> Additionally, the same security patches applied to Debian's version of
> Linux should apply to Linux-libre. If the main security team doesn't
> want to cover this as indicates, perhaps someone else could do that? I
> expect most patches would apply as-is.

Thanks for the pointer!  I agree the approach to get to distro-quality
packages needs more research, and it isn't terribly clear what the right
trade-offs are.  To me, getting something as close as linux-libre into
Debian, using whatever method is acceptable, and then iterate on the
details, seems better than trying to design some perfect approach and
not be included in Debian.

Maybe naming here is a problem though.  If this doesn't use your
linux-libre sources, or even your deblob script, how do you feel about
even calling that 'linux-libre'?

Compare what Trisquel is doing, they seem to be doing something similar
to your deblob script, but it is not the same.  Trisquel doesn't claim
to be using linux-libre, though, right?  Was that a concious decision,
or merely accidental?

How similar are their packages to yours, really?  My perception is that
they are rather different, because Trisquel base their packages on
Ubuntu kernels, and you on upstream Linux.

I'm happy to proceed down the path of working on a
'user-mode-linux'-alike Debian packaging that produces a more libre
linux image, with the aim of getting that included in Debian.  Does
anyone have ideas for names, that would be great ('linux-deblob'?).  I
also think re-using the name 'linux-libre' would get messaging across
better, and the implementation details aren't terribly important, but I
understand if you feel this will be too far off from what is truly
'linux-libre'.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20251201/7f491f0e/attachment.sig>


More information about the linux-libre mailing list