Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On Sat, 24 Jul 2021, alicef wrote: > On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller wrote: >>> On Fri, 23 Jul 2021, Alice wrote: >> GNU FSDG-compliance require not only removing non-free code but also to disable loading of known non-free firmware. >> >> So they actually remove code that by itself is free software. I had >> suspected that. (By what logic does removing an option add to the >> user's freedom and choice, though? :) >> >>> I also point you to some other information from the mailing list >>> https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html >>> https://www.fsfla.org/pipermail/linux-libre/2021-May/003419.html >> >> Thank you. Looks like there's no issue with the LICENSE="GPL-2" label >> for recent kernels then. > that's not what they are saying. The first posting references a discussion on Wikipedia (which I think is a third party with a more neutral point of view than Linux-libre): https://en.wikipedia.org/wiki/Talk:Linux_kernel/Archive_7#RfC_on_the_Linux_kernel_licensing_rules I tend to agree with their conclusion, which resulted in the following wording: "The official kernel, that is the Linus git branch at the kernel.org repository, does not contain any kind of proprietary code; however Linux can search the filesystems to locate proprietary firmware, drivers, and other executable modules (collectively known as "binary blobs"), then it can load and link them into the kernel space." https://en.wikipedia.org/wiki/Linux_kernel#Firmware_binary_blobs > but I repeat again please open a thread to their own mailing list not > here. Sorry, but I don't care about the Linux-libre patches, only about the mainline kernel. So if anything, I would start a thread on the LKML about concrete files that violate the GPL. Then again, I don't have evidence of any such files (see above). Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On July 24, 2021 3:41:22 AM GMT+09:00, "Andreas K. Huettel" wrote: >> >> Gentoo is about choice. if there are users that want to use deblob I >> don't see why we don't have to add the option. >> > >Errr how is *removing the firmware loader* about choice? > >You have all the choice of the world by just not providing any firmware >to load. > >Removing the loader removes that choice. I'm not discussing gnu fsf philosophy here. That's their choice and most distro have a libre kernel option. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller wrote: >> On Fri, 23 Jul 2021, Alice wrote: > >>> GNU FSDG-compliance require not only removing non-free code but also >>> to disable loading of known non-free firmware. > >So they actually remove code that by itself is free software. I had >suspected that. (By what logic does removing an option add to the >user's >freedom and choice, though? :) > >> I also point you to some other information from the mailing list >> https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html >> https://www.fsfla.org/pipermail/linux-libre/2021-May/003419.html > >Thank you. Looks like there's no issue with the LICENSE="GPL-2" label >for recent kernels then. > that's not what they are saying. but I repeat again please open a thread to their own mailing list not here. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-dev] [PATCH 2/2] lua-single.eclass: consider historical impls in _lua_verify_patterns()
This is so that lua_gen_foo() calls die on mentions of formerly
supported implementations, allowing for such mentions to be gradually
removed from ebuilds which contain them.
Signed-off-by: Marek Szuba
---
eclass/lua-single.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
index ab4fdb3c75a..f55c3f80948 100644
--- a/eclass/lua-single.eclass
+++ b/eclass/lua-single.eclass
@@ -348,7 +348,7 @@ _lua_verify_patterns() {
local impl pattern
for pattern; do
- for impl in "${_LUA_ALL_IMPLS[@]}"; do
+ for impl in "${_LUA_ALL_IMPLS[@]}"
"${_LUA_HISTORICAL_IMPLS[@]}"; do
[[ ${impl} == ${pattern/./-} ]] && continue 2
done
--
2.31.1
[gentoo-dev] [PATCH 1/2] lua-utils.eclass: new eclass variable _LUA_HISTORICAL_IMPLS
Similarly to _PYTHON_HISTORICAL_IMPLS, it will hold names of Lua implementations which used to be supported but no longer are. Signed-off-by: Marek Szuba --- eclass/lua-utils.eclass | 7 +++ 1 file changed, 7 insertions(+) diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass index 278bbca58a3..12067928002 100644 --- a/eclass/lua-utils.eclass +++ b/eclass/lua-utils.eclass @@ -40,6 +40,13 @@ _LUA_ALL_IMPLS=( ) readonly _LUA_ALL_IMPLS +# @ECLASS-VARIABLE: _LUA_HISTORICAL_IMPLS +# @INTERNAL +# @DESCRIPTION: +# All historical Lua implementations that are no longer supported. +_LUA_HISTORICAL_IMPLS=() +readonly _LUA_HISTORICAL_IMPLS + # @FUNCTION: _lua_set_impls # @INTERNAL # @DESCRIPTION: -- 2.31.1
[gentoo-dev] [PATCH 0/2] Lua eclasses: prepare for dropping lua5-2 support
If memory serves me right there _are_ ebuilds which mention lua5-2 in lua_gen_cond_dep() calls. Let's steal another idea from Python eclasses and allow this implementation not to trip pattern validation in spite of no longer being supported by the eclasses, by be declaring it a historical implementation. For the time being the list of historical implementations is empty, will move lua5-2 to it on the scheduled date. -- Marecki
[gentoo-dev] Last rites: sys-kernel/bliss-kernel-bin
# Michał Górny (2021-07-23)
# Abandoned. All versions are vulnerable to CVE-2021-33909.
# sys-kernel/gentoo-kernel{,-bin} are the suggested replacements.
# Removal on 2021-08-06. Bug #803212.
sys-kernel/bliss-kernel-bin
--
Best regards,
Michał Górny
Re: [gentoo-dev] Packages up for grabs
[2021-07-23 08:40:50+0100] Sergei Trofimovich: > dev-lang/elixir > dev-lang/erlang I could co-maintain these two, feel free to add me to metadata.xml, I'll look if there is some improvments that could be done but I haven't had to scratch an itch on it yet.
[gentoo-dev] Last rites: www-servers/resin
# Conrad Kostecki (2021-07-23) # Outdated and multiple bugs open. # Other alternatives in tree available. # Removal in 30 days (2021-08-22) www-servers/resin
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> > Gentoo is about choice. if there are users that want to use deblob I > don't see why we don't have to add the option. > Errr how is *removing the firmware loader* about choice? You have all the choice of the world by just not providing any firmware to load. Removing the loader removes that choice. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On Fri, 23 Jul 2021, Alice wrote: >> GNU FSDG-compliance require not only removing non-free code but also >> to disable loading of known non-free firmware. So they actually remove code that by itself is free software. I had suspected that. (By what logic does removing an option add to the user's freedom and choice, though? :) > I also point you to some other information from the mailing list > https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html > https://www.fsfla.org/pipermail/linux-libre/2021-May/003419.html Thank you. Looks like there's no issue with the LICENSE="GPL-2" label for recent kernels then. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Package up for grabs: dev-python/imread
On Fri, Jul 23, 2021 at 07:42:48PM +0200, Dennis Lamm wrote: > Hello, > > Package up for grabs due to to no consumer in 3dprint project and other > portage package: > dev-python/imread > > It has 1 open bug and a version bump pending according to Repology. > > IMHO: this should be removed from portage. Why? If you think so, why not do it? signature.asc Description: PGP signature
[gentoo-dev] Package up for grabs: dev-python/imread
Hello, Package up for grabs due to to no consumer in 3dprint project and other portage package: dev-python/imread It has 1 open bug and a version bump pending according to Repology. IMHO: this should be removed from portage. Best regards, Dennis signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On 23 Jul 2021, at 18:11, Alessandro Barbieri > wrote: > > IIUC, it will disable CPU microcode updates. The code being removed is > entirely free (but it could load some non-free third-party microcode). > Do we really endorse that, from a security (spectre, meltdown, etc.) > point of view? > > rt-sources aren't supported by the kernel team I'm not sure it makes much of a difference to just say this, really. It doesn't help folks or stop us questioning if it's helpful to keep it (unmasked). signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> > IIUC, it will disable CPU microcode updates. The code being removed is > entirely free (but it could load some non-free third-party microcode). > Do we really endorse that, from a security (spectre, meltdown, etc.) > point of view? > rt-sources aren't supported by the kernel team >
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/24/21 1:50 AM, Alice wrote: On 7/24/21 1:45 AM, Alice wrote: On 7/24/21 1:43 AM, Alice wrote: On 7/23/21 10:49 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: On 7/23/21 9:52 PM, Ulrich Mueller wrote: My point is, when we changed the ACCEPT_LICENSE default to @FREE in 2019, there was a discussion if we could remove LICENSE="linux-firmware" from kernel packages. The conclusion was that we could do so starting with version 4.14, because in that version firmware was gone from the Linux kernel tree. Now, either our conclusion back then was right, then >=*-sources-4.14 are under a free software license, and I don't understand what would be the purpose of deblobbing. Could somebody more knowledgeable please explain it to me? Or our conclusion was wrong, which means that there are still non-free files in the kernel tree. Again, could someone explain and show me examples of such non-free files? I think this discussion is not to do be done here. if you want to discuss about deblob philosophy please open a thread about this on the FSF mailing list. Sorry for my perseverance, but it affects what we declare as LICENSE of kernel packages, so at least to some degree it _is_ our discussion. According to COPYING and Documentation/process/license-rules.rst the kernel is "provided under the terms of the GNU General Public License version 2 only". Does the FSFLA/Linux-libre project challenge that statement (and if yes, why don't they work with Linux upstream to rectify the situation)? I am still hoping that someone will explain it to me. Ulrich I still think is not a discussion to be done here Please check this for more informations: https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html The link is replying to also your question about >=*-sources-4.14 also if you have other questions please ask it to the appropriated mailing list -> linux-li...@fsfla.org AFAIK GNU FSDG-compliance require not only removing non-free code but also to disable loading of known non-free firmware. I also point you to some other information from the mailing list https://www.fsfla.org/pipermail/linux-libre/2020-August/003400.html https://www.fsfla.org/pipermail/linux-libre/2021-May/003419.html -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/24/21 1:45 AM, Alice wrote: On 7/24/21 1:43 AM, Alice wrote: On 7/23/21 10:49 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: On 7/23/21 9:52 PM, Ulrich Mueller wrote: My point is, when we changed the ACCEPT_LICENSE default to @FREE in 2019, there was a discussion if we could remove LICENSE="linux-firmware" from kernel packages. The conclusion was that we could do so starting with version 4.14, because in that version firmware was gone from the Linux kernel tree. Now, either our conclusion back then was right, then >=*-sources-4.14 are under a free software license, and I don't understand what would be the purpose of deblobbing. Could somebody more knowledgeable please explain it to me? Or our conclusion was wrong, which means that there are still non-free files in the kernel tree. Again, could someone explain and show me examples of such non-free files? I think this discussion is not to do be done here. if you want to discuss about deblob philosophy please open a thread about this on the FSF mailing list. Sorry for my perseverance, but it affects what we declare as LICENSE of kernel packages, so at least to some degree it _is_ our discussion. According to COPYING and Documentation/process/license-rules.rst the kernel is "provided under the terms of the GNU General Public License version 2 only". Does the FSFLA/Linux-libre project challenge that statement (and if yes, why don't they work with Linux upstream to rectify the situation)? I am still hoping that someone will explain it to me. Ulrich I still think is not a discussion to be done here Please check this for more informations: https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html The link is replying to also your question about >=*-sources-4.14 also if you have other questions please ask it to the appropriated mailing list -> linux-li...@fsfla.org AFAIK GNU FSDG-compliance require not only removing non-free code but also to disable loading of known non-free firmware. -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/24/21 1:43 AM, Alice wrote: On 7/23/21 10:49 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: On 7/23/21 9:52 PM, Ulrich Mueller wrote: My point is, when we changed the ACCEPT_LICENSE default to @FREE in 2019, there was a discussion if we could remove LICENSE="linux-firmware" from kernel packages. The conclusion was that we could do so starting with version 4.14, because in that version firmware was gone from the Linux kernel tree. Now, either our conclusion back then was right, then >=*-sources-4.14 are under a free software license, and I don't understand what would be the purpose of deblobbing. Could somebody more knowledgeable please explain it to me? Or our conclusion was wrong, which means that there are still non-free files in the kernel tree. Again, could someone explain and show me examples of such non-free files? I think this discussion is not to do be done here. if you want to discuss about deblob philosophy please open a thread about this on the FSF mailing list. Sorry for my perseverance, but it affects what we declare as LICENSE of kernel packages, so at least to some degree it _is_ our discussion. According to COPYING and Documentation/process/license-rules.rst the kernel is "provided under the terms of the GNU General Public License version 2 only". Does the FSFLA/Linux-libre project challenge that statement (and if yes, why don't they work with Linux upstream to rectify the situation)? I am still hoping that someone will explain it to me. Ulrich I still think is not a discussion to be done here Please check this for more informations: https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html The link is replying to also your question about >=*-sources-4.14 also if you have other questions please ask it to the appropriated mailing list -> linux-li...@fsfla.org -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/23/21 10:49 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: On 7/23/21 9:52 PM, Ulrich Mueller wrote: My point is, when we changed the ACCEPT_LICENSE default to @FREE in 2019, there was a discussion if we could remove LICENSE="linux-firmware" from kernel packages. The conclusion was that we could do so starting with version 4.14, because in that version firmware was gone from the Linux kernel tree. Now, either our conclusion back then was right, then >=*-sources-4.14 are under a free software license, and I don't understand what would be the purpose of deblobbing. Could somebody more knowledgeable please explain it to me? Or our conclusion was wrong, which means that there are still non-free files in the kernel tree. Again, could someone explain and show me examples of such non-free files? I think this discussion is not to do be done here. if you want to discuss about deblob philosophy please open a thread about this on the FSF mailing list. Sorry for my perseverance, but it affects what we declare as LICENSE of kernel packages, so at least to some degree it _is_ our discussion. According to COPYING and Documentation/process/license-rules.rst the kernel is "provided under the terms of the GNU General Public License version 2 only". Does the FSFLA/Linux-libre project challenge that statement (and if yes, why don't they work with Linux upstream to rectify the situation)? I am still hoping that someone will explain it to me. Ulrich I still think is not a discussion to be done here Please check this for more informations: https://www.fsfla.org/ikiwiki/selibre/linux-libre/index.en.html The link is replying to also your question about >=*-sources-4.14 -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On Fri, 23 Jul 2021, Alice wrote: > On 7/23/21 9:52 PM, Ulrich Mueller wrote: >> My point is, when we changed the ACCEPT_LICENSE default to @FREE in >> 2019, there was a discussion if we could remove LICENSE="linux-firmware" >> from kernel packages. The conclusion was that we could do so starting >> with version 4.14, because in that version firmware was gone from the >> Linux kernel tree. >> Now, either our conclusion back then was right, then >=*-sources-4.14 >> are under a free software license, and I don't understand what would be >> the purpose of deblobbing. Could somebody more knowledgeable please >> explain it to me? >> Or our conclusion was wrong, which means that there are still non-free >> files in the kernel tree. Again, could someone explain and show me >> examples of such non-free files? > I think this discussion is not to do be done here. > if you want to discuss about deblob philosophy please open a thread > about this on the FSF mailing list. Sorry for my perseverance, but it affects what we declare as LICENSE of kernel packages, so at least to some degree it _is_ our discussion. According to COPYING and Documentation/process/license-rules.rst the kernel is "provided under the terms of the GNU General Public License version 2 only". Does the FSFLA/Linux-libre project challenge that statement (and if yes, why don't they work with Linux upstream to rectify the situation)? I am still hoping that someone will explain it to me. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/23/21 9:52 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: Gentoo is about choice. if there are users that want to use deblob I don't see why we don't have to add the option. Sure, choice is good. My point is, when we changed the ACCEPT_LICENSE default to @FREE in 2019, there was a discussion if we could remove LICENSE="linux-firmware" from kernel packages. The conclusion was that we could do so starting with version 4.14, because in that version firmware was gone from the Linux kernel tree. Now, either our conclusion back then was right, then >=*-sources-4.14 are under a free software license, and I don't understand what would be the purpose of deblobbing. Could somebody more knowledgeable please explain it to me? Or our conclusion was wrong, which means that there are still non-free files in the kernel tree. Again, could someone explain and show me examples of such non-free files? Ulrich I think this discussion is not to do be done here. if you want to discuss about deblob philosophy please open a thread about this on the FSF mailing list. -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/23/21 9:41 PM, Michał Górny wrote: On Fri, 2021-07-23 at 20:44 +0900, Alice wrote: On 7/23/21 8:29 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: On 7/23/21 6:04 AM, Ulrich Mueller wrote: Maybe this is a stupid question, but what is USE=deblob doing these days anyway? I thought that all nonfree firmware had been removed from the kernel tree (with version 4.14) and was provided separately by the sys-kernel/linux-firmware package? There are still users that want a full libre(deblob) kernel. There are also distributions built around libre(deblob) kernel. deblob is still removing many modules from the kernel that are non-free you can see for exemple is removing things also on most recent kernels https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 I know, but I still wonder what it actually does. I've checked the first 10 or so files in their list, and they all say in their header that they are under a free software license. So does that mean the license info in these files is wrong? If not, then why is the script touching them? Also, (e.g.) this: announce MICROCODE_INTEL - "Intel microcode patch loading support" reject_firmware arch/x86/kernel/cpu/microcode/intel.c clean_blob arch/x86/kernel/cpu/microcode/intel.c clean_blob arch/x86/events/intel/core.c clean_kconfig arch/x86/Kconfig MICROCODE_INTEL clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile IIUC, it will disable CPU microcode updates. The code being removed is entirely free (but it could load some non-free third-party microcode). Do we really endorse that, from a security (spectre, meltdown, etc.) point of view? Note that the ex-factory microcode of these CPUs is already non-free, so arguably rejecting updates for it doesn't change anything. Ulrich Gentoo is about choice. if there are users that want to use deblob I don't see why we don't have to add the option. do you want to suggest any warn message that deblob option can give from a security point of view ? If deblob indeed makes things vulnerable, it must be at least masked via use.mask. sorry, I rephrase my answer. Is not deblob that makes things vulnerable, as deblob is just removing what is non-free code in the kernel, but not having CPU microcode updates it may make the system vulnerable. You should still be able to update microcode and than use a libre kernel without security issues. -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On Fri, 23 Jul 2021, Alice wrote: > Gentoo is about choice. if there are users that want to use deblob I > don't see why we don't have to add the option. Sure, choice is good. My point is, when we changed the ACCEPT_LICENSE default to @FREE in 2019, there was a discussion if we could remove LICENSE="linux-firmware" from kernel packages. The conclusion was that we could do so starting with version 4.14, because in that version firmware was gone from the Linux kernel tree. Now, either our conclusion back then was right, then >=*-sources-4.14 are under a free software license, and I don't understand what would be the purpose of deblobbing. Could somebody more knowledgeable please explain it to me? Or our conclusion was wrong, which means that there are still non-free files in the kernel tree. Again, could someone explain and show me examples of such non-free files? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On Fri, 2021-07-23 at 20:44 +0900, Alice wrote: > On 7/23/21 8:29 PM, Ulrich Mueller wrote: > > > > > > > On Fri, 23 Jul 2021, Alice wrote: > > > > > On 7/23/21 6:04 AM, Ulrich Mueller wrote: > > > > Maybe this is a stupid question, but what is USE=deblob doing these days > > > > anyway? I thought that all nonfree firmware had been removed from the > > > > kernel tree (with version 4.14) and was provided separately by the > > > > sys-kernel/linux-firmware package? > > > > > There are still users that want a full libre(deblob) kernel. > > > There are also distributions built around libre(deblob) kernel. > > > deblob is still removing many modules from the kernel that are non-free > > > you can see for exemple is removing things also on most recent kernels > > > https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 > > > > I know, but I still wonder what it actually does. I've checked the first > > 10 or so files in their list, and they all say in their header that they > > are under a free software license. So does that mean the license info in > > these files is wrong? If not, then why is the script touching them? > > > > Also, (e.g.) this: > > > > > announce MICROCODE_INTEL - "Intel microcode patch loading support" > > > reject_firmware arch/x86/kernel/cpu/microcode/intel.c > > > clean_blob arch/x86/kernel/cpu/microcode/intel.c > > > clean_blob arch/x86/events/intel/core.c > > > clean_kconfig arch/x86/Kconfig MICROCODE_INTEL > > > clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile > > > > IIUC, it will disable CPU microcode updates. The code being removed is > > entirely free (but it could load some non-free third-party microcode). > > Do we really endorse that, from a security (spectre, meltdown, etc.) > > point of view? Note that the ex-factory microcode of these CPUs is > > already non-free, so arguably rejecting updates for it doesn't change > > anything. > > > > Ulrich > > > > > Gentoo is about choice. if there are users that want to use deblob I > don't see why we don't have to add the option. > > do you want to suggest any warn message that deblob option can give from > a security point of view ? If deblob indeed makes things vulnerable, it must be at least masked via use.mask. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/23/21 8:29 PM, Ulrich Mueller wrote: On Fri, 23 Jul 2021, Alice wrote: On 7/23/21 6:04 AM, Ulrich Mueller wrote: Maybe this is a stupid question, but what is USE=deblob doing these days anyway? I thought that all nonfree firmware had been removed from the kernel tree (with version 4.14) and was provided separately by the sys-kernel/linux-firmware package? There are still users that want a full libre(deblob) kernel. There are also distributions built around libre(deblob) kernel. deblob is still removing many modules from the kernel that are non-free you can see for exemple is removing things also on most recent kernels https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 I know, but I still wonder what it actually does. I've checked the first 10 or so files in their list, and they all say in their header that they are under a free software license. So does that mean the license info in these files is wrong? If not, then why is the script touching them? Also, (e.g.) this: | announce MICROCODE_INTEL - "Intel microcode patch loading support" | reject_firmware arch/x86/kernel/cpu/microcode/intel.c | clean_blob arch/x86/kernel/cpu/microcode/intel.c | clean_blob arch/x86/events/intel/core.c | clean_kconfig arch/x86/Kconfig MICROCODE_INTEL | clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile IIUC, it will disable CPU microcode updates. The code being removed is entirely free (but it could load some non-free third-party microcode). Do we really endorse that, from a security (spectre, meltdown, etc.) point of view? Note that the ex-factory microcode of these CPUs is already non-free, so arguably rejecting updates for it doesn't change anything. Ulrich Gentoo is about choice. if there are users that want to use deblob I don't see why we don't have to add the option. do you want to suggest any warn message that deblob option can give from a security point of view ? -- Thanks, Alicef OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v2 5/5] check-reqs.eclass: Repl. I_KNOW_WHAT_I_AM_DOING w/ CHECKREQS_DONOTHING
This will break backwards compatibility for user configuration. Not sure if it merits a news item (probably not, as it would be addressed only at users who know what they're doing :) but maybe respect both variables for some transition time? signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> On Fri, 23 Jul 2021, Alice wrote: > On 7/23/21 6:04 AM, Ulrich Mueller wrote: >> Maybe this is a stupid question, but what is USE=deblob doing these days >> anyway? I thought that all nonfree firmware had been removed from the >> kernel tree (with version 4.14) and was provided separately by the >> sys-kernel/linux-firmware package? > There are still users that want a full libre(deblob) kernel. > There are also distributions built around libre(deblob) kernel. > deblob is still removing many modules from the kernel that are non-free > you can see for exemple is removing things also on most recent kernels > https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 I know, but I still wonder what it actually does. I've checked the first 10 or so files in their list, and they all say in their header that they are under a free software license. So does that mean the license info in these files is wrong? If not, then why is the script touching them? Also, (e.g.) this: | announce MICROCODE_INTEL - "Intel microcode patch loading support" | reject_firmware arch/x86/kernel/cpu/microcode/intel.c | clean_blob arch/x86/kernel/cpu/microcode/intel.c | clean_blob arch/x86/events/intel/core.c | clean_kconfig arch/x86/Kconfig MICROCODE_INTEL | clean_mk CONFIG_MICROCODE_INTEL arch/x86/kernel/cpu/microcode/Makefile IIUC, it will disable CPU microcode updates. The code being removed is entirely free (but it could load some non-free third-party microcode). Do we really endorse that, from a security (spectre, meltdown, etc.) point of view? Note that the ex-factory microcode of these CPUs is already non-free, so arguably rejecting updates for it doesn't change anything. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
On 7/23/21 6:04 AM, Ulrich Mueller wrote: Maybe this is a stupid question, but what is USE=deblob doing these days anyway? I thought that all nonfree firmware had been removed from the kernel tree (with version 4.14) and was provided separately by the sys-kernel/linux-firmware package? Also, if I grep for K_DEBLOB_AVAILABLE in sys-kernel, I see it only in rt-sources but nowhere else. Ulrich There are still users that want a full libre(deblob) kernel. There are also distributions built around libre(deblob) kernel. deblob is still removing many modules from the kernel that are non-free you can see for exemple is removing things also on most recent kernels https://www.fsfla.org/svn/fsfla/software/linux-libre/releases/tags/5.13-gnu/deblob-5.13 Alice OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] Add deblob support only for python3
Signed-off-by: Alice Ferrazzi
---
eclass/kernel-2.eclass | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index f94dd9c..e3d556f 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -604,8 +604,12 @@ if [[ ${ETYPE} == sources ]]; then
[[ -z ${K_DEBLOB_AVAILABLE} ]] && \
kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
K_DEBLOB_AVAILABLE=1
+ # deblob less than 5.10 require python 2.7
+ if kernel_is lt 5 10; then
+ K_DEBLOB_AVAILABLE=0
+ fi
if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
- PYTHON_COMPAT=( python2_7 )
+ PYTHON_COMPAT=( python3_{7..10} )
inherit python-any-r1
--
2.25.3
OpenPGP_0x1D6802D75C10FEF6.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs
The packages could use some help from a dedicated maintainer. I dropped myself from maintainer list for the following: app-text/fbpdf dev-lang/crystal dev-lang/elixir dev-lang/erlang dev-lang/jwasm dev-libs/capstone dev-util/objconv dev-util/radare2 dev-util/shards dev-lang/gforth dev-util/xxdiff net-fs/smbnetfs Most of them require low/no maintenance. But there should be room for improvements over existing state. -- Sergei
