4:22 a.m.
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)
6:21 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
7:07 a.m.
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
7:08 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
7:24 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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.
7:34 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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...
https://meetbot.fedoraproject.org/fedora-meeting/2022-05-31/fesco.2022-05...
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
7:41 a.m.
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
7:51 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
7:51 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
8:05 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
8:29 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
8:35 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:35 a.m.
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
8:52 a.m.
On Tue, 28 Jun 2022 at 09:37, Kevin Kofler via devel <
devel(a)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.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
8:56 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
On Tue, Jun 28 2022 at 03:29:33 PM +0200, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)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
8:59 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:17 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:21 a.m.
On Tue, 28 Jun 2022 at 10:18, Vitaly Zaitsev via devel <
devel(a)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.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:51 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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
11:51 a.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
3 p.m.
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
4:50 p.m.
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
5:07 p.m.
New subject: Tuesday's FESCo Meeting (2022-06-28) is cancelled. Many
announcements
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.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
1:54 a.m.
New subject: Can we start changing License to SPDX now?
#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
2:47 a.m.
New subject: Can we start changing License to SPDX now?
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
3:17 a.m.
New subject: Can we start changing License to SPDX now?
On Wed, 29 Jun 2022, 09:48 Zbigniew Jędrzejewski-Szmek, <zbyszek(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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é
5:30 a.m.
New subject: Can we start changing License to SPDX now?
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_S...;.
-- Petr
10:23 a.m.
New subject: Can we start changing License to SPDX now?
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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
5:50 a.m.
New subject: Can we start changing License to SPDX now?
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
664
days inactive
667
days old
28 comments
14 participants
participants (14)
-
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