[gentoo-dev] [PATCH] Add deblob support only for python3

[gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 1538 bytes --]


Signed-off-by: Alice Ferrazzi <alicef@gentoo.org>
---
  eclass/kernel-2.eclass | 13 +++++++++----
  1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
index f94dd9c..05f8161 100644
--- a/eclass/kernel-2.eclass
+++ b/eclass/kernel-2.eclass
@@ -605,7 +605,7 @@ if [[ ${ETYPE} == sources ]]; then
                                 kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
                                         K_DEBLOB_AVAILABLE=1
                 if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
-                       PYTHON_COMPAT=( python2_7 )
+                       PYTHON_COMPAT=( python3_{7..10} )

                         inherit python-any-r1

@@ -1489,9 +1489,14 @@ kernel-2_src_compile() {
         [[ ${ETYPE} == headers ]] && compile_headers

         if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
-               einfo ">>> Running deblob script ..."
-               python_setup
-               sh "${T}/${DEBLOB_A}" --force || die "Deblob script 
failed to run!!!"
+               # deblob less than 5.10 require python 2.7
+               if kernel_is lt 5 10; then
+                       ewarn "we don't support deblob for kernel less 
then 5.10"
+               else
+                       einfo ">>> Running deblob script ..."
+                       python_setup
+                       sh "${T}/${DEBLOB_A}" --force || die "Deblob 
script failed to run!!!"
+               fi
         fi
  }

-- 
2.25.3

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Michał Górny]

On Fri, 2021-07-23 at 00:00 +0900, Alice wrote:
> Signed-off-by: Alice Ferrazzi <alicef@gentoo.org>
> ---
>   eclass/kernel-2.eclass | 13 +++++++++----
>   1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index f94dd9c..05f8161 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -605,7 +605,7 @@ if [[ ${ETYPE} == sources ]]; then
>                                  kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
>                                          K_DEBLOB_AVAILABLE=1
>                  if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
> -                       PYTHON_COMPAT=( python2_7 )
> +                       PYTHON_COMPAT=( python3_{7..10} )
> 
>                          inherit python-any-r1
> 
> @@ -1489,9 +1489,14 @@ kernel-2_src_compile() {
>          [[ ${ETYPE} == headers ]] && compile_headers
> 
>          if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
> -               einfo ">>> Running deblob script ..."
> -               python_setup
> -               sh "${T}/${DEBLOB_A}" --force || die "Deblob script 
> failed to run!!!"
> +               # deblob less than 5.10 require python 2.7
> +               if kernel_is lt 5 10; then
> +                       ewarn "we don't support deblob for kernel less 
> then 5.10"

Why are you adding the USE flag for these kernels then?  It's misleading
at best.

> +               else
> +                       einfo ">>> Running deblob script ..."
> +                       python_setup
> +                       sh "${T}/${DEBLOB_A}" --force || die "Deblob 
> script failed to run!!!"
> +               fi
>          fi
>   }
> 

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 95 bytes --]

On 7/23/21 12:02 AM, Michał Górny wrote:
> use deblob
was already there I'm not adding it

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 360 bytes --]

On 7/23/21 12:02 AM, Michał Górny wrote:
> Why are you adding the USE flag for these kernels then?  It's misleading
> at best.

ah I just understand what are you asking.
that's right the USE flag on such kernel should be removed,
but I think is something that we can do in a next release of such kernel 
and after removing this part from the eclass.

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 155 bytes --]

On 7/23/21 12:21 AM, Alice wrote:
> On 7/23/21 12:02 AM, Michał Górny wrote:
>> use deblob
> was already there I'm not adding it
please ignore this

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Michał Górny]

On Fri, 2021-07-23 at 00:24 +0900, Alice wrote:
> On 7/23/21 12:02 AM, Michał Górny wrote:
> > Why are you adding the USE flag for these kernels then?  It's misleading
> > at best.
> 
> ah I just understand what are you asking.
> that's right the USE flag on such kernel should be removed,
> but I think is something that we can do in a next release of such kernel 
> and after removing this part from the eclass.

