Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> 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 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 signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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 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
ku...@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 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
> 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!
>
> 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
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> 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.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.
signature.asc
Description: Message signed with OpenPGP
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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
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 : mpag...@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=index
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> 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 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 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 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). You are complain against linux-libre not mainline kernel so you should ask their opinion on this topic. linux-li...@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 OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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 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). > > > > > > > > > > You are complain against linux-libre not mainline kernel so you should > > > ask their opinion on this topic. linux-li...@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
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-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-li...@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 OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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 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-li...@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
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. 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-li...@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 OpenPGP_0x1D6802D75C10FEF6.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
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.
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] [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] 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
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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
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 ? 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, 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
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. 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, 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
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. 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, 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
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
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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. 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 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
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
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/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
