Linux Libre in Debian

[Jason Self]

> 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

To be sure my concern was different which I'll explain below.

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

This seems to address my concern. My understanding is that Debian's
kernel packaging is available via
https://salsa.debian.org/kernel-team/linux

So a strategy could be to "just" take the Linux-libre tarballs, add the
Debian bits, and compile. The only difference from a "normal" Debian
tarball is substituing one from fsfla.org instead of kernel.org. The
process could otherwise remain the same.

I think Alexandre Oliva did a good job explaining the future plan.

With that plan in mind, and imagining the future state with the Linux-
libre git repository synchronized with upstream (Torvalds and -stable)
on a per-commit basis, cleaning commits as they happen rather than
running a deblob-<kver> script on a final tarball, the Linux-libre git
repo can stay mere minutes behind upstream. This allows for faster
releases and provides bleeding-edge versions for users who need them.
Eventually, this would mean the deblob-<kver> scripts are no longer
developed for new versions in favor of the pre-cleaned git repository
and resulting tarballs.

My concern is whether the Debian kernel project project as had been
initially proposed could survive that shift. If this Debian kerenel
workflow is built around scripts that will eventually disappear, it
seems there's future breakage incorporated into the plan. Since the
clean git repository and tarballs are already available, why not base
the project on those sources now rather than "kicking the can down the
road"? It would be disappointing to choose a short-term strategy now
that forces a migration later, or maybe even ends the project entirely
if it can't survive the change, especially when the long-term solution
is already available to use the tarballs and git repository.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 870 bytes
Desc: This is a digitally signed message part
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20251208/cf19f1f7/attachment.sig>