- Mentioned In
- T241: chromium - promotes non-free NVIDIA driver via (embedded copy of) libxnvctrl
T224: qtwebengine-opensource-src - promotes non-free NVIDIA driver via libxnvctrl
T223: psensor - promotes non-free NVIDIA driver via libxnvctrl
T222: mate-sensors-applet - promotes non-free NVIDIA driver via libxnvctrl
T221: conky - promotes non-free NVIDIA driver via libxnvctrl
T655: libxnvctrl bogusly blocked from entering PureOS
conky: libxnvctrl-dev |nvidia-settings
psensor: libxnvctrl-dev |nvidia-settings
--> We can't remove this just yet.
Also, I don't get why the thing is actually a "freedom issue" if it's actually free software (sure, it only becomes really useful if one uses non-free drivers, but we don't ship those. Removing this thing will cause some pain though, mainly through psensor and qtwebengine)
Yeah, I have similar comments for smtube issue. As this is also indeed Free software and sadly it is not usable without nonfree nvidia, we will postpone the work on it because of obvious dependency havoc it would cause. It also doesn't break FSF rules afaik.
Will remove the following packages from landing: libxnvctrl-dev | 375.66-3 | amd64 libxnvctrl0 | 375.66-3 | amd64 nvidia-settings | 375.66-3 | source Maintainer: Debian NVIDIA Maintainers <firstname.lastname@example.org> Will also send CCs to: <<redacted>> ------------------- Reason ------------------- Freedom issue ---------------------------------------------- Checking reverse dependencies... No dependency problem found. Going to remove the packages now. Deleting... done.
$ lk-admin synchrotron blacklist-add nvidia-settings 'References non-free NVIDIA driver' Package blacklisted.
I have come to same conclusion as you, @mak, that this is no Freedom issue, and too painful without any real gain to try solve.
My previous reasoning was that libxnvctrl encourages the use of non-free software indirectly by encouraging hte use of hardware (GPUs) that work only with non-free software. But that is slightly (yet semantic importantly) wrong: a library enables use but does not encourage said use (this is the equivalent to the debate in Debian over libraries recommending executables they enable access to - e.g. gnupg).
Bug was closed and stay closed. Changing semantics for closing to be because it is invalid (not because all instances of this issue is addressed).