Re: [gentoo-dev] [PATCH v2 5/5] check-reqs.eclass: Repl. I_KNOW_WHAT_I_AM_DOING w/ CHECKREQS_DONOTHING
On 23.07.2021 08:58, Andreas Sturmlechner wrote: > Signed-off-by: Andreas Sturmlechner > --- > eclass/check-reqs.eclass | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass > index 39e4bad1363..836dd0d4a1f 100644 > --- a/eclass/check-reqs.eclass > +++ b/eclass/check-reqs.eclass > @@ -68,6 +68,13 @@ _CHECK_REQS_ECLASS=1 > # @DESCRIPTION: > # How much space is needed in /var? Eg.: CHECKREQS_DISK_VAR=3000M > > +# @ECLASS-VARIABLE: CHECKREQS_DONOTHING > +# @USER_VARIABLE > +# @DEFAULT_UNSET > +# @DESCRIPTION: > +# Do not error out in _check-reqs_output if requirements are not met. > +# This is a user flag and should under _no circumstances_ be set in the > ebuild. ...snip... note that developer profiles set I_KNOW_WHAT_I_AM_DOING="yes" by default in profiles/targets/developer/make.defaults I don't know if anyone seriously using this profile though. -- Best regards, Georgy
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, I don't understand. Isn't it the same motion we put down just 2 months ago [1]? Or is this something new? If this isn't something new, what has changed since May [2]? To remember: Currently we have two different hashes for every distfile. If we are going to throw this data away, we should really have good reasons to do that. Like said during that council meeting, BLAKE2B and SHA512 are competing hashes. What's wrong with having a backup plan even for a very unlikely scenario, that BLAKE2B will get broken? It's not like SHA512 is requiring any additional deps which are unmaintained or something like that. SHA has even hardware acceleration support in modern systems. In addition it is even more likely that you will find SHA checksum files with upstream release tarballs than BLAKE2B files. Remember that verify-sig.eclass I criticized last year? Of course some scenarios I outlined were very unlikely and I never expected that I can run around in near future saying "I told you". But in January 2021, CVE-2021-3345 happened in libgcrypt... So again: Why should we throw the data we currently have away and put Gentoo unnecessarily at risk that we will end up without hashes because the only hash algorithm we used became broken and given that we will be unable to re-hash every file in a timely manner (remember how long it took to get a BLAKE2B hash for every file)? See also: = [1] https://bugs.gentoo.org/784710 [2] https://projects.gentoo.org/council/meeting-logs/20210509.txt -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] libffi-3.4 is on the horison (unkeyworded for now, ~arch soon)
On Sat, 17 Jul 2021 20:14:52 +0100 Sergei Trofimovich wrote: > On Thu, 8 Jul 2021 00:20:58 +0100 > Sergei Trofimovich wrote: > > > Tl;DR > > - > > > > libffi-3.4 entered ::gento without KEYWORDS today. > > After some testing it will be promoted into ~arch. > > > > libffi has two modes: > > 1. USE=-exec-static-trampoline: old (default, safe) > > 2. USE=exec-static-trampoline: new (cool, might expose latent bugs) > > Default USE=-exec-static-trampoline did not expose any new > failures over past week. > > If next week will be as calm we can unleash libffi into > ~arch next weekend (~24 July 2021). libffi-3.4.2 pushed to ~arch as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e03b5b8d5f1a5023dff4c341bb40578690471acb -- Sergei
Re: [gentoo-dev] [RFC] Removing SHA512 hash from Manifests
On 7/24/2021 11:16, Michał Górny wrote: > Hi, everyone. > > I've been asked to repost the idea of removing SHA512 hash from > Manifests, effectively limiting them to BLAKE2B. > > The 'old' set of Gentoo hashes including SHA512 went live in July 2012. > In November 2017, we have decided to remove the two other hashes and add > BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B > and SHA512 hashes. > > To all extent, this is purely a cosmetic change. The benefit from > removing the additional hash is negligible, both from space perspective > and hashing speed perspective. The benefit from keeping two hashes is > also negligible. > > Back during the 2017 discussion, Infra came to the conclusion that we're > going to keep SHA512 for a transition period, then remove it, and stay > with a single hash algorithm. In my opinion, we have kept it long > enough. > > WDYT? Are there any security benefits/consequences of keeping two/one? If no to consequences, then I don't see a problem dropping SHA512. And are we looking at BLAKE3 hash support at all for the future? I know that algo is fairly new (Jan 2020). A quick read indicates it merges a number of the BLAKE2 variants together and is faster in some areas of execution. -- 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
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] Packages up for grabs
On Sat, Jul 24, 2021 at 06:32:21PM +0100, Sergei Trofimovich wrote: > On Sat, 24 Jul 2021 19:20:16 +0200 > Petr Vaněk wrote: > > > Hi, > > > > On Fri, Jul 23, 2021 at 11:31:59PM +0200, Haelwenn (lanodan) Monnier wrote: > > > [2021-07-23 08:40:50+0100] Sergei Trofimovich: > > > > dev-lang/elixir > > > > dev-lang/erlang > > > > I am remaining dev-lang/erlang proxy-maintainer. I came to the package > > approximately in the same time like Sergei, when I did few > > contributions. Anyway, Sergei maintained the package really well and > > meantime I stopped needing this package, therefore, I was about to drop > > myself from metadata.xml past few months, but never did that. > > > > Probably question to Sergei or some other dev, should I do PR, where I > > drop myself from erlang maintainers? > > I set erlang to maintainer-needed as: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37a7f224110019b127703919594332b40a1be559 > and will unassign bugs from you. Thanks!
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] Packages up for grabs
On Sat, 24 Jul 2021 19:20:16 +0200 Petr Vaněk wrote: > Hi, > > On Fri, Jul 23, 2021 at 11:31:59PM +0200, Haelwenn (lanodan) Monnier wrote: > > [2021-07-23 08:40:50+0100] Sergei Trofimovich: > > > dev-lang/elixir > > > dev-lang/erlang > > I am remaining dev-lang/erlang proxy-maintainer. I came to the package > approximately in the same time like Sergei, when I did few > contributions. Anyway, Sergei maintained the package really well and > meantime I stopped needing this package, therefore, I was about to drop > myself from metadata.xml past few months, but never did that. > > Probably question to Sergei or some other dev, should I do PR, where I > drop myself from erlang maintainers? I set erlang to maintainer-needed as: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37a7f224110019b127703919594332b40a1be559 and will unassign bugs from you. > > I could co-maintain these two, feel free to add me to metadata.xml, > > I'll look if there is some improvments that could be done but I haven't had > > to scratch an itch on it yet. > > New erlang version 24.0.4 has been released recently. Package version > bump is nice way how to start. > > Petr > -- Sergei
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] Packages up for grabs
Hi, On Fri, Jul 23, 2021 at 11:31:59PM +0200, Haelwenn (lanodan) Monnier wrote: > [2021-07-23 08:40:50+0100] Sergei Trofimovich: > > dev-lang/elixir > > dev-lang/erlang I am remaining dev-lang/erlang proxy-maintainer. I came to the package approximately in the same time like Sergei, when I did few contributions. Anyway, Sergei maintained the package really well and meantime I stopped needing this package, therefore, I was about to drop myself from metadata.xml past few months, but never did that. Probably question to Sergei or some other dev, should I do PR, where I drop myself from erlang maintainers? > I could co-maintain these two, feel free to add me to metadata.xml, > I'll look if there is some improvments that could be done but I haven't had > to scratch an itch on it yet. New erlang version 24.0.4 has been released recently. Package version bump is nice way how to start. Petr
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
[gentoo-dev] [RFC] Removing SHA512 hash from Manifests
Hi, everyone. I've been asked to repost the idea of removing SHA512 hash from Manifests, effectively limiting them to BLAKE2B. The 'old' set of Gentoo hashes including SHA512 went live in July 2012. In November 2017, we have decided to remove the two other hashes and add BLAKE2B in their stead. Today, all Gentoo packages are using BLAKE2B and SHA512 hashes. To all extent, this is purely a cosmetic change. The benefit from removing the additional hash is negligible, both from space perspective and hashing speed perspective. The benefit from keeping two hashes is also negligible. Back during the 2017 discussion, Infra came to the conclusion that we're going to keep SHA512 for a transition period, then remove it, and stay with a single hash algorithm. In my opinion, we have kept it long enough. WDYT? -- Best regards, Michał Górny
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
