> On 26 Jul 2021, at 16:01, Joshua Kinard 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
On 7/25/2021 19:19, Sam James wrote:
>
>
>> On 22 Jul 2021, at 16:00, Alice wrote:
>>
>>
>> Signed-off-by: Alice Ferrazzi
>> ---
>> eclass/kernel-2.eclass | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> Alice, thanks for taking the initiative to get this done and drop
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
> On 22 Jul 2021, at 16:00, Alice wrote:
>
>
> Signed-off-by: Alice Ferrazzi
> ---
> 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!
>
> d
> On 25 Jul 2021, at 23:10, Peter Stuge 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.
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 tool
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.
>
> [s
> 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.
> ge
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 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 GM
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 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 GM
On 7/25/21 1:56 AM, Michał Górny wrote:
Dnia July 24, 2021 4:52:28 PM UTC, Alice 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
wrote:
On Fri, 23 Jul 2021, Alice wrote:
GNU FSDG-complianc
Dnia July 24, 2021 4:52:28 PM UTC, Alice 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
> wrote:
> On Fri, 23 Jul 2021, Alice wrote:
>> GNU FSDG-compliance require no
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 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.
> 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 actu
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
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
>
> 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
> 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
> 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?
>
>
> 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
>
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
201
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 co
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-firmwar
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 conclu
> 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 st
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, th
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 t
> 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 remo
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 though
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)
> 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 b
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
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 [[ ${
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,
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
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_AVAILAB
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,
> b
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 rem
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.
> > >
> >
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 kerne
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 t
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
OpenPGP_0x1D6802D75C10FEF6.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
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 kern
On 7/23/21 12:02 AM, Michał Górny wrote:
use deblob
was already there I'm not adding it
OpenPGP_0x1D6802D75C10FEF6.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
On Fri, 2021-07-23 at 00:00 +0900, Alice wrote:
> Signed-off-by: Alice Ferrazzi
> ---
> 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/k
Signed-off-by: Alice Ferrazzi
---
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 @@
46 matches
Mail list logo
