Linux Libre in Debian

[Simon Josefsson]

Thanks for explanation!

My main concern is that I want to do something in Debian now -- and your
deblob approach seems to be supported right now, for 6.17, isn't it?
When will the future approach be ready and the deblob approach
decommishioned?

To be honest, without knowing much about this area, I like the deblob
approach.  It makes the boundary between upstream Linux kernel and your
work clear.  It also avoids having two 95% identical source code trees
to audit.  Having two tarballs with mostly the same code is a
vendoring-problem.  I suspect the Debian kernel folks would really like
to avoid that, maintaining kernel security patches for two sets of
source trees is tedious work.

I have tried to run deblob-6.17 on Debian's 'linux-source-6.17' kernel
source code (which is pretty much verbatim upstream kernel.org sources,
but they do prune some files that you do too!) and it worked.  I am now
trying to get something to build, trying to figure out what config file
to use.

/Simon

Jason Self <j at jxself.org> writes:

> The deblob scripts are intended to be used on the kernel source code
> that comes from kernel.org. They're version-dependent and there are
> updates made for every major kernel release and sometimes during a
> major release too so as to address freedom problems that are introduced
> during that version. The deblob scripts we ship will likely fail on any
> other kernel. 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.
>
> 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.
>
> But I urge you to reconsider going that route: The scripts are on the
> way out. 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?
>
>> 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'.
>
> I don't have any name suggestions at present. I suppose reusing the
> linux-libre name depends on what this ends up shaping into.
>
> _______________________________________________
> linux-libre mailing list
> linux-libre-3d8yaqT+vUfYtjvyW6yDsg at public.gmane.org
> http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
>
-------------- 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/20251202/e9e2eaeb/attachment-0001.sig>