Why not just unset the var in eclass?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 733 bytes --]

On 7/23/21 12:43 AM, Michał Górny wrote:
> On Fri, 2021-07-23 at 00:24 +0900, Alice wrote:
>> On 7/23/21 12:02 AM, Michał Górny wrote:
>>> Why are you adding the USE flag for these kernels then?  It's misleading
>>> at best.
>>
>> ah I just understand what are you asking.
>> that's right the USE flag on such kernel should be removed,
>> but I think is something that we can do in a next release of such kernel
>> and after removing this part from the eclass.
> 
> Why not just unset the var in eclass?
> 

Because deblob works with python3 for kernel that are more recent than 
5.4 excluded. so I'm deprecating old kernel deblob that still use python 
2.7 and keep it for most recent one that can use python3.

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Michał Górny]

On Fri, 2021-07-23 at 00:47 +0900, Alice wrote:
> On 7/23/21 12:43 AM, Michał Górny wrote:
> > On Fri, 2021-07-23 at 00:24 +0900, Alice wrote:
> > > On 7/23/21 12:02 AM, Michał Górny wrote:
> > > > Why are you adding the USE flag for these kernels then?  It's misleading
> > > > at best.
> > > 
> > > ah I just understand what are you asking.
> > > that's right the USE flag on such kernel should be removed,
> > > but I think is something that we can do in a next release of such kernel
> > > and after removing this part from the eclass.
> > 
> > Why not just unset the var in eclass?
> > 
> 
> Because deblob works with python3 for kernel that are more recent than 
> 5.4 excluded. so I'm deprecating old kernel deblob that still use python 
> 2.7 and keep it for most recent one that can use python3.

I'm saying that instead of printing ewarn for old kernels you should
just disable the whole logic in eclass for old kernels.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 339 bytes --]

On 7/23/21 2:29 AM, Michał Górny wrote:
> I'm saying that instead of printing ewarn for old kernels you should
> just disable the whole logic in eclass for old kernels.
Disabling everything by K_DEBLOB_AVAILABLE = 0 is what I did at first, 
but I still prefer to warn the user until old ebuild get removed of the 
deblob USE flag.

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[David Seifert]

On Fri, 2021-07-23 at 02:56 +0900, Alice wrote:
> On 7/23/21 2:29 AM, Michał Górny wrote:
> > I'm saying that instead of printing ewarn for old kernels you should
> > just disable the whole logic in eclass for old kernels.
> Disabling everything by K_DEBLOB_AVAILABLE = 0 is what I did at first,
> but I still prefer to warn the user until old ebuild get removed of
> the 
> deblob USE flag.

This is confusing and not how we do things in Gentoo normally.

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 578 bytes --]

On 7/23/21 3:08 AM, David Seifert wrote:
> On Fri, 2021-07-23 at 02:56 +0900, Alice wrote:
>> On 7/23/21 2:29 AM, Michał Górny wrote:
>>> I'm saying that instead of printing ewarn for old kernels you should
>>> just disable the whole logic in eclass for old kernels.
>> Disabling everything by K_DEBLOB_AVAILABLE = 0 is what I did at first,
>> but I still prefer to warn the user until old ebuild get removed of
>> the
>> deblob USE flag.
> 
> This is confusing and not how we do things in Gentoo normally.
> 
> 

what do you suggest as the Gentoo normal way ?

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[David Seifert]

On Fri, 2021-07-23 at 03:23 +0900, Alice wrote:
> On 7/23/21 3:08 AM, David Seifert wrote:
> > On Fri, 2021-07-23 at 02:56 +0900, Alice wrote:
> > > On 7/23/21 2:29 AM, Michał Górny wrote:
> > > > I'm saying that instead of printing ewarn for old kernels you
> > > > should
> > > > just disable the whole logic in eclass for old kernels.
> > > Disabling everything by K_DEBLOB_AVAILABLE = 0 is what I did at
> > > first,
> > > but I still prefer to warn the user until old ebuild get removed
> > > of
> > > the
> > > deblob USE flag.
> > 
> > This is confusing and not how we do things in Gentoo normally.
> > 
> > 
> 
> what do you suggest as the Gentoo normal way ?

Just unset the var in the eclass as mgorny suggested?

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

[gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 967 bytes --]


Signed-off-by: Alice Ferrazzi <alicef@gentoo.org>
---
  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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 801 bytes --]

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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2122 bytes --]

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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Michał Górny]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2709 bytes --]

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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 1191 bytes --]

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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 1870 bytes --]

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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2066 bytes --]

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-libre@fsfla.org

-- 
Thanks,
Alicef

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2288 bytes --]

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-libre@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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2602 bytes --]

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-libre@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

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alessandro Barbieri]

[-- Attachment #1: Type: text/plain, Size: 289 bytes --]

>
> 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

>

[-- Attachment #2: Type: text/html, Size: 693 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]



> On 23 Jul 2021, at 18:11, Alessandro Barbieri <lssndrbarbieri@gmail.com> 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).

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

>>>>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 450 bytes --]

> 
> 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
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[alicef]

On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller <ulm@gentoo.org> 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.

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[alicef]

On July 24, 2021 3:41:22 AM GMT+09:00, "Andreas K. Huettel" <dilfridge@gentoo.org> 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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

>>>>> On Sat, 24 Jul 2021, alicef  wrote:

> On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller <ulm@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2406 bytes --]

On 7/24/21 3:30 PM, Ulrich Mueller wrote:
>>>>>> On Sat, 24 Jul 2021, alicef  wrote:
> 
>> On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller <ulm@gentoo.org> 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).
> 

You are complain against linux-libre not mainline kernel so you should 
ask their opinion on this topic. linux-libre@fsfla.org

My modest opinion on the topic is:
As far that is free software and there are users that use deblob, I 
don't see any reason on why we should not support this and give them the 
choice. Gentoo is about choice.


-- 
Thanks,
Alicef

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Michał Górny]

Dnia July 24, 2021 4:52:28 PM UTC, Alice <alicef@gentoo.org> napisał(a):
>On 7/24/21 3:30 PM, Ulrich Mueller wrote:
>>>>>>> On Sat, 24 Jul 2021, alicef  wrote:
>> 
>>> On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller
><ulm@gentoo.org> 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).
>> 
>
>You are complain against linux-libre not mainline kernel so you should 
>ask their opinion on this topic. linux-libre@fsfla.org
>
>My modest opinion on the topic is:
>As far that is free software and there are users that use deblob, I 
>don't see any reason on why we should not support this and give them
>the 
>choice. Gentoo is about choice.

Then why does none of the supported kernels offer that choice?


--
Best regards, 
Michał Górny

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 2770 bytes --]

On 7/25/21 1:56 AM, Michał Górny wrote:
> Dnia July 24, 2021 4:52:28 PM UTC, Alice <alicef@gentoo.org> napisał(a):
>> On 7/24/21 3:30 PM, Ulrich Mueller wrote:
>>>>>>>> On Sat, 24 Jul 2021, alicef  wrote:
>>>
>>>> On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller
>> <ulm@gentoo.org> 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).
>>>
>>
>> You are complain against linux-libre not mainline kernel so you should
>> ask their opinion on this topic. linux-libre@fsfla.org
>>
>> My modest opinion on the topic is:
>> As far that is free software and there are users that use deblob, I
>> don't see any reason on why we should not support this and give them
>> the
>> choice. Gentoo is about choice.
> 
> Then why does none of the supported kernels offer that choice?
> 

why they shouldn't ?

-- 
Thanks,
Alicef

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Michał Górny]

