We have one ticket tagged with 'meeting', but there has been no progress in discussion or implementation, so I'm cancelling today's meeting.
We've had a glitch in the process, and various tickets which were voted and approved offline were not announced. I'll do that now here in one fell swoop, together with tickets that were approved during the last week. (I tried to filter out tickets that were announced somewhere but not closed, but I might have missed something, so please excuse any duplication.)
== Approved during one of the previous meetings
#2794 F37 Change proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib APPROVED: FESCo approves the use of bundled libraries and static libstdc++ for building Java (+5, 1, -0)
== Voted and approved in the ticket
#2809 Change proposal: Erlang 25 APPROVED (+4,0,-0)
#2807 Change proposal: Supplement of Server distributables by a KVM VM disk image APPROVED (+3,0,-0)
#2806 Change proposal: LLVM 15 APPROVED (+4,0-0)
#2805 Change proposal: RPM Macros for Build Flags APPROVED (+4,0,-0)
#2799 F38 Change proposal: SPDX License Phase 1 APPROVED (+5,0,-0)
#2798 Nonresponsive maintainer: Alfredo Deza adeza Approved by the people involved.
#2797 Change proposal: Install Using GPT on x86_64 BIOS by Default APPROVED (+4,0,-0)
#2796 Change proposal: BIOS boot.iso with GRUB2 APPROVED (+4,0,-0)
#2795 Change proposal: Python: Add -P to default shebangs APPROVED (+5,0,-0)
#2792 Nonresponsive maintainer: Ryan Brown ryansb APPROVED (+1,0,-0)
#2791 F37 Change proposal: Perl 5.36 APPROVED (+4,0,-0)
#2788 Change proposal: Strong crypto settings: phase 3, forewarning 1/2 APPROVED (+3,0,-0)
On 6/28/22 05:22, Zbigniew Jędrzejewski-Szmek wrote:
We have one ticket tagged with 'meeting', but there has been no progress in discussion or implementation, so I'm cancelling today's meeting.
Hmm. That would be https://pagure.io/fesco/issue/2804
I don't really know what else I'm supposed to do to progress that. I can't really force people to discuss it on the list and I've been waiting two weeks to discuss it at the FESCO meeting.
How come we can't talk about it at the FESCO meeting in its current form?
Dusty
On Tue, Jun 28, 2022 at 07:21:33AM -0400, Dusty Mabe wrote:
On 6/28/22 05:22, Zbigniew Jędrzejewski-Szmek wrote:
We have one ticket tagged with 'meeting', but there has been no progress in discussion or implementation, so I'm cancelling today's meeting.
Hmm. That would be https://pagure.io/fesco/issue/2804
I don't really know what else I'm supposed to do to progress that. I can't really force people to discuss it on the list and I've been waiting two weeks to discuss it at the FESCO meeting.
How come we can't talk about it at the FESCO meeting in its current form?
Hi,
I wasn't aware that you wanted to discuss it in the current form; all that I could see was the lack of activity. It's still tagged with 'meeting', so it'll be on the agenda next week.
Zbyszek
On 6/28/22 08:08, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jun 28, 2022 at 07:21:33AM -0400, Dusty Mabe wrote:
On 6/28/22 05:22, Zbigniew Jędrzejewski-Szmek wrote:
We have one ticket tagged with 'meeting', but there has been no progress in discussion or implementation, so I'm cancelling today's meeting.
Hmm. That would be https://pagure.io/fesco/issue/2804
I don't really know what else I'm supposed to do to progress that. I can't really force people to discuss it on the list and I've been waiting two weeks to discuss it at the FESCO meeting.
How come we can't talk about it at the FESCO meeting in its current form?
Hi,
I wasn't aware that you wanted to discuss it in the current form; all that I could see was the lack of activity. It's still tagged with 'meeting', so it'll be on the agenda next week.
Thanks! I also commented in the ticket to make it clear the current status.
Dusty
Zbigniew Jędrzejewski-Szmek wrote:
#2794 F37 Change proposal: Build all JDKs in Fedora against in-tree #libraries and with static stdc++lib APPROVED: FESCo approves the use of bundled libraries and static libstdc++ for building Java (+5, 1, -0)
WTF, why???
The feedback in the mailing list thread was overwhelmingly negative. We have brought up several strong reasons why doing this is a horribly bad idea. Why have those arguments and the mailing list consensus not been considered by FESCo?
Kevin Kofler
On Tue, Jun 28, 2022 at 02:07:54PM +0200, Kevin Kofler via devel wrote:
Zbigniew Jędrzejewski-Szmek wrote:
#2794 F37 Change proposal: Build all JDKs in Fedora against in-tree #libraries and with static stdc++lib APPROVED: FESCo approves the use of bundled libraries and static libstdc++ for building Java (+5, 1, -0)
WTF, why???
The feedback in the mailing list thread was overwhelmingly negative. We have brought up several strong reasons why doing this is a horribly bad idea. Why have those arguments and the mailing list consensus not been considered by FESCo?
The whole proposal consists of a few parts. The part that was voted on was the first part. Various people opposed the whole proposal, but it was the later parts that raised the stronger opposition. The first part is something that is really within maintainer discretion, and has no impact on other packages. If the maintainer thinks that this will make it easier for them to deliver the package in this form, I don't think FESCo should block it. At least that's my motivation; for the whole discussion see the logs [*]. It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Zbyszek
[*] I wanted to link to meetbot here, but I can't get the new version to cooperate.
On Tue, Jun 28, 2022 at 02:24:17PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jun 28, 2022 at 02:07:54PM +0200, Kevin Kofler via devel wrote:
Zbigniew Jędrzejewski-Szmek wrote:
#2794 F37 Change proposal: Build all JDKs in Fedora against in-tree #libraries and with static stdc++lib APPROVED: FESCo approves the use of bundled libraries and static libstdc++ for building Java (+5, 1, -0)
WTF, why???
The feedback in the mailing list thread was overwhelmingly negative. We have brought up several strong reasons why doing this is a horribly bad idea. Why have those arguments and the mailing list consensus not been considered by FESCo?
The whole proposal consists of a few parts. The part that was voted on was the first part. Various people opposed the whole proposal, but it was the later parts that raised the stronger opposition. The first part is something that is really within maintainer discretion, and has no impact on other packages. If the maintainer thinks that this will make it easier for them to deliver the package in this form, I don't think FESCo should block it. At least that's my motivation; for the whole discussion see the logs [*]. It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Zbyszek
[*] I wanted to link to meetbot here, but I can't get the new version to cooperate.
Here it is
https://meetbot.fedoraproject.org/fedora-meeting/2022-05-31/fesco.2022-05-31... https://meetbot.fedoraproject.org/fedora-meeting/2022-05-31/fesco.2022-05-31...
With regards, Daniel
Zbigniew Jędrzejewski-Szmek wrote:
The whole proposal consists of a few parts. The part that was voted on was the first part. Various people opposed the whole proposal, but it was the later parts that raised the stronger opposition.
I and others have also objected to the entire concept of bundling the libraries where not absolutely necessary, with arguments given.
The first part is something that is really within maintainer discretion,
It is true that the rules on bundling have become less and less strict over time. However, there is still a SHOULD-grade requirement that system libraries should be used where reasonably possible, to which the Change is in blatant contradiction.
and has no impact on other packages.
Well, it has a potential impact at least on all packages depending on the JDK/JRE. Also, security issues in the bundled libraries can cause the user's whole Fedora installation to be compromised.
If the maintainer thinks that this will make it easier for them to deliver the package in this form, I don't think FESCo should block it.
At that point, we gain very little from having the JDK/JRE in Fedora at all, as opposed to a third-party RPM repository. Why bother shipping a Fedora package at all if it does not follow Fedora best practices (SHOULD guidelines) and in particular does not use Fedora-packaged libraries?
It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Yet, the outcome is diametrically opposed to the mailing list consensus.
Kevin Kofler
On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote:
Zbigniew Jędrzejewski-Szmek wrote:
The whole proposal consists of a few parts. The part that was voted on was the first part. Various people opposed the whole proposal, but it was the later parts that raised the stronger opposition.
I and others have also objected to the entire concept of bundling the libraries where not absolutely necessary, with arguments given.
The first part is something that is really within maintainer discretion,
It is true that the rules on bundling have become less and less strict over time. However, there is still a SHOULD-grade requirement that system libraries should be used where reasonably possible, to which the Change is in blatant contradiction.
As you say, it's "SHOULD", and the maintainers argue that it'll be much easier for them to do it in this way. You keep using strong words like "blatant" where they are blatanly inappropriate.
and has no impact on other packages.
Well, it has a potential impact at least on all packages depending on the JDK/JRE. Also, security issues in the bundled libraries can cause the user's whole Fedora installation to be compromised.
If the maintainer thinks that this will make it easier for them to deliver the package in this form, I don't think FESCo should block it.
At that point, we gain very little from having the JDK/JRE in Fedora at all, as opposed to a third-party RPM repository. Why bother shipping a Fedora package at all if it does not follow Fedora best practices (SHOULD guidelines) and in particular does not use Fedora-packaged libraries?
It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Yet, the outcome is diametrically opposed to the mailing list consensus.
I don't think it makes sense to restart the discussion here. I disagree that there was (any) consensus on the mailing list. If you feel that it's better to use a non-Fedora JRE, that's certainly possible, please just do that if you want to. Personally, I see a lot of value in having Java packaged for Fedora, and use it for my stuff.
Zbyszek
Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek:
On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote:
It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Yet, the outcome is diametrically opposed to the mailing list consensus.
I don't think it makes sense to restart the discussion here. I disagree
And I disagree with you.
This decision is such kind of harmful to Fedora, this decision should be reverted. This decision communicates the attitude of FESCO not caring about security, maintainablity and further related topics.
Personally, I see a lot of value in having Java packaged for Fedora, and use it for my stuff.
So do I, but this doesn't invalidate the the thought of "bundling" and "static linkage" being a prime security risk.
Ralf
On Tue, Jun 28, 2022 at 03:05:32PM +0200, Ralf Corsépius wrote:
Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek:
On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote:
It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Yet, the outcome is diametrically opposed to the mailing list consensus.
I don't think it makes sense to restart the discussion here. I disagree
And I disagree with you.
OK.
This decision is such kind of harmful to Fedora, this decision should be reverted. This decision communicates the attitude of FESCO not caring about security, maintainablity and further related topics.
Personally, I see a lot of value in having Java packaged for Fedora, and use it for my stuff.
So do I, but this doesn't invalidate the the thought of "bundling" and "static linkage" being a prime security risk.
We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again.
(Pfff, people are so angry about this… I would prefer to unbundle anything too. But sometimes a big upstream is just too big to fight on every front.)
Zbyszek
On 28/06/2022 15:29, Zbigniew Jędrzejewski-Szmek wrote:
We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again.
Upstream doesn't care because their tests fails on modern libraries versions.
Also, this only the first part of their proposal. The other part is to let them build the OpenJDK once and then ship prebuilt binaries to all supported Fedora releases.
On 6/28/22 09:35, Vitaly Zaitsev via devel wrote:
On 28/06/2022 15:29, Zbigniew Jędrzejewski-Szmek wrote:
We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again.
Upstream doesn't care because their tests fails on modern libraries versions.
If the TCK fails with modern library versions, that is a problem with the TCK or with OpenJDK and needs to be fixed. Fedora should not ship outdated libraries because an upstream test suite is too restrictive.
The main problem here is that the TCK is closed-source. If it were open to contributions, problems like this could be identified and fixed. Given the current situation, though, the best solution would be for Red Hat to create an alternate test suite that is free software.
On Tue, Jun 28 2022 at 03:29:33 PM +0200, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
We can treat this as an experiment. The hope is that Java upstream is big enough to be able to release updates for any CVEs in a timely manner, and that the RHEL/Fedora maintainers are able to provide updates in a timely manner. If it turns out this is not the case, we can unbundle again.
I hope the Java maintainers ensure the RPM has proper Provides: bundled(foo) for each bundled library, including bundled dependencies of bundled libraries, so that Product Security can track CVEs. The FESCo approval to bundle should be contingent on adherence to this existing Fedora policy.
Michael
On Tue, Jun 28, 2022 at 03:05:32PM +0200, Ralf Corsépius wrote:
Am 28.06.22 um 14:51 schrieb Zbigniew Jędrzejewski-Szmek:
On Tue, Jun 28, 2022 at 02:41:42PM +0200, Kevin Kofler via devel wrote:
It certainly is not true that the feedback was not considered by FESCo: there was a long discussion on IRC, and FESCo members also participated in the mailing list thread.
Yet, the outcome is diametrically opposed to the mailing list consensus.
I don't think it makes sense to restart the discussion here. I disagree
And I disagree with you.
This decision is such kind of harmful to Fedora, this decision should be reverted. This decision communicates the attitude of FESCO not caring about security, maintainablity and further related topics.
I don't see that attitude in reading the IRC logs of the meeting, and I think that characterization is rather unfair to those involved.
Personally, I see a lot of value in having Java packaged for Fedora, and use it for my stuff.
So do I, but this doesn't invalidate the the thought of "bundling" and "static linkage" being a prime security risk.
I see people aware of the downsides of bundling and static linking, but they're not the sole factors to be considered. Our packaging guidelines on the topic of bundling are more nuanced and this is what FESCO has considered when evaluating this feature from what I can read in the meeting minutes.
IOW, if people think the outcome is wrong, then the problem really lies with the agreed packaging guidelines wrt to bundling, not with FESCOs decision which looks to be in compliance with the stated guidelines.
With regards, Daniel
Zbigniew Jędrzejewski-Szmek wrote:
I don't think it makes sense to restart the discussion here. I disagree that there was (any) consensus on the mailing list. If you feel that it's better to use a non-Fedora JRE, that's certainly possible, please just do that if you want to. Personally, I see a lot of value in having Java for Fedora, and use it for my stuff.
But the thing is, I am left with only the options of using an all-bundled JRE from Fedora or using an all-bundled JRE from elsewhere. I hope you can see how this is not a real choice.
I have been using the Fedora-packaged Java all this time, and I indeed also see a lot of value in it. But to me, this also implies that it is packaged to Fedora standards and uses Fedora system libraries. Stopping to do so destroys much of the value of having a Fedora package at all.
So, sure, I can just use Java from elsewhere, but that is exactly what I do not want. What I do want is being taken away from me.
Kevin Kofler
On Tue, 28 Jun 2022 at 09:37, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
Zbigniew Jędrzejewski-Szmek wrote:
I don't think it makes sense to restart the discussion here. I disagree that there was (any) consensus on the mailing list. If you feel that it's better to use a non-Fedora JRE, that's certainly possible, please just do that if you want to. Personally, I see a lot of value in having Java for Fedora, and use it for my stuff.
But the thing is, I am left with only the options of using an all-bundled JRE from Fedora or using an all-bundled JRE from elsewhere. I hope you can see how this is not a real choice.
I have been using the Fedora-packaged Java all this time, and I indeed also see a lot of value in it. But to me, this also implies that it is packaged to Fedora standards and uses Fedora system libraries. Stopping to do so destroys much of the value of having a Fedora package at all.
So, sure, I can just use Java from elsewhere, but that is exactly what I do not want. What I do want is being taken away from me.
Since I do not see this decision changing, it is probably time for people negatively affected by this change to set up a COPR or some other build system which builds the packages as they were previously. It might help to see what kind of problems it has and if there are solutions which were not seen before.
On 28/06/2022 15:52, Stephen Smoogen wrote:
Since I do not see this decision changing, it is probably time for people negatively affected by this change to set up a COPR or some other build system which builds the packages as they were previously.
I think it will be better to introduce the coffee-named-language-XX packages and build them for the main Fedora repository without running any Oracle's tests and certifications.
On Tue, 28 Jun 2022 at 10:18, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
On 28/06/2022 15:52, Stephen Smoogen wrote:
Since I do not see this decision changing, it is probably time for people negatively affected by this change to set up a COPR or some other build system which builds the packages as they were previously.
I think it will be better to introduce the coffee-named-language-XX packages and build them for the main Fedora repository without running any Oracle's tests and certifications.
Someone outside of the current team has to sign up to do that work either inside of Fedora or outside.
On Tue, Jun 28, 2022 at 03:35:35PM +0200, Kevin Kofler via devel wrote:
Zbigniew Jędrzejewski-Szmek wrote:
I don't think it makes sense to restart the discussion here. I disagree that there was (any) consensus on the mailing list. If you feel that it's better to use a non-Fedora JRE, that's certainly possible, please just do that if you want to. Personally, I see a lot of value in having Java for Fedora, and use it for my stuff.
But the thing is, I am left with only the options of using an all-bundled JRE from Fedora or using an all-bundled JRE from elsewhere. I hope you can see how this is not a real choice.
That's part of what makes it hard to discuss things with you: the proposal _explicitly_ says that only some libraries will be bundled. (There's a separate section about this!) So it's not "all-bundled" but "some of the low-level libs are bundled".
I have been using the Fedora-packaged Java all this time, and I indeed also see a lot of value in it. But to me, this also implies that it is packaged to Fedora standards and uses Fedora system libraries. Stopping to do so destroys much of the value of having a Fedora package at all.
The package is still build by Fedora maitainers, from controlled sources, on Fedora infra. The only difference is that some libraries are in a version that the upstream project has blessed. The upstream project is big and has an extensive test suite and cares about vulnerabilities as much as we do. You describe it as if the bundling would radically change things, but I think that in this case the impact for users will not be noticable.
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
That's part of what makes it hard to discuss things with you: the proposal _explicitly_ says that only some libraries will be bundled. (There's a separate section about this!) So it's not "all-bundled" but "some of the low-level libs are bundled".
I am sorry, but I have to think that you are the one weasel-wording. The proposal says in its subject that it wants to "Build all JDKs in Fedora against in-tree libraries". Not "some in-tree libraries", just (unqualified) "in-tree libraries", which in correct English defaults to meaning "all in- tree libraries that are available". (This may actually be a grammar error from the submitters, in which case that should have been fixed before voting on the proposal.)
In the full text, the proposal includes the following list:
--with-zlib="bundled" --with-freetype="bundled" --with-libjpeg="bundled" --with-giflib="bundled" --withlibpng="bundled" --with-lcms="bundled" --with-harfbuzz="bundled"
It does not state whether these are all the libraries that upstream bundles in the tree or, if not, which ones will not be bundled. (So I cannot tell from the proposal's text whether the "all-bundled" term I used is an exaggeration or not.) It also does not state why these libraries in particular were selected to be bundled.
I also do not see these libraries as being particularly "low-level", though anyway, IMHO, the lower-level a library, the worse an idea it is to bundle it. (E.g., trying to bundle glibc would be a horrible idea, but that is not what is being proposed here anyway. So I am not sure why you chose the word "low-level".)
In addition to the libraries that will be bundled, there is also the switch to statically linking the system libstdc++, which is IMHO an entirely different change, and for which I do not see any possible benefit at all, since we will be using the exact same version of libstdc++ as before, just without the benefits of shared libraries.
The package is still build by Fedora maitainers, from controlled sources, on Fedora infra. The only difference is that some libraries are in a version that the upstream project has blessed.
Instead of the version that the distribution has blessed, that is known to work together with all the other software in the distribution, and that does not require extra space for Java only.
The upstream project is big and has an extensive test suite and cares about vulnerabilities as much as we do.
But introducing a middleman (who needs to upgrade the bundled library and issue a security update for Java that we need to package, instead of directly packaging the upgraded library) necessarily increases the response time to security vulnerabilities.
You describe it as if the bundling would radically change things, but I think that in this case the impact for users will not be noticable.
The mailing list discussion had pointed out at least one user-visible issue, related to fontconfig support.
And the increased disk space and RAM requirements will definitely be noticeable.
Kevin Kofler
On Tue, 2022-06-28 at 22:00 +0200, Kevin Kofler via devel wrote:
Zbigniew Jędrzejewski-Szmek wrote:
That's part of what makes it hard to discuss things with you: the proposal _explicitly_ says that only some libraries will be bundled. (There's a separate section about this!) So it's not "all-bundled" but "some of the low-level libs are bundled".
I am sorry, but I have to think that you are the one weasel-wording. The proposal says in its subject that it wants to "Build all JDKs in Fedora against in-tree libraries". Not "some in-tree libraries", just (unqualified) "in-tree libraries", which in correct English defaults to meaning "all in- tree libraries that are available".
It really doesn't. It's ambiguous. Without more specific language it could mean either.
One thing I forgot in my previous reply to this post:
Zbigniew Jędrzejewski-Szmek wrote:
As you say, it's "SHOULD", and the maintainers argue that it'll be much easier for them to do it in this way.
I believe that the rationale for doing the opposite of a SHOULD ought to be much stronger than "it'll be much easier for them to do it in this way". The easy way is often not the right way, which is why we have packaging guidelines at all.
In the particular case of bundling libraries, there are a few valid reasons for it that I can see, e.g.: * The bundled library is patched, and the project does not compile or has unfixable bugs with the upstream version of the library. * The bundled library is older or newer than the system version, and the project does not compile or has unfixable bugs with the version of the library packaged in Fedora, and providing a compatibility library is impractical (e.g., because the application is the only one needing that particular version of the library). * The bundled library has no canonical upstream version at all. * The upstream build system does not support building against the system version, and it is impractically hard to patch it downstream to do so. (But the packager should at least try to get a person more familiar with the build system to have a try at it.)
None of these appear to be satisfied for OpenJDK, considering that there are configure switches (that will be toggled by the Change), and that OpenJDK works now with the system versions of the libraries. Hence, I see the use of bundled libraries as an unnecessary shortcut that degrades packaging quality for no good reason other than one person or team's convenience.
Kevin Kofler
#2799 F38 Change proposal: SPDX License Phase 1 APPROVED (+5,0,-0)
Do I understand it correctly that we can change License tags in our spec files to SPDX syntax right now?
Or should we wait until updating https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses to SPDX identifiers?
-- Petr
On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote:
#2799 F38 Change proposal: SPDX License Phase 1 APPROVED (+5,0,-0)
Do I understand it correctly that we can change License tags in our spec files to SPDX syntax right now?
Or should we wait until updating https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses to SPDX identifiers?
That's my understanding. The plan is to not treat the wiki as the authoritative source, but instead to generate a Docs page from a table in fedora-license-data.rpm. If the license is listed in /usr/share/fedora-license-data/licenses/fedora-licenses.json as approved:yes, then this should be enough. The plan is to rework the wiki too, but that'll likely take more time.
Zbyszek
On Wed, 29 Jun 2022, 09:48 Zbigniew Jędrzejewski-Szmek, zbyszek@in.waw.pl wrote:
On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote:
#2799 F38 Change proposal: SPDX License Phase 1 APPROVED (+5,0,-0)
Do I understand it correctly that we can change License tags in our spec
files
to SPDX syntax right now?
Or should we wait until updating https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses to SPDX identifiers?
That's my understanding. The plan is to not treat the wiki as the authoritative source, but instead to generate a Docs page from a table in fedora-license-data.rpm. If the license is listed in /usr/share/fedora-license-data/licenses/fedora-licenses.json as approved:yes, then this should be enough. The plan is to rework the wiki too, but that'll likely take more time.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Weren't there a proposal for a macro allowing to use both Spottags and SPDX so we could merge --ff-only to the old branches? Not being able to do that is a PITA.
Have a great day everyone!
Robert-André
V Wed, Jun 29, 2022 at 10:17:48AM +0200, Bob Mauchin napsal(a):
Weren't there a proposal for a macro allowing to use both Spottags and SPDX so we could merge --ff-only to the old branches? Not being able to do that is a PITA.
SPDX is allowed in all Fedora branches https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1#Can_we_use_SPDX_expressions_in_older_Fedora_branches.3F.
-- Petr
As I read it, the Change text strongly implies that package maintainers should wait for FPC to approve updated Licensing guidelines. That work seems to be in progress here: https://pagure.io/packaging-committee/pull-request/1142
– Ben
On Wed, Jun 29, 2022, at 3:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jun 29, 2022 at 08:54:37AM +0200, Petr Pisar wrote:
#2799 F38 Change proposal: SPDX License Phase 1 APPROVED (+5,0,-0)
Do I understand it correctly that we can change License tags in our spec files to SPDX syntax right now?
Or should we wait until updating https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses to SPDX identifiers?
That's my understanding. The plan is to not treat the wiki as the authoritative source, but instead to generate a Docs page from a table in fedora-license-data.rpm. If the license is listed in /usr/share/fedora-license-data/licenses/fedora-licenses.json as approved:yes, then this should be enough. The plan is to rework the wiki too, but that'll likely take more time.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dne 29. 06. 22 v 9:47 Zbigniew Jędrzejewski-Szmek napsal(a):
Or should we wait until updating https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses to SPDX identifiers?
That's my understanding. The plan is to not treat the wiki as the authoritative source, but instead to generate a Docs page from a table in fedora-license-data.rpm. If the license is listed in /usr/share/fedora-license-data/licenses/fedora-licenses.json as approved:yes, then this should be enough. The plan is to rework the wiki too, but that'll likely take more time.
+1
Technically you can do it now. It is approved. However there is no/little guidance for now. We aim to have this done by next branching event (August).
So you either know what you are doing, or you wait till the documentation is done. Otherwise you are in risk to re-doing that later.
Miroslav
devel@lists.stg.fedoraproject.org
-
Adam Williamson -
Ben Beasley -
Bob Mauchin -
Daniel P. Berrangé -
Demi Marie Obenour -
Dusty Mabe -
Kevin Kofler -
Michael Catanzaro -
Miroslav Suchý -
Petr Pisar -
Ralf Corsépius -
Stephen Smoogen -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek