Alexandre Oliva <[email protected]> writes:
> Hello, Simon, > > Thanks for undertaking debian-libre, it's very valuable IMHO. Thanks for support! I'm trying to navigate things in a way that makes practical progress possible. > On Dec 1, 2025, Simon Josefsson > <[email protected]> wrote: > >> 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'? > > IMHO, as long as you follow the same approach and reach the same goal of > GNU FSDG-compliance, there's no reason to mind your calling it > Linux-libre, even if you need to adjust some details because you're > starting from a slightly different baseline. Ok. I'm beginning to find the name 'linux-deblob' more appropriate to what I'm attempting, because that 1) matches the approach taken to use the deblob scripts, and 2) allows for a a futre 'linux-libre' package following some other approach, and 3) doesn't hijack the linux-libre name for things that may end up being somewhat different due to Debian vs linux-libre packaging concerns. If at the end of this 'linux-deblob' and 'linux-libre' is identical, that's great, but there seems to be signs that there will be some small differences (for example, the kernel config to use). Calling something similar but not identical by the same name may be confusing. One pun here is that 'deblob' contains the beginning of 'DEBian' too. > There's one concern in my mind, however, about what corresponding > sources you'd publish. If you just add cleaning-up scripts to Debian's > sources, you'll be already better off than those who publish upstream > sources plus scripts, because they still make binary blobs available > under obnoxious licenses as part of their source trees, whereas I > believe Debian cleans those up. You might still be shipping plenty of > binary blob names and freedom-averse pieces of documentation, unless you > publish as corresponding sources the *result* of the cleaning up. I'm not sure I follow all the subtleties involved here, but two approaches: 1) A 'linux-deblob' Debian source package that have 'linux-source-6.18' as Build-Depends and just contain the deblob-* scripts, run those on the Debian source code (which contains offensive blobs), and build a binary image package e.g. 'linux-image-deblob-*'. 2) Doing 1) but ALSO output a new binary package 'linux-source-deblob-6.18' which is the output of running the deblob scripts on the source code. I'm not sure what use there is for such a package really, but maybe it fits some piece of the puzzle here. It would serve the same purpose as the current 'linux-source-6.18' package, which is for later consumption by others who doesn't want to duplicate the deblobing process. > I'll second Jason's warning that the script-based approach to cleaning > up is to be phased out when we switch to a manually-cleaned repository. Debian is tarball centric, and if I understand correctly, the resulting tarball of your linux-libre will be identical regardless if they were prepared via git-scrubbing or through a deblob script. So I'm not sure this aspect is that relevant for Debian packaging. > We will still have a deblob-check, but the plan was to not have a > deblob-<kver> any more. > > That said, maybe we can figure out a way to turn diffs between upstream > and libre releases into a script that cleans things up. That may > involve running patch to do part of the job, but publishing such scripts > is probably not going to work, freedom-wise. A future simulation of the 'deblob' script could be just doing: 1) wget linux-6.18.tar.gz wget linux-libre-6.18.tar.gz unpack diff -ur linux-6.18 linux-libre-6.18 > deblob-6.18.patch 2) and a hypothetical deblob-6.18 would just contain: patch -p1 < deblob-6.18.patch This ought to work for Debian too, modulo some DFSG-cleanups that Debian is already doing to the upstream source code. For Debian needs, which is tarball centric, the current deblob-* script approach seems easier to audit for what kind of non-free stuff is actually removed, compared to the above approach. The diff will not be easy to read, whereas the deblob script appears to be as simple as they can be. >> anyone have ideas for names, that would be great ('linux-deblob'?). I > > linux.deblibred could be fun if you'd rather go for a name other than > linux-libre. I like that! Or 'linux-deblibre' combining both DEBian and 'libre'. Or 'linux-deblib' to imply that this is a Debian-variant of the deblob scripts. /Simon PS. This is a re-send, I think the original never showed up, sorry if this ends up as a duplicate somehow.
signature.asc
Description: PGP signature
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
