About issue 27686: "Kernel Is Not Being Appropriately Deblobbed"
- Anmelden oder Registrieren um Kommentare zu schreiben
The issue seems to be flagged as active, unassigned: https://trisquel.info/en/issues/27686. But maybe it is in fact already being dealt with?
"This results in Trisquel shipping kernels that are not fully deblobbed."
I checked, and there are two blobs included in Trisquel's linux source package. These are the same ones that I reported to Alexandre Oliva recently, so I think this is because Trisquel is using an old deblob script, not because anything is going wrong with the deblobbing.
Besides removing the few (around 5) remaining blobs in the Linux source code, the deblob script disables blob loading in hundreds of drivers, and removes some scripts and documentation for extracting or installing such blobs. I have not checked if this is done fully in the Trisquel package. According to Alexandre, disabling loading of nonfree firmware is not actually needed for FSDG compliance in the context of a distribution that doesn't install or suggest installation of proprietary firmware: https://www.fsfla.org/pipermail/linux-libre/2021-May/003419.html
> disabling loading of nonfree firmware
The bug mentioned by jxself in the related thread is indeed about the kernel complaining about missing non-free sofwtare, not about (not) disabling loading it.
But the reported issue is of a different nature. See jxself's comment there:
https://trisquel.info/en/forum/hwe-kernels-can-load-proprietary-kernel-modules#comment-155759.
> the kernel complaining about missing non-free sofwtare
Right. In practice Linux-libre deals with this by fully disabling the loading of nonfree firmware.
I always find it unclear when people refer to "deblob" because only a small percentage of the deblob script actually removes blobs at this point, since the vast majority of blobs have been removed upstream. At this point, a deblob (without disabling the firmware loading) can be done by simply removing 5 files from the kernel source tree. The full script is only necessary if you want to disable the loading of nonfree firmware. And based on Alexandre Oliva's email that I linked above, it is not necessary for FSDG distros to do this: "For a distro that encompasses the other pieces and knows they won't induce users to error, this extra step is not essential."
Anyway, the big problem now is that there are two blobs that were present in Linux-libre until a few weeks ago, and they are still present in Trisquel's kernel: https://www.fsfla.org/pipermail/linux-libre/2021-August/003439.html (scroll down to the section about the nonfree code). This has nothing to do with jxself's issue, because this is due to the use of outdated deblob scripts, rather than said scripts not working correctly.
EDIT: I created a new issue referring to the exact blobs that are still present: https://trisquel.info/en/issues/28262
Merge request to update the deblob scripts, thereby removing the two blobs: https://gitlab.trisquel.org/trisquel/package-helpers/-/merge_requests/511
"And based on Alexandre Oliva's email that I linked above, it is not necessary for FSDG distros to do this: "For a distro that encompasses the other pieces and knows they won't induce users to error, this extra step is not essential.""
Not logging such "file not found" errors and other such messages for non-free software, which the cleanup scripts normally take care of, seems a good way to "not induce users to error."
Sure, but this is the "extra step" that Alexandre says is not needed for an FSDG-compliant distro. PureOS doesn't do this, and they were approved. It has been four years since PureOS was approved, so I don't see any reason to believe that the situation has changed.
> Alexandre says is not needed for an FSDG-compliant distro
From Alexandre's quote from your own comment above: "this extra step is not essential". I do not read this as "not needed", you are taking that extra step, not him. He seems to agree with RMS that this is, in fact, a problem.
Last time I checked, Trisquel was still recommended by the FSF, I guess that is what he means by "not essential".
I'm not sure how you can get from "not essential" to thinking that this step is needed for FSDG compliance.
Just to be clear, what I am saying is that for FSDG compliance a distro needs to remove proprietary firmware from the kernel, as well as documentation and scripts for installing such firmware. A distro can choose whether or not to go further by disabling the firmware error messages or disabling the requests, but this doesn't impact FSDG compliance. I have no idea what RMS thinks about this issue, but given the FSF's approval of PureOS, whoever is in charge of reviewing distros for FSDG compliance is OK with distros that simply remove the blobs. Apparently the standards for FSDG compliance are more lax than what most people here seem to think.
Meanwhile, the two actual blobs that are present in the Trisquel kernel source code are an FSDG issue.
This comment perfectly illustrates the problem:
https://trisquel.info/en/forum/compatible-usb-wifi-adapters#comment-160806.
The OP was fortunate enough to ask about it in the right place, but many others might have assumed Trisquel had a bug, and possibly given it up for Mint, not a positive outcome for software freedom.
NB: I always assumed that the "upstream" kernel here is not linux-libre but the kernel of the Ubuntu LTS on which a given Trisquel version is based. See: https://trisquel.info/en/wiki/how-trisquel-made. Maybe things have changed since, though.
The issue which was the actual topic of this thread has now been updated:
"This is no longer the case on nabia."
All is well.
> All is well.
Not yet, because the Trisquel linux source package contains two actual blobs. This is true of all versions of Trisquel. If you want to check for yourself, run "apt source linux" and check the files arch/powerpc/platforms/8xx/micropatch.c and drivers/media/i2c/vs6624.c. See https://trisquel.info/en/issues/28262.
The deblob scripts have now been fixed, so you should get the correctly deblobbed package soon.
- Anmelden oder Registrieren um Kommentare zu schreiben