On Sun, 2021-07-25 at 01:57 +0900, Alice wrote:
> On 7/25/21 1:56 AM, Michał Górny wrote:
> > Dnia July 24, 2021 4:52:28 PM UTC, Alice <alicef@gentoo.org> napisał(a):
> > > On 7/24/21 3:30 PM, Ulrich Mueller wrote:
> > > > > > > > > On Sat, 24 Jul 2021, alicef  wrote:
> > > > 
> > > > > On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller
> > > <ulm@gentoo.org> 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).
> > > > 
> > > 
> > > You are complain against linux-libre not mainline kernel so you should
> > > ask their opinion on this topic. linux-libre@fsfla.org
> > > 
> > > My modest opinion on the topic is:
> > > As far that is free software and there are users that use deblob, I
> > > don't see any reason on why we should not support this and give them
> > > the
> > > choice. Gentoo is about choice.
> > 
> > Then why does none of the supported kernels offer that choice?
> > 
> 
> why they shouldn't ?
> 

That's my question.  Apparently deblob is only supported for rt-sources.
Last I heard, only gentoo-sources are officially supported.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Alice]

[-- Attachment #1.1.1: Type: text/plain, Size: 3248 bytes --]

On 7/25/21 2:28 AM, Michał Górny wrote:
> On Sun, 2021-07-25 at 01:57 +0900, Alice wrote:
>> On 7/25/21 1:56 AM, Michał Górny wrote:
>>> Dnia July 24, 2021 4:52:28 PM UTC, Alice <alicef@gentoo.org> napisał(a):
>>>> On 7/24/21 3:30 PM, Ulrich Mueller wrote:
>>>>>>>>>> On Sat, 24 Jul 2021, alicef  wrote:
>>>>>
>>>>>> On July 24, 2021 3:21:56 AM GMT+09:00, Ulrich Mueller
>>>> <ulm@gentoo.org> 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).
>>>>>
>>>>
>>>> You are complain against linux-libre not mainline kernel so you should
>>>> ask their opinion on this topic. linux-libre@fsfla.org
>>>>
>>>> My modest opinion on the topic is:
>>>> As far that is free software and there are users that use deblob, I
>>>> don't see any reason on why we should not support this and give them
>>>> the
>>>> choice. Gentoo is about choice.
>>>
>>> Then why does none of the supported kernels offer that choice?
>>>
>>
>> why they shouldn't ?
>>
> 
> That's my question.  Apparently deblob is only supported for rt-sources.
> Last I heard, only gentoo-sources are officially supported.
> 

deblob is only supported for rt-sources.
gentoo-sources currently doesn't have deblob.

-- 
Thanks,
Alicef

[-- Attachment #1.1.2: OpenPGP_0x1D6802D75C10FEF6.asc --]
[-- Type: application/pgp-keys, Size: 0 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

> >>>> My modest opinion on the topic is:
> >>>> As far that is free software and there are users that use deblob, I
> >>>> don't see any reason on why we should not support this and give them
> >>>> the
> >>>> choice. Gentoo is about choice.

[snip]

> deblob is only supported for rt-sources.
> gentoo-sources currently doesn't have deblob.


So deblob is highly important for choice, you say.
Also, the kernel sources that everyone uses don't offer deblob.

Somehow this discussion is getting ridiculous.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Mike]

On 7/24/21 2:15 PM, Andreas K. Huettel wrote:
>>>>>> My modest opinion on the topic is:
>>>>>> As far that is free software and there are users that use deblob, I
>>>>>> don't see any reason on why we should not support this and give them
>>>>>> the
>>>>>> choice. Gentoo is about choice.
> 
> [snip]
> 
>> deblob is only supported for rt-sources.
>> gentoo-sources currently doesn't have deblob.
> 
> 
> So deblob is highly important for choice, you say.
> Also, the kernel sources that everyone uses don't offer deblob.
> 
> Somehow this discussion is getting ridiculous.
> 

1.	There is nothing wrong with a maintainer of a specific kernel 
package to add support for deblob. They're the maintainer and it's their choice to
support that or not.

2. I removed deblob from gentoo-sources because it was annoying at the time
(I hear the script has changed now), and rather than make it less annoying, I decided 
my time was better spent on other things. 

3. Something does not have to be in gentoo-sources for it to have relevance. 
I think that's obvious and should not be an argument to include something or not.



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead 
E-Mail     : mpagano@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Peter Stuge]

Alice wrote:
> +++ b/eclass/kernel-2.eclass
..
> -                       PYTHON_COMPAT=( python2_7 )
> +                       PYTHON_COMPAT=( python3_{7..10} )

From

https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html

it seems that it may be possible to need only very simple tools for the
deblob program(s). I think that would be a worthwhile improvement and it
would probably also simplify integration of deblob not only in Gentoo.

That said, if python2_7 is not a thing in Gentoo anymore then the patch
makes sense to me.

I think the discussion on merits concluded well - kernel maintainers who
want can support it. Everyone who considers it pointless can ignore it.
All good.


Kind regards

//Peter

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]



> On 25 Jul 2021, at 23:10, Peter Stuge <peter@stuge.se> wrote:
> 
> Alice wrote:
>> +++ b/eclass/kernel-2.eclass
> ..
>> -                       PYTHON_COMPAT=( python2_7 )
>> +                       PYTHON_COMPAT=( python3_{7..10} )
> 
> From
> 
> https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
> 
> it seems that it may be possible to need only very simple tools for the
> deblob program(s). I think that would be a worthwhile improvement and it
> would probably also simplify integration of deblob not only in Gentoo.

Instead of linking to a huge release announcement, could you summarise it?

Better yet, if there's nothing to add, email threads tend to be easier to read with fewer interventions.

This one has got rather noisy in particular.

> 
> That said, if python2_7 is not a thing in Gentoo anymore then the patch
> makes sense to me.
> 

It's not been a thing for quite some time other than build-time only dependencies
which we're only keeping for (now older) Chromium and Firefox/SpiderMonkey.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 2060 bytes --]



> On 22 Jul 2021, at 16:00, Alice <alicef@gentoo.org> wrote:
> 
> 
> Signed-off-by: Alice Ferrazzi <alicef@gentoo.org>
> ---
> eclass/kernel-2.eclass | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)

Alice, thanks for taking the initiative to get this done and drop Python 2.7 here.

It's much appreciated!

> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index f94dd9c..05f8161 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -605,7 +605,7 @@ if [[ ${ETYPE} == sources ]]; then
>                                kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
>                                        K_DEBLOB_AVAILABLE=1
>                if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
> -                       PYTHON_COMPAT=( python2_7 )
> +                       PYTHON_COMPAT=( python3_{7..10} )

I think others already said this, but Python 3.7 is a noop (eclasses ignore it), so just drop it.

> 
>                        inherit python-any-r1
> 
> @@ -1489,9 +1489,14 @@ kernel-2_src_compile() {
>        [[ ${ETYPE} == headers ]] && compile_headers
> 
>        if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
> -               einfo ">>> Running deblob script ..."
> -               python_setup
> -               sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed to run!!!"
> +               # deblob less than 5.10 require python 2.7
> +               if kernel_is lt 5 10; then
> +                       ewarn "we don't support deblob for kernel less then 5.10"
> +               else
> +                       einfo ">>> Running deblob script ..."
> +                       python_setup
> +                       sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed to run!!!"
> +               fi
>        fi
> }
> 

I'd still prefer it if we just didn't provide the USE flag on irrelevant kernels (it's too confusing) but if you plan on removing this
message at some point, I guess we can keep it?

best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Peter Stuge]

Sam James wrote:
> > https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
> > 
> > it seems that it may be possible to need only very simple tools for the
> > deblob program(s).
> 
> Instead of linking to a huge release announcement, could you summarise it?

Fair enough - though the relevant part is the short commentary preceding
the perhaps mechanical release announcement.

The deblob program(s) previously used sed and awk instead of python
or perl and seem to have switched more because of performance than
because of any features in either python or perl. A quick look into
the source code seems to confirm that there's no strong tie to Python.


//Peter

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Joshua Kinard]

On 7/25/2021 19:19, Sam James wrote:
> 
> 
>> On 22 Jul 2021, at 16:00, Alice <alicef@gentoo.org> wrote:
>>
>>
>> Signed-off-by: Alice Ferrazzi <alicef@gentoo.org>
>> ---
>> eclass/kernel-2.eclass | 13 +++++++++----
>> 1 file changed, 9 insertions(+), 4 deletions(-)
> 
> Alice, thanks for taking the initiative to get this done and drop Python 2.7 here.
> 
> It's much appreciated!
> 
>>
>> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
>> index f94dd9c..05f8161 100644
>> --- a/eclass/kernel-2.eclass
>> +++ b/eclass/kernel-2.eclass
>> @@ -605,7 +605,7 @@ if [[ ${ETYPE} == sources ]]; then
>>                                kernel_is le 2 6 ${DEBLOB_MAX_VERSION} && \
>>                                        K_DEBLOB_AVAILABLE=1
>>                if [[ ${K_DEBLOB_AVAILABLE} == 1 ]]; then
>> -                       PYTHON_COMPAT=( python2_7 )
>> +                       PYTHON_COMPAT=( python3_{7..10} )
> 
> I think others already said this, but Python 3.7 is a noop (eclasses ignore it), so just drop it.
> 
>>
>>                        inherit python-any-r1
>>
>> @@ -1489,9 +1489,14 @@ kernel-2_src_compile() {
>>        [[ ${ETYPE} == headers ]] && compile_headers
>>
>>        if [[ ${K_DEBLOB_AVAILABLE} == 1 ]] && use deblob; then
>> -               einfo ">>> Running deblob script ..."
>> -               python_setup
>> -               sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed to run!!!"
>> +               # deblob less than 5.10 require python 2.7
>> +               if kernel_is lt 5 10; then
>> +                       ewarn "we don't support deblob for kernel less then 5.10"
>> +               else
>> +                       einfo ">>> Running deblob script ..."
>> +                       python_setup
>> +                       sh "${T}/${DEBLOB_A}" --force || die "Deblob script failed to run!!!"
>> +               fi
>>        fi
>> }
>>
> 
> I'd still prefer it if we just didn't provide the USE flag on irrelevant kernels (it's too confusing) but if you plan on removing this
> message at some point, I guess we can keep it?

I think the message text for the ewarn case could be a bit better.  How
about instead of:

    "we don't support deblob for kernel less then 5.10"

Something like:

    "Deblob support requires a Linux kernel >=5.10"

Is used instead?

Also, the die message text can drop the triple exclamation marks.  One
exclamation mark is enough.

And someone correct me if wrong, as I am reading this thread late, but
deblobbing is disabled by setting K_DEBLOB_AVAILABLE=0 in a kernel-2
inheritor ebuild, right?  mips-sources can't support deblobbing, as several
of the SGI machines (IP27, IP30) are literally unbootable off of internal
drive bays if specific Qlogic firmware blobs don't get included in the
kernel image.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [PATCH] Add deblob support only for python3

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]



> On 26 Jul 2021, at 16:01, Joshua Kinard <kumba@gentoo.org> wrote:
> 
>>> [snip]
>> 
>> I'd still prefer it if we just didn't provide the USE flag on irrelevant kernels (it's too confusing) but if you plan on removing this
>> message at some point, I guess we can keep it?
> 
> I think the message text for the ewarn case could be a bit better.  How
> about instead of:
> 
>    "we don't support deblob for kernel less then 5.10"
> 
> Something like:
> 
>    "Deblob support requires a Linux kernel >=5.10"
> 
> Is used instead?

Sounds good to me!

best,
sam

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]