F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
8:29 a.m.
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This is initial step to move JDKs to be more like other JDKs, to build
proper transferable images, and to lower certification burden of each
binary. Long storyshort, first step in:
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
This first step will move, one by one, individual JDKs in F37 to be
built `--with-stdc++lib=static` and against in-tree (bundeld)
libraries: `--with-zlib="bundled" --with-freetype="bundled"
--with-libjpeg="bundled" --with-giflib="bundled"
--withlibpng="bundled" --with-lcms="bundled"
--with-harfbuzz="bundled" `
We already made a heavy testing of the behavior, and user should not
face negative experience. I'm not sure if this is
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
for whole picture
Please see
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JD...
for this particular step. I would rather keep the details in the main
page then here.
== Feedback ==
According to short investigations, there are already precedents, where
certification is a reason to build once, certificate, and repack.
According to developers, the non-portbale JDK is causing upredicted
behavior different from other JDK vendors
According to JDK packagers and testers, there is to much JDKs now, and
the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fe...
is the only way out
== Benefit to Fedora ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation
for whole picture.
This particular proposal's main benefit will be that Fedora's JDKs as
packed in RPMs will again start to resemble upstream JDKs and other
vendors build, and some platform specific issues disappear, while JDKs
remain same in view of system integration and user experience
== Scope ==
* Proposal owners: push improved version of
https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#re...
to all JDKs - one by one from latest, over 17 to 11 and 8. Once
settled down in F37 the backport to F36 is expected.
* Other developers: really, nothing. If there will be unexpected
impact to other developers, the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may
need rework
* Release engineering: N/A [https://pagure.io/releng/issues #Releng
issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The compatibility and upgrade path should remain completely smooth.
== How To Test ==
Install system JDK (java-17-openjdk) and ru your favorite application
or development. No regression should be noted.
== User Experience ==
Because of in-tree libraries, minimal image or font rendering
differences canbe spotted after very detailed investigations -
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_ef...
- still, no of th e
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_i...
should be hit by this proposal.
== Dependencies ==
No dependent packages should notice the change.
== Contingency Plan ==
* Contingency mechanism: Revert the patches and rework
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
* Contingency deadline: before f37 release
* Blocks release? Unless the java-stack will become completely borked then no.
== Documentation ==
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
8:33 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 09:29, Ben Cotton wrote:
We already made a heavy testing of the behavior, and user should not
face negative experience. I'm not sure if this is
Might be a copy-paste error there, the last sentence is incomplete.
--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
8:42 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 10/05/2022 15:29, Ben Cotton wrote:
This is initial step to move JDKs to be more like other JDKs, to
build
proper transferable images, and to lower certification burden of each
binary.
Strongly -1. Bundled versions are always outdated and may be even
vulnerable.
--with-zlib="bundled" --with-freetype="bundled"
--with-libjpeg="bundled" --with-giflib="bundled"
--withlibpng="bundled" --with-lcms="bundled"
--with-harfbuzz="bundled" `
Using bundled freetype, fontconfig and harfbuzz will result in ugly
fonts (without system configuration support, including subpixel
rendering, hinting, etc).
Applications linking against libraries SHOULD link against shared
libraries not static versions.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
12:36 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
* Vitaly Zaitsev via devel:
On 10/05/2022 15:29, Ben Cotton wrote:
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary.
Strongly -1. Bundled versions are always outdated and may be even
vulnerable.
And upstream only incorporates security fixes once per quarter, so the
recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a
downstream-only patched for it applied. There was some confusion
whether this bug only happened with Z_FIXED, but there's been another
reproducer now. Given the lack of public discussion (following upstream
policy), it's not clear whether this has been taken into account.
Once the vulnerability scanners get better, we should really avoid
copies of the demangler code because of its occasional vulnerabilities.
They won't be exploitable in OpenJDK (at all), but scanners will
eventually flag the presence of that code, still requiring security
updates.
If demangling can be disabled (so that mangled names show up in crash
dumps), I think eliminating the remaining libstdc++ dependencies is a
few week's work, mostly involving documenting interposable functions on
the GCC side.
Thanks,
Florian
3:08 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
On Tue, 10 May 2022 19:36:22 +0200
Florian Weimer <fweimer(a)redhat.com> wrote:
* Vitaly Zaitsev via devel:
> On 10/05/2022 15:29, Ben Cotton wrote:
>> This is initial step to move JDKs to be more like other JDKs, to
>> build proper transferable images, and to lower certification
>> burden of each binary.
>
> Strongly -1. Bundled versions are always outdated and may be even
> vulnerable.
And upstream only incorporates security fixes once per quarter, so the
recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a
downstream-only patched for it applied. There was some confusion
whether this bug only happened with Z_FIXED, but there's been another
reproducer now. Given the lack of public discussion (following
upstream policy), it's not clear whether this has been taken into
account.
In this case upstream might actually get there first because this CVE
is not yet fixed in Fedora
(https://bugzilla.redhat.com/show_bug.cgi?id=2068066). Of course, this
is unusual.
Paul.
8:53 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 19:36 Tue 10 May , Florian Weimer wrote:
* Vitaly Zaitsev via devel:
> On 10/05/2022 15:29, Ben Cotton wrote:
>> This is initial step to move JDKs to be more like other JDKs, to build
>> proper transferable images, and to lower certification burden of each
>> binary.
>
> Strongly -1. Bundled versions are always outdated and may be even
> vulnerable.
And upstream only incorporates security fixes once per quarter, so the
recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a
downstream-only patched for it applied. There was some confusion
whether this bug only happened with Z_FIXED, but there's been another
reproducer now. Given the lack of public discussion (following upstream
policy), it's not clear whether this has been taken into account.
It's not quite as simple as bundled is always worse.
It really depends a lot on how well the package is maintained and how
quickly security updates for the system package make it into Fedora.
Yes, if a security fix comes out right after a quarterly security
update to OpenJDK has happened, it could be at least three months
until the version in the JDK is patched. How problematic this is
depends on how exploitable the issue is from JDK code.
Having being involved in these security updates for over fifteen
years, I've seen cases both where the fix is already in the system
version and also where it is not (and may be some time before it is,
depending on the seriousness of the bug). This includes cases where
the bug is discovered at the JDK level and so the issue can be
resolved there before it is in the upstream project.
One thing I can say is that determining whether the system version
is fixed or not adds additional work to the process, and also
causes confusion when Oracle are reporting a CVE as fix in the
JDK update and we are not (because it's already fixed in the
system library)
Also, my sympathy for this argument is a little short, given the
number of times we've released OpenJDK updates for Fedora on unembargo
date, only for them to sit waiting for karma. Recently, we even had
one security update usurped by a later regression fix because it still
hadn't gone stable in over a week. Let's not pretend that Fedora has
every security issue fixed as soon as the unembargo lifts.
Once the vulnerability scanners get better, we should really avoid
copies of the demangler code because of its occasional vulnerabilities.
They won't be exploitable in OpenJDK (at all), but scanners will
eventually flag the presence of that code, still requiring security
updates.
That seems to assume that the JDK retains the old version of the
code. The in-tree libraries do get updates as part of quarterly
security updates. As I say, there are even times when this happens
when the issue is not yet public.
If a scanner is flagging bundle code in the JDK as being vulnerable,
then that's something we can raise in the OpenJDK vulnerability group
to get the code fixed in OpenJDK. That's actually better from a
"upstream first" position as we are then improving all builds of
OpenJDK, rather than taking a position of it not being our problem
because the system version is fixed.
Thanks,
--
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
10:08 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Mon, May 16, 2022 at 9:54 PM Andrew Hughes <gnu.andrew(a)redhat.com> wrote:
On 19:36 Tue 10 May , Florian Weimer wrote:
> * Vitaly Zaitsev via devel:
>
> > On 10/05/2022 15:29, Ben Cotton wrote:
> >> This is initial step to move JDKs to be more like other JDKs, to build
> >> proper transferable images, and to lower certification burden of each
> >> binary.
> >
> > Strongly -1. Bundled versions are always outdated and may be even
> > vulnerable.
>
> And upstream only incorporates security fixes once per quarter, so the
> recent zlib bug (CVE-2018-25032) would have to be reintroduced, or a
> downstream-only patched for it applied. There was some confusion
> whether this bug only happened with Z_FIXED, but there's been another
> reproducer now. Given the lack of public discussion (following upstream
> policy), it's not clear whether this has been taken into account.
>
It's not quite as simple as bundled is always worse.
It really depends a lot on how well the package is maintained and how
quickly security updates for the system package make it into Fedora.
Yes, if a security fix comes out right after a quarterly security
update to OpenJDK has happened, it could be at least three months
until the version in the JDK is patched. How problematic this is
depends on how exploitable the issue is from JDK code.
Having being involved in these security updates for over fifteen
years, I've seen cases both where the fix is already in the system
version and also where it is not (and may be some time before it is,
depending on the seriousness of the bug). This includes cases where
the bug is discovered at the JDK level and so the issue can be
resolved there before it is in the upstream project.
One thing I can say is that determining whether the system version
is fixed or not adds additional work to the process, and also
causes confusion when Oracle are reporting a CVE as fix in the
JDK update and we are not (because it's already fixed in the
system library)
Also, my sympathy for this argument is a little short, given the
number of times we've released OpenJDK updates for Fedora on unembargo
date, only for them to sit waiting for karma. Recently, we even had
one security update usurped by a later regression fix because it still
hadn't gone stable in over a week. Let's not pretend that Fedora has
every security issue fixed as soon as the unembargo lifts.
I don't know if you're going to gain any sympathy for stating this,
considering how badly the Fedora Java ecosystem has fallen apart in
the span of five years. Both in the wider Red Hat world and within
Fedora itself, Java has received less and less love, to the point that
it has been brutally starved. It has gotten so bad that Debian (!!!)
beat us to newer Java and we had to *beg* for this to be fixed. So
much for Features and First, eh?
Once, long ago, we were the leader in the Linux Java ecosystem, but
ironically as Red Hat's influence in OpenJDK grew, investment in
Fedora dwindled.
We've also lost most of our Java based apps to even test OpenJDK with.
What the heck are we supposed to do to test and give karma? We lost
Eclipse last year, and we lost IntellJ and NetBeans several years ago.
Azureus was removed a year ago, too. The larger Java community stopped
encouraging the development of desktop apps more than seven years ago,
and with it all the things people would normally be able to use with
it are gone. Red Hat encourages web apps because it aligns well with
the JBoss middleware stack that they still sell subscriptions for, and
even *those* aren't in Fedora.
The Red Hat Java team has done *nothing* that I can see to advocate
for Java in the larger Fedora community, nor have they tried to appeal
to people to make applications like Microsoft does with .NET. Even
with all the poison a decade ago heaped at Mono and .NET, we actually
still have a better shot of reviving interest in C# on Linux because
the .NET ecosystem still tries to make native applications and
cross-platform ones at that. GtkSharp is amazingly somehow not
completely dead, and there have been efforts to plug it into .NET
MAUI. If that happened, tons of .NET applications would be easily
available to Linux users.
So tell me, if we actually *did* this, what are *you* planning to do
to make open source Java more attractive? What are you going to do to
help drive growth in developing the next generation of Java
applications so that the ecosystem doesn't fall apart even further
than it already has? What are you going to do to make Java in Fedora
successful?
> Once the vulnerability scanners get better, we should really
avoid
> copies of the demangler code because of its occasional vulnerabilities.
> They won't be exploitable in OpenJDK (at all), but scanners will
> eventually flag the presence of that code, still requiring security
> updates.
That seems to assume that the JDK retains the old version of the
code. The in-tree libraries do get updates as part of quarterly
security updates. As I say, there are even times when this happens
when the issue is not yet public.
If a scanner is flagging bundle code in the JDK as being vulnerable,
then that's something we can raise in the OpenJDK vulnerability group
to get the code fixed in OpenJDK. That's actually better from a
"upstream first" position as we are then improving all builds of
OpenJDK, rather than taking a position of it not being our problem
because the system version is fixed.
Sorry, no. Bundling libraries upstream was always a bad idea, a legacy
of the bad old days where code dependency managers didn't exist. Even
for C/C++ code, dependency managers exist. Notably Conan is quite
popular. If we wanted to, we could map Conan dependencies to RPM
packaged content.
I don't know how any of this Change benefits Fedora, when it reeks of
reducing investment even further. From where I stand, I see no
"Benefit to Fedora".
--
真実はいつも一つ！/ Always, there's only one truth!
6:38 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 17/05/2022 05:08, Neal Gompa wrote:
Even
for C/C++ code, dependency managers exist. Notably Conan is quite
popular. If we wanted to, we could map Conan dependencies to RPM
packaged content.
Btw, we now have a packaged version of vcpkg[1] on Fedora 35+.
[1]: https://src.fedoraproject.org/rpms/vcpkg
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:33 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Mon, 16 May 2022 at 23:18, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, May 16, 2022 at 9:54 PM Andrew Hughes
<gnu.andrew(a)redhat.com>
wrote:
>
> On 19:36 Tue 10 May , Florian Weimer wrote:
> > * Vitaly Zaitsev via devel:
> >
> > > On 10/05/2022 15:29, Ben Cotton wrote:
> Also, my sympathy for this argument is a little short, given the
> number of times we've released OpenJDK updates for Fedora on unembargo
> date, only for them to sit waiting for karma. Recently, we even had
> one security update usurped by a later regression fix because it still
> hadn't gone stable in over a week. Let's not pretend that Fedora has
> every security issue fixed as soon as the unembargo lifts.
>
I don't know if you're going to gain any sympathy for stating this,
considering how badly the Fedora Java ecosystem has fallen apart in
the span of five years. Both in the wider Red Hat world and within
Fedora itself, Java has received less and less love, to the point that
it has been brutally starved. It has gotten so bad that Debian (!!!)
beat us to newer Java and we had to *beg* for this to be fixed. So
much for Features and First, eh?
Once, long ago, we were the leader in the Linux Java ecosystem, but
ironically as Red Hat's influence in OpenJDK grew, investment in
Fedora dwindled.
I am pretty sure that was a very very tiny period of time of 2 to 3 years.
Over the 25 years I have worked on RHL and then Fedora.. we have nearly
always been a far follower on Java. For a good period of time from
2004->2012, there were regular flaming mailing threads about "Java in
Fedora sucks", "Java only wants exceptions to standard policies",
"Fedora's
java is broken on X". It took a LOT of work to get Java into a 'working
state' but it is like 'welding' plastic to steel.. You constantly find
yourself remelting parts or adding more glue until what you have is more
'stuff which keeps them stuck together' versus 'tools which work'.
The investment when it was done back then was done by volunteers (they
might have been @redhat.com but they weren't doing it as their main tasks)
who frankly one after another burned out over the toxic reaction they got.
[That said it was a two way street of toxic reactions...] For the last 7
years, there has been a dwindling number of people who basically got mostly
'this is bull$hit, fix it the way I want it' reactions from Fedora
community members. For some reason, various people in the community have
assumed that Red Hat pays people to work on Fedora primarily and Java
secondary which was never the case.
So tell me, if we actually *did* this, what are *you* planning to do
to make open source Java more attractive? What are you going to do to
Why is this their job to do that? They, like N% of Fedora packagers, are
volunteers who just have @redhat.com addresses. They have limited time,
resources and ability to keep the packages in Fedora. They, like many other
volunteers, are finding that 'free' time is getting smaller, and are trying
to come up with ways to keep it in.
If other people want it to be promoted and attractive, they need to do the
marketing work to do so. The alternatives I am seeing here are:
1. This is done this way (if the build system will even allow that without
more horrible hacks).
2. OpenJDK is taken out and a different external repo is given a nod like
the ones we do for flatpak and such.
3. OpenJDK is taken out, and the various new people step up and put in a
IcedTea replacement that 'mostly' works and deals with the trademark
issues, and the marketing to get it seen and used.
Staying the same is not an option and is off the table.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
8:02 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 8:33 AM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
On Mon, 16 May 2022 at 23:18, Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Mon, May 16, 2022 at 9:54 PM Andrew Hughes <gnu.andrew(a)redhat.com> wrote:
> >
> > On 19:36 Tue 10 May , Florian Weimer wrote:
> > > * Vitaly Zaitsev via devel:
> > >
> > > > On 10/05/2022 15:29, Ben Cotton wrote:
>
> > Also, my sympathy for this argument is a little short, given the
> > number of times we've released OpenJDK updates for Fedora on unembargo
> > date, only for them to sit waiting for karma. Recently, we even had
> > one security update usurped by a later regression fix because it still
> > hadn't gone stable in over a week. Let's not pretend that Fedora has
> > every security issue fixed as soon as the unembargo lifts.
> >
>
> I don't know if you're going to gain any sympathy for stating this,
> considering how badly the Fedora Java ecosystem has fallen apart in
> the span of five years. Both in the wider Red Hat world and within
> Fedora itself, Java has received less and less love, to the point that
> it has been brutally starved. It has gotten so bad that Debian (!!!)
> beat us to newer Java and we had to *beg* for this to be fixed. So
> much for Features and First, eh?
>
> Once, long ago, we were the leader in the Linux Java ecosystem, but
> ironically as Red Hat's influence in OpenJDK grew, investment in
> Fedora dwindled.
I am pretty sure that was a very very tiny period of time of 2 to 3 years. Over the 25
years I have worked on RHL and then Fedora.. we have nearly always been a far follower on
Java. For a good period of time from 2004->2012, there were regular flaming mailing
threads about "Java in Fedora sucks", "Java only wants exceptions to
standard policies", "Fedora's java is broken on X". It took a LOT of
work to get Java into a 'working state' but it is like 'welding' plastic
to steel.. You constantly find yourself remelting parts or adding more glue until what you
have is more 'stuff which keeps them stuck together' versus 'tools which
work'.
The investment when it was done back then was done by volunteers (they might have been
@redhat.com but they weren't doing it as their main tasks) who frankly one after
another burned out over the toxic reaction they got. [That said it was a two way street of
toxic reactions...] For the last 7 years, there has been a dwindling number of people who
basically got mostly 'this is bull$hit, fix it the way I want it' reactions from
Fedora community members. For some reason, various people in the community have assumed
that Red Hat pays people to work on Fedora primarily and Java secondary which was never
the case.
>
> So tell me, if we actually *did* this, what are *you* planning to do
> to make open source Java more attractive? What are you going to do to
Why is this their job to do that? They, like N% of Fedora packagers, are volunteers who
just have @redhat.com addresses. They have limited time, resources and ability to keep the
packages in Fedora. They, like many other volunteers, are finding that 'free' time
is getting smaller, and are trying to come up with ways to keep it in.
If other people want it to be promoted and attractive, they need to do the marketing work
to do so.
My expectation is based on how both Python and .NET have done this:
The Python team made "Fedora Loves Python": https://fedoralovespython.org/
The .NET team maintains the Developer page for .NET and has a domain
redirect to it: https://fedoraloves.net/
These groups also do advocacy for Fedora in their upstreams and the
broader communities. I don't know why you or anyone else wouldn't
expect the packagers of OpenJDK to do advocacy for Fedora to the
OpenJDK project and the broader Java community? Maybe they wouldn't be
alone, but if they're not part of it, then the efforts fail.
The alternatives I am seeing here are:
1. This is done this way (if the build system will even allow that without more horrible
hacks).
2. OpenJDK is taken out and a different external repo is given a nod like the ones we do
for flatpak and such.
3. OpenJDK is taken out, and the various new people step up and put in a IcedTea
replacement that 'mostly' works and deals with the trademark issues, and the
marketing to get it seen and used.
Staying the same is not an option and is off the table.
It is technically possible for OpenJDK to be built the way this Change
proposes. It would require two extra packaging changes:
1. A "noautobuild" file needs to be added to opt out of mass builds and such
2. The DistTag would need to be dropped (no "%{?dist}" in Release)
After that, OpenJDK would follow the same mechanism the EFI stuff
does, where we go to "single build, multiple tags". Koji by default
automatically inherits builds from the previous tag, so when new tags
are made, the latest build in the previous tag is picked up
automatically. As long as updates for OpenJDK are built against a
particular tag, then the only thing left to do would be to tag in
manually to newer Fedora release candidate tags so Bodhi can pick it
up. Most of the workflow kinks should have been worked out with shim
years ago.
However, doing this has some terrible consequences: You cannot
participate in mass builds. You cannot benefit from newer libraries.
You will not benefit from system improvements. Finally, you are
effectively isolated from the distribution.
But what this Change discussion tells me is that there's something
seriously wrong with the Java TCK. I want to know if any discussion
upstream has been had about streamlining the TCK to make it easier in
the first place.
--
真実はいつも一つ！/ Always, there's only one truth!
4:51 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 17.05.2022 um 15:02 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
On Tue, May 17, 2022 at 8:33 AM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
>
>
>>
>> So tell me, if we actually *did* this, what are *you* planning to do
>> to make open source Java more attractive? What are you going to do to
>
>
> Why is this their job to do that? They, like N% of Fedora packagers, are volunteers
who just have @redhat.com addresses. They have limited time, resources and ability to keep
the packages in Fedora. They, like many other volunteers, are finding that 'free'
time is getting smaller, and are trying to come up with ways to keep it in.
>
> If other people want it to be promoted and attractive, they need to do the marketing
work to do so.
My expectation is based on how both Python and .NET have done this:
The Python team made "Fedora Loves Python": https://fedoralovespython.org/
The .NET team maintains the Developer page for .NET and has a domain
redirect to it: https://fedoraloves.net/
These groups also do advocacy for Fedora in their upstreams and the
broader communities. I don't know why you or anyone else wouldn't
expect the packagers of OpenJDK to do advocacy for Fedora to the
OpenJDK project and the broader Java community? Maybe they wouldn't be
alone, but if they're not part of it, then the efforts fail.
These are all excellent ideas. Do you also have an idea on how to get this going (except
"it would have to be someone ....“)? The current packagers are booked up maintaining
the software, I suspect. Additional people are needed, and cooperation between the
"old" and the "new" has to build up.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
5:36 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 8:33 AM Stephen Smoogen
<ssmoogen(a)redhat.com> wrote:
My expectation is based on how both Python and .NET have done this:
The Python team made "Fedora Loves Python": https://fedoralovespython.org/
The .NET team maintains the Developer page for .NET and has a domain
redirect to it: https://fedoraloves.net/
These groups also do advocacy for Fedora in their upstreams and the
broader communities. I don't know why you or anyone else wouldn't
expect the packagers of OpenJDK to do advocacy for Fedora to the
OpenJDK project and the broader Java community? Maybe they wouldn't be
alone, but if they're not part of it, then the efforts fail.
This is nice example. And I agree that we shoudl do it. Issue is to findthe time. This
proposal will help OpenJDK people to find a time.
Second may be that ant, maven and jigsaw still have issues wit proper integration to help
both distribution and outside ecosystem. Pythond defintely did better job.
As for .NET - you can not compare. The pure fact that you can dnf install it says nothing
about what lies beneath and how to properly toolchain it or package applications for it. I
had seenboth .NET packagin internals, and tried to pack and .NET application and it was
terrible. But yes, presentation is good.
It is technically possible for OpenJDK to be built the way this Change
proposes. It would require two extra packaging changes:
1. A "noautobuild" file needs to be added to opt out of mass builds and such
2. The DistTag would need to be dropped (no "%{?dist}" in Release)
While it will be build in the scope of
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic then no, it will
remain %{?dist} based.
If whole https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs happens, then
yes, the portbale base wil be ?dist-less, but the integration wrapper will remain
?dist-full
After that, OpenJDK would follow the same mechanism the EFI stuff
does, where we go to "single build, multiple tags". Koji by default
shmi is probably best example you can provide. And our reason is quite same - we have to
certificate bianry. Fact that the owners of certificationallows us to do it on our own
just simplify it, but do nto lower burden.
automatically inherits builds from the previous tag, so when new
tags
are made, the latest build in the previous tag is picked up
automatically. As long as updates for OpenJDK are built against a
particular tag, then the only thing left to do would be to tag in
manually to newer Fedora release candidate tags so Bodhi can pick it
up. Most of the workflow kinks should have been worked out with shim
years ago.
However, doing this has some terrible consequences: You cannot
participate in mass builds. You cannot benefit from newer libraries.
You will not benefit from system improvements. Finally, you are
effectively isolated from the distribution.
I'm aware, and as stated many times, we are not happy from it. But we can not find
better way.
But what this Change discussion tells me is that there's something
seriously wrong with the Java TCK. I want to know if any discussion
upstream has been had about streamlining the TCK to make it easier in
the first place.
Hundreds:( No reasonable resoult ever come out.
9:23 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
Hi,
"jiri vanek" <jvanek(a)redhat.com> writes:
As for .NET - you can not compare.
That's completely fair. One (OpenJDK) has been open source in various
forms for 15 years. The other has been (re-designed and made) open
source for around 5 years now. 10 years is an eternity, and has both
positive and negative implications for the late-comer.
So there are definitely going to be huge differences, in terms of
ownership models, community contributions, availability, usage, how the
ecosystem works and user experience.
The pure fact that you can dnf install it says nothing about what
lies
beneath and how to properly toolchain it or package applications for
it. I had seenboth .NET packagin internals, and tried to pack and .NET
application and it was terrible. But yes, presentation is good.
Could you share more?
Are your concerns around the .NET SDK/Runtime packages themselves or
packaging external applications that need to be built using the
SDK/Runtime?
What would make you revise your opinion?
Thanks,
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
9:20 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
Hi,
Neal Gompa <ngompa13(a)gmail.com> writes:
The Python team made "Fedora Loves Python":
https://fedoralovespython.org/
The .NET team maintains the Developer page for .NET and has a domain
redirect to it: https://fedoraloves.net/
For the record, the .NET SIG has a bus factor of one (maybe two) people
when it comes to marketing like fedoraloves.net. We are probably going
to lose one person soon, and I don't know if we can dedicate the
manpower it needs anymore.
What do other communities that are short on members do? Are there
well-known strategies on how to best utilize the minimal people/time for
maximum community benefit?
Thanks,
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
8:14 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/17/22 08:33, Stephen Smoogen wrote:
On Mon, 16 May 2022 at 23:18, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> On Mon, May 16, 2022 at 9:54 PM Andrew Hughes <gnu.andrew(a)redhat.com>
> wrote:
>>
>> On 19:36 Tue 10 May , Florian Weimer wrote:
>>> * Vitaly Zaitsev via devel:
>>>
>>>> On 10/05/2022 15:29, Ben Cotton wrote:
>
>> Also, my sympathy for this argument is a little short, given the
>> number of times we've released OpenJDK updates for Fedora on unembargo
>> date, only for them to sit waiting for karma. Recently, we even had
>> one security update usurped by a later regression fix because it still
>> hadn't gone stable in over a week. Let's not pretend that Fedora has
>> every security issue fixed as soon as the unembargo lifts.
>>
>
> I don't know if you're going to gain any sympathy for stating this,
> considering how badly the Fedora Java ecosystem has fallen apart in
> the span of five years. Both in the wider Red Hat world and within
> Fedora itself, Java has received less and less love, to the point that
> it has been brutally starved. It has gotten so bad that Debian (!!!)
> beat us to newer Java and we had to *beg* for this to be fixed. So
> much for Features and First, eh?
>
> Once, long ago, we were the leader in the Linux Java ecosystem, but
> ironically as Red Hat's influence in OpenJDK grew, investment in
> Fedora dwindled.
I am pretty sure that was a very very tiny period of time of 2 to 3 years.
Over the 25 years I have worked on RHL and then Fedora.. we have nearly
always been a far follower on Java. For a good period of time from
2004->2012, there were regular flaming mailing threads about "Java in
Fedora sucks", "Java only wants exceptions to standard policies",
"Fedora's
java is broken on X". It took a LOT of work to get Java into a 'working
state' but it is like 'welding' plastic to steel.. You constantly find
yourself remelting parts or adding more glue until what you have is more
'stuff which keeps them stuck together' versus 'tools which work'.
The investment when it was done back then was done by volunteers (they
might have been @redhat.com but they weren't doing it as their main tasks)
who frankly one after another burned out over the toxic reaction they got.
[That said it was a two way street of toxic reactions...] For the last 7
years, there has been a dwindling number of people who basically got mostly
'this is bull$hit, fix it the way I want it' reactions from Fedora
community members. For some reason, various people in the community have
assumed that Red Hat pays people to work on Fedora primarily and Java
secondary which was never the case.
If I understand correctly, the main problem
with the Java ecosystem
is that it is based on redistribution of binaries, not source code.
The focus is on building binaries that can be run on as many
systems as possible, rather than on providing source code that
users compile themselves. This makes a huge amount of sense in
the enterprise software world, but is diametrically opposed to
the open source distribution model. Nowadays, the problem of
redistributing Linux binaries is solved via containers (including
Flatpak/Snap/AppImage/etc), but those both predate Java and are not
useful for those targeting Windows (as many enterprise projects do).
The result is a culture clash. Rebuilding from source isn’t a matter
of reusing the upstream release tarball or Cargo/pip/etc package,
but of finding whatever VCS commit upstream used and building that
manually. OpenJDK is designed to produce native images that can be
redistributed, rather than be a system-wide installation that other
software depends on. Packaging Java software for any distribution
(not just Fedora) means going against the grain of various upstreams,
and that is a significant amount of work.
That said, I don’t think the answer is “give up”. A much better
approach would be for the work to be shared between Fedora, Debian, and
other distributions. I believe that this is both doable and necessary.
This isn’t specific to Java, by the way. JavaScript has similar
problems, and I believe .NET does as well. In the case of JavaScript,
the problem is hidden by the heavy use of transpilers, which result
in the shipping of JavaScript that isn’t actually source code
(in the sense of “preferred form for making modifications”).
> So tell me, if we actually *did* this, what are *you* planning to
do
> to make open source Java more attractive? What are you going to do to
>
Why is this their job to do that? They, like N% of Fedora packagers, are
volunteers who just have @redhat.com addresses. They have limited time,
resources and ability to keep the packages in Fedora. They, like many other
volunteers, are finding that 'free' time is getting smaller, and are trying
to come up with ways to keep it in.
If other people want it to be promoted and attractive, they need to do the
marketing work to do so. The alternatives I am seeing here are:
1. This is done this way (if the build system will even allow that without
more horrible hacks).
2. OpenJDK is taken out and a different external repo is given a nod like
the ones we do for flatpak and such.
3. OpenJDK is taken out, and the various new people step up and put in a
IcedTea replacement that 'mostly' works and deals with the trademark
issues, and the marketing to get it seen and used.
Staying the same is not an option and is off the table.
I would be fine with either dropping TCK certification or only
certifying a subset of the packages. Fedora users almost certainly
do not need it, and the trademark problems can be worked around.
AdoptOpenJDK did so a while back, so there is precedent.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:42 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/17/22 08:33, Stephen Smoogen wrote:
If I understand correctly, the main problem
with the Java ecosystem
is that it is based on redistribution of binaries, not source code.
The focus is on building binaries that can be run on as many
systems as possible, rather than on providing source code that
users compile themselves. This makes a huge amount of sense in
the enterprise software world, but is diametrically opposed to
the open source distribution model. Nowadays, the problem of
well said! ty!
redistributing Linux binaries is solved via containers (including
Flatpak/Snap/AppImage/etc), but those both predate Java and are not
useful for those targeting Windows (as many enterprise projects do).
We really do not want ending with java in Flatpak. But growing number of projects
embedding whole jdk wit project is alarming.
The result is a culture clash. Rebuilding from source isn’t a matter
Correct
of reusing the upstream release tarball or Cargo/pip/etc package,
but of finding whatever VCS commit upstream used and building that
manually. OpenJDK is designed to produce native images that can be
redistributed, rather than be a system-wide installation that other
software depends on. Packaging Java software for any distribution
(not just Fedora) means going against the grain of various upstreams,
and that is a significant amount of work.
That said, I don’t think the answer is “give up”. A much better
approach would be for the work to be shared between Fedora, Debian, and
other distributions. I believe that this is both doable and necessary.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
There is an effort of identical reproducible binaries in openjdk usptream. That says, that
you build on several systems identical binaries, and thus you can TCK onl one of them.
That was created by cowork of Red hat, Debian and others, to solve the TCK issue.
Still I'm afraid it will never work properly with dynamic linking.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
This isn’t specific to Java, by the way. JavaScript has similar
problems, and I believe .NET does as well. In the case of JavaScript,
the problem is hidden by the heavy use of transpilers, which result
in the shipping of JavaScript that isn’t actually source code
(in the sense of “preferred form for making modifications”).
I would be fine with either dropping TCK certification or only
certifying a subset of the packages. Fedora users almost certainly
do not need it, and the trademark problems can be worked around.
You really cant. Ownere of TCK is quite benevolent, but possibel breaking of this
agreement will lead to lost of OpenJDK in Fedora
AdoptOpenJDK did so a while back, so there is precedent.
Nope. They run full TCK. And before they proeprly passed, they hard hard times wit OpenJDK
owner.
4:27 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 17.05.2022 um 05:08 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
I don't know if you're going to gain any sympathy for stating this,
considering how badly the Fedora Java ecosystem has fallen apart in
the span of five years. Both in the wider Red Hat world and within
Fedora itself, Java has received less and less love, to the point that
it has been brutally starved. It has gotten so bad that Debian (!!!)
beat us to newer Java and we had to *beg* for this to be fixed. So
much for Features and First, eh?
We had that discussion some time ago. The essence is: Your description is not accurate.
We have - as for years - a very stable and current and highly usable JRE / JDK.
Many application program disappeared as RPM. This is not particularly important for the
use of Java programs. Since any jar / was /ear program runs on any JRE, it pretty much
does not matter where the jar comes from. All Fedora-specific issues are managed by the
JRE/JDK.
However, I too would be happier if we had more programs in RPM form.
We've also lost most of our Java based apps to even test OpenJDK
with.
See above, there are so many Java progs, just not as RPM (and this does not
affect comfort and usability in case of Java).
We lost
Eclipse last year, and we lost IntellJ and NetBeans several years ago.
We didn’t lost Eclipse, we switched from RPM to another distribution method. The same with
Netbeans.
The larger Java community stopped
encouraging the development of desktop apps more than seven years ago,
and with it all the things people would normally be able to use with
it are gone.
Maybe (we have much more alternatives today, so a single technique relatively shrinks),
but that wouldn’t be a Fedora issue.
The Red Hat Java team has done *nothing* that I can see to advocate
for Java in the larger Fedora community, nor have they tried to appeal
to people to make applications like Microsoft does with .NET.
I agree, that’s an issue in Fedora, too. Technically, everything is highly developed and
of high quality. But, IMHO, the "ensemble around", which is essential for
long-term success, is considerably neglected.
I have tried to get involved on several occasions, but have thrown in the towel in
discouragement. I am still ready to get involved, if I could find an on-boarding route.
So tell me, if we actually *did* this, what are *you* planning to do
to make open source Java more attractive?
Basically, you could ask these questions to anyone here, and perhaps to yourself as well.
It must be achieved to develop an initiative that bundles the existing technical expertise
with new ideas and new people and drives the project forward not only technically, but
also the "ensemble around".
But how?
I don’t know. At least not with accusations and clever speeches alone.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
7:40 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 18.05.22 um 11:27 schrieb Peter Boy:
We didn’t lost Eclipse, we switched from RPM to another distribution
method.
Do you mean the Eclipse flatpak? I tried the flatpak but in the end went back to
upstream's plain binaries as the Flatpak does not work well when using pydev.
So for my use case Fedora lost Eclipse.
Felix
6:50 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 14:40, Felix Schwarz wrote:
Am 18.05.22 um 11:27 schrieb Peter Boy:
> We didn’t lost Eclipse, we switched from RPM to another distribution method.
Do you mean the Eclipse flatpak? I tried the flatpak but in the end went back to
upstream's plain binaries as the Flatpak does not work well when using pydev.
So for my use case Fedora lost Eclipse.
I tend to agree. No flatpak ide ever proeprly fored for me, especially becasue of
impossibility to use any custom jdk or thrd party servers (including in fedora packed
ones) proeprly.
On the other side, huge java projecs (like eclipse or netbeasn) are so complex and so
impossibel to pack properly, that wgeted tarball remmains win win.
Even in time of those ides packed,the tarballs freom web was quite a lot better.
J:(
Felix
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
9:36 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 11:27, Peter Boy wrote:
We didn’t lost Eclipse, we switched from RPM to another distribution
method. The same with Netbeans.
No RPMS in Fedora repositories => Fedora lost them.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:28 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org>:
On 18/05/2022 11:27, Peter Boy wrote:
> We didn’t lost Eclipse, we switched from RPM to another distribution method. The same
with Netbeans.
No RPMS in Fedora repositories => Fedora lost them.
You neglect the reality.
One alternative installation source is flatpak, that is gaining approval among more and
more Fedora developers, and more and more are switching to it. There may still be initial
difficulties, but this is a clear trend. Meanwhile, this is also an accepted Fedora
repository. Not that I think that's great, but it's the reality.
Another way is to run software as a „black box“ container. If I run CoreOS or Silverblue I
would primarily look in container repositories, not any dnf find …
Or you just download the jar or Linux installation tar from the project. They usually
contain a shell script to invoke the jre and provide a class path. That’s all you need for
a java app.
So Fedora (= Fedora users) can use it as they could for years. There is nothing lost. But
circumstances and the nature of management and maintenance are changing. 20 years ago we
had no virtualization and no containers, no generic package managers as flatpack, snap,
etc. And Java development was much more about using ant and source code libraries instead
of maven and depository dependencies.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
10:31 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 11:28 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org>:
>
> On 18/05/2022 11:27, Peter Boy wrote:
>> We didn’t lost Eclipse, we switched from RPM to another distribution method. The
same with Netbeans.
>
> No RPMS in Fedora repositories => Fedora lost them.
You neglect the reality.
One alternative installation source is flatpak, that is gaining approval among more and
more Fedora developers, and more and more are switching to it. There may still be initial
difficulties, but this is a clear trend. Meanwhile, this is also an accepted Fedora
repository. Not that I think that's great, but it's the reality.
Another way is to run software as a „black box“ container. If I run CoreOS or Silverblue
I would primarily look in container repositories, not any dnf find …
These two options do not use a Fedora Java runtime,
Or you just download the jar or Linux installation tar from the
project. They usually contain a shell script to invoke the jre and provide a class path.
That’s all you need for a java app.
So Fedora (= Fedora users) can use it as they could for years. There is nothing lost. But
circumstances and the nature of management and maintenance are changing. 20 years ago we
had no virtualization and no containers, no generic package managers as flatpack, snap,
etc. And Java development was much more about using ant and source code libraries instead
of maven and depository dependencies.
Java was almost never about source code libraries, that's been the
problem the entire time. The entire focus has been on introspectable
binary JAR files, which is how most libraries are distributed. That's
what makes Java the odd duck out compared to most ecosystems. It also
makes Java applications more difficult to fix, because there's no
built-in assumption or ecosystem drive to promote shipping source
code.
--
真実はいつも一つ！/ Always, there's only one truth!
6:52 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 17:31, Neal Gompa wrote:
On Wed, May 18, 2022 at 11:28 AM Peter Boy <pboy(a)uni-bremen.de>
wrote:
>
>
>
>> Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org>:
>>
>> On 18/05/2022 11:27, Peter Boy wrote:
>>> We didn’t lost Eclipse, we switched from RPM to another distribution method.
The same with Netbeans.
>>
>> No RPMS in Fedora repositories => Fedora lost them.
>
> You neglect the reality.
>
> One alternative installation source is flatpak, that is gaining approval among more
and more Fedora developers, and more and more are switching to it. There may still be
initial difficulties, but this is a clear trend. Meanwhile, this is also an accepted
Fedora repository. Not that I think that's great, but it's the reality.
>
> Another way is to run software as a „black box“ container. If I run CoreOS or
Silverblue I would primarily look in container repositories, not any dnf find …
>
These two options do not use a Fedora Java runtime,
I'm still new to silverblue, so I don not parse. What does it use if not system java
please?
> Or you just download the jar or Linux installation tar from the project. They usually
contain a shell script to invoke the jre and provide a class path. That’s all you need for
a java app.
>
> So Fedora (= Fedora users) can use it as they could for years. There is nothing lost.
But circumstances and the nature of management and maintenance are changing. 20 years ago
we had no virtualization and no containers, no generic package managers as flatpack, snap,
etc. And Java development was much more about using ant and source code libraries instead
of maven and depository dependencies.
>
Java was almost never about source code libraries, that's been the
problem the entire time. The entire focus has been on introspectable
binary JAR files, which is how most libraries are distributed. That's
what makes Java the odd duck out compared to most ecosystems. It also
I would say this is one fo the strengths of the java.
11:30 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 17:28, Peter Boy wrote:
You neglect the reality.
RPM is still the main package format on Fedora.
One alternative installation source is flatpak, that is gaining
approval among more and more Fedora developers, and more and more are switching to it.
Do you mean a third-party repository Flathub by "Flatpak"?
Sorry, but I can't trust Flathub, because they even doesn't build a lot
of popular apps from sources[1]. They are just repackaging DEBs.
There is nothing lost.
I don't think so. The entire Java ecosystem on Fedora was destroyed by
Fedora Modularity. Volunteers tried several times to revive it but
failed due to opposition.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:53 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
I don't think so. The entire Java ecosystem on Fedora was destroyed by Fedora
Modularity. Volunteers tried several times to revive it but failed due to opposition.
I personally heavily agree:((( The modularity was great idea, but worst implementation
ever.
And for java it was indeed death blow which will take years to fix.
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
5:28 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Once, long ago, we were the leader in the Linux Java ecosystem, but
ironically as Red Hat's influence in OpenJDK grew, investment in
Fedora dwindled.
That really is not true. But maybe we were doing to much to keep any java somehow alive.
This proposal will untie our hands, and we wil be able to focus to toher things - exactl
those which you propose.
We've also lost most of our Java based apps to even test OpenJDK
with.
What the heck are we supposed to do to test and give karma? We lost
Eclipse last year, and we lost IntellJ and NetBeans several years ago.
Azureus was removed a year ago, too. The larger Java community stopped
encouraging the development of desktop apps more than seven years ago,
Excelent point - the reason why they quit, is that it is impossible to maintain compelte
dependency chain, and having downloadable blob is so much easier for the maintenance.
And JDK world is moving into this direction. If we will not be allowed to do so, JDK can
leave fedora at all.
6:02 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 12:28 PM jiri vanek <jvanek(a)redhat.com> wrote:
> Once, long ago, we were the leader in the Linux Java ecosystem, but
> ironically as Red Hat's influence in OpenJDK grew, investment in
> Fedora dwindled.
That really is not true. But maybe we were doing to much to keep any java somehow alive.
This proposal will untie our hands, and we wil be able to focus to toher things - exactl
those which you propose.
My experience with trying to keep Java packages in Fedora alive does
not allow me to agree with you.
I tried to keep Java ecosystem from disintegrating *twice* and both
times I was discouraged by Red Hat employees.
> We've also lost most of our Java based apps to even test
OpenJDK with.
> What the heck are we supposed to do to test and give karma? We lost
> Eclipse last year, and we lost IntellJ and NetBeans several years ago.
> Azureus was removed a year ago, too. The larger Java community stopped
> encouraging the development of desktop apps more than seven years ago,
Excelent point - the reason why they quit, is that it is impossible to maintain compelte
dependency chain, and having downloadable blob is so much easier for the maintenance.
And JDK world is moving into this direction. If we will not be allowed to do so, JDK can
leave fedora at all.
That's not a valid argument, though, is it?
If you have the choice between doing something that is 1) hard or 2)
forbidden, then you don't really have a choice, do you?
Redistributing binary blobs or pre-compiled JAR files is not something
we can do with Fedora RPM packages.
Of course it would be much simpler if we could just take JAR files
from Maven Central and wrap them in an RPM, but that is forbidden in
Fedora for good reason.
And that does not even account for the packages in Fedora that contain
some amount of Java support code or tools that happen to be written in
Java, and so rely on at least some parts of the Java ecosystem (javac,
maybe maven or ant) to be available as RPMs during package builds.
Fabio
7:03 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 13:02, Fabio Valentini wrote:
On Wed, May 18, 2022 at 12:28 PM jiri vanek <jvanek(a)redhat.com>
wrote:
>
>> Once, long ago, we were the leader in the Linux Java ecosystem, but
>> ironically as Red Hat's influence in OpenJDK grew, investment in
>> Fedora dwindled.
>
> That really is not true. But maybe we were doing to much to keep any java somehow
alive. This proposal will untie our hands, and we wil be able to focus to toher things -
exactl those which you propose.
My experience with trying to keep Java packages in Fedora alive does
not allow me to agree with you.
I tried to keep Java ecosystem from disintegrating *twice* and both
times I was discouraged by Red Hat employees.
Can you elaborate more please?
I guess one of this interactions was me. Which makes me double courious what caused you
this experience.
>> We've also lost most of our Java based apps to even test OpenJDK with.
>> What the heck are we supposed to do to test and give karma? We lost
>> Eclipse last year, and we lost IntellJ and NetBeans several years ago.
>> Azureus was removed a year ago, too. The larger Java community stopped
>> encouraging the development of desktop apps more than seven years ago,
>
> Excelent point - the reason why they quit, is that it is impossible to maintain
compelte dependency chain, and having downloadable blob is so much easier for the
maintenance.
> And JDK world is moving into this direction. If we will not be allowed to do so, JDK
can leave fedora at all.
That's not a valid argument, though, is it?
If you have the choice between doing something that is 1) hard or 2)
forbidden, then you don't really have a choice, do you?
That is correct.
But afaik there are three
1) hard 2) a bit easier 3) forbidden
As fedora ahve bundling already allwod, the 2 is choice if 1 was attempted and proved to
cost really a lot.
Redistributing binary blobs or pre-compiled JAR files is not
something
we can do with Fedora RPM packages.
As writtten several times - this si not true. It will eb always source codebuilt in
koji.
Of course it would be much simpler if we could just take JAR files
from Maven Central and wrap them in an RPM, but that is forbidden in
Fedora for good reason.
Here I agree. if fedora move to prepacked blobs, then all freedome of source is gone. No
way. If I ever suggest that, I will give you happily my address so you can take proper
steps to stop it;)
And that does not even account for the packages in Fedora that contain
some amount of Java support code or tools that happen to be written in
Java, and so rely on at least some parts of the Java ecosystem (javac,
maybe maven or ant) to be available as RPMs during package builds.
But that is again not going to change. I fail to understand your point here. Nor did I got
why my argument is not valid.
Maybe you misunderstood "having downloadable blob is so much easier for the
maintenance"
I ment downloadable from internet, not as rpms. Some simple mvn assembly:assembly which
will do all the build work on developer's local machine, and then mvn release:release
which will publish on project's web page and maintianer is done.
On contrary, with more then 10 dependencies (unpacked for distro) it is already quite a
fight to put it in. And if dependency (version) hell strikes, the apckager is lsot, where
upstream maintainer and publisher is not.
Fabio
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
7:26 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:03, Jiri Vanek wrote:
As writtten several times - this si not true. It will eb always
source
codebuilt in koji.
From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
Make the normal rpms to not built jdk, but to repack the portable
rpms with all integration
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:02 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Fri, 20 May 2022 at 08:43, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
On 20/05/2022 14:03, Jiri Vanek wrote:
> As writtten several times - this si not true. It will eb always source
> codebuilt in koji.
From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
I looked through the wiki history and it has said the following since the
first page in April 8th:
```
It is also not a goal, to pack third party blob. Jdk will still continue to
build in koji as it should.
```
Is there some other section which counters this?
Make the normal rpms to not built jdk, but to repack the portable
rpms
with all integration
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
2:13 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Hello!
My apologies, I had accidentally dropped out of computer world for a while, and here a
world spins ahead! Thanx a lot for many valuable feedback!
see the clarifications of most concerns:
Might be a copy-paste error there, the last sentence is incomplete.
ty, fixed: "We already made a heavy testing of the behavior, and user should
not face negative experience. Still I'm not sure if this testing can ever be enough,
considering all the use-cases we do not know. "
Bundled versions are always outdated and may be even vulnerable.
Not necessarily. In small project, sure, bundled libraries will get rotten, but project
like OpenJDK, where 99% of its builds uses the in tree copies, can not allow itself to
have security holes in them. It already happened in past that we
have switched to the in-tree library because the CVE there was already fixed, and moved
back to system library once the fix landed to live Fedora.
Using bundled freetype, fontconfig and harfbuzz will result in ugly
fonts (without system configuration support, including subpixel rendering, hinting, etc).
This is probably main issue we are aware about. Especially the system configuration will
be a hard issue, if solvable at all.
However IIRC, those features do nor work properly in java event hose days, as java have to
support all what lies below, and it simply can not, so the intree libraries come to play.
Note that we had to patch jdk in past to work properly after changes in the system
libraries. And that is not easy task.
Please take my last three sentences with bit of reserve, a better upstream engineer then
me should comment.
Applications linking against libraries SHOULD link against shared
libraries not static versions.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
right, should. So strictly from law of guidelines, there is no rule to stop this change.
The bundling was always bad, but is necessary evil. See eg rsync - the bundled zlib is
there because it is technically not possible to use dynamic one.
Java is in the border - yes, you can use the dynamic libraries (and it really took several
excellent engineers a decade to manage), but it have pros and cons. Unluckily, the
negatives are multiplying for years. Although we are not happy
with the change, it must be done if JDKs should remain maintained and healthy in Fedora.
s
And upstream only incorporates security fixes once per quarter
Right, but downstream works well too. If such vulnerability occurs, be sure we will patch
RPMs asap, and also upstream project - maybe without release - will react to.
Unluckily, I'm unable to comment on the demanglers, can you elaborate more?
In this case upstream might actually get there first because this CVE
is not yet fixed in Fedora
And it already happeed in past, that jdk swithced to bundled version for a while, and back
to dynamic once the library was fixed in live Fedora.
This sounds fascinating. Can anyone share details about this? On the
I'm aware of some codecs, which are built in Fedora, then the binary is sent to
.. cisco(?), and if passed, they are repacked into all live fedoras.
As super cornercase of this may be packing of some firmwares as binary blobs.
versions in an RPM sounds like it would violate all the guidelines
under
$foo to meet this threshold and claim it needs to avoid rebuilding for certification?
Right, you need fesco exception.
I'm very confused on why this reduces certification burden. In
our crypto libraries this is exactly the kind of behavior we would *NOT* want packages
to do because it increases our certification and support burden.
I believe this are
two things.
First - our burden. We ahve to certify each binary. This is quite long and lenghty
process. Onl once it is certified, we can release it (with small unwritten exception in
rawhide)
So with repacked portabel build as described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs will allow us to certify
once (and even stop hoping for that small exception in rawhide). Considering 4 jdks in 3
maintianed
fedoras, that is incredible work. If it reduced to 4 we will manage again.
Second - I can understand that you certify your libray, but if others bundle it, then it
is theirs choice, and they are on thier own, arent they? Also you highlight crypto lib, we
are not going to embed any crypto library. Crypto is loaded
in runtime, and build time have no idea about future system in this case. Can you please
elaborate more if still needed?
I'm confused how this would not negatively impact the user
experience, because things like FreeType and HarfBuzz in Fedora have features and
configuration that are non-default that improve the font rendering capabilities of
applications
that link to FreeType.
As explained above. This is knwon issue. I was naively considereding it as minor, as it
nearly non-fixable, and to my half blind eyes some subixels and shadows says nothing. (/me
on non patched fluxbox, which I guess explains all). This
is also how I wrote it to the
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic#User... and
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_ef... . As I
realy ahve only vague knowledge of
what you are speaking about, can you please ehnace those two paragraphs?
I would rather have our shared maintenance and evolution of font
stuff be reused in Java too...
This is holy grail we have been pursuing for last 10 years. But now we gave up. To keep
java alive in Fedora, we have to take this one step back.
Are people really installing OpenJDK RPM packages, taking the
"/usr/bin/java" binary, and putting it onto some other system?
No, no and
no:)
Please see the linked https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
I cannot see how Fedora RPM packages for OpenJDK can redistributing
pre-built binaries would ever be considered acceptable.
no, no and no again, Please
see the linked https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
In long run, we will build in koji once, and repack this to all live fedoras. There alre
already prcednets, and even worse things - like packing blobish binary driver, are here.
I guess you noticed, that it was clarified already in the discussion. Thanx a lot for
highlighting this though.
I agree, I don't think there's positives for the user
experience here. And I don't understand what actual problem this change is trying to
solve?
As described above, keeping dynamic jdk proeprly working requires huge maintainance. In
addition, jdks are expected to be static (only distribution rpms do differently, and thats
why developers often unpack 3rd party static jdk to develop
on), and have futures like generating standalone binary native images and so, which are
impossible with dynamic linking. Future of java looks pointing pretty stright forward to
such changes, so we have to move to.
When the change talks about being "portable", my
understanding is that means within the context of Fedora. eg they want to be able to build
the JDK version in a Fedora 35 build root once, and then ship that built binary in Fedora
35,
Fedora 36 and Fedora rawhide (37) by just tagging the F35 build into the newer
Fedora koji tags too, instead of rebuilding for each Fedora version.
Exactly. With one addition - the jdk will be indeed portable, you should be able to bring
it to most of the system,and it should work. Still glibc limitations remains here. To
stand on the safe ground, "usual" non distribution providers of
openjdk simply builds on oldest possible supported system.
Also there si one more advantage - the native images you produce form suchjdk will be
trully portable. Unlike now, when they are simply unusable. I know distro-based people
dont like this. But that si current state of world. By hart I'm
distribution person living on Fedora since Core 4 with few steps to other distros, but as
java developer I;m rather distributing final self contianed blob to custommmer so he have
everything in place. So despite being java maintainer for
decade, I' have to unpack and use 3rd party jdk much more often then I would like.
This case appears different in that Fedora is still building the
binaries in one release stream,
Right. Thanx for describing it.
One downside with building in F35 and then re-tagging into newer
Fedora releases, is that we loose any insight into problems coming down the pipe.
Currently a Fedora rawhide mass rebuild will often highlight pre-existing bugs in
applications, and/or highlight bugs in newly rebased GCC toolchain....Detecting bugs
early in both applications and GCC toolchain, via builds in rawhide...
Right you are, and it is already described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Rawhide...
We are very well aware of this benefit, and we will do our best to keep it running - eg to
build portbales also in rawhide, although not to repack them. Just for this single - but
huge - case.
We deeply agree with your description of rawhide and gcc bumps. Thanx a lot for
highligting it.
This is so bad. The final death of Java on Fedora.
Actually just a opposite. This is future of java and without it java in fedora my diminish
and fade away. I personally really do not like this change, and I agree with all rebukes
taken here. But current OpenJDK maintainers (which are the
same for last decade) do not see other way.
If it will really go bad, we will withdraw and continue fighting.
I consider this a step entirely in the wrong direction. The JDK
should be linked to system libraries wherever possible just like our other packages.
Language interpreters/JITs are not exempt from that. In fact, I see very little value
in providing JDK packages at all if they are built that way.
Where you are right with the interpreters/jits not being exempt, I'm afraid yo do not
see current flow of java - to self contained native images, and to share OpenJDK
marketpalce. Even if wesomhow will be able to pathc jdk to live with
system libraries, which is already close to impossible, and drop all features which
allows generate portable images, the problem with the certification will persists. It
isnot in human powers to maintain 4 JDKS in 3 Fedoras.
And this plan is entirely unacceptable. It is just plain not allowed
in Fedora to ship prebuilt binary blobs (even if they are built by Fedora developers)
This is wrong. The JDK will be always build from sources in koji. The main reduce of load
will be that webuilt once in koji, in oldest Fedora, and repack to newer.
In additon there are many excludes in various binary drivers.
If passing the TCK is such an issue, then please just go back to
shipping the packages under the name IcedTea or some other name not trademarked by
Oracle.
It is not as simple. You are right that to call it java yoou must pass tck. But unluckily
even IcedTea had to pass TCK. Maybe it is possible to patch out all "java" from
it, but I doubt jdk will remain working and usefull,.
No way. This violates Fedora policy. All packages **must** be built
from sources. No exceptions.
Quite a few packages are dleivered as blobs... Still. Be sure we are NOT going to do that.
We will continue to build from sources, in koji, and with luck only repack build form
latest stable Fedora to all,
Fedora 38. So the decision on whether to approve this first feature
really needs to consider the acceptability of the overall plan, not just this first step
in isolation.
You are right, that the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
is the key, but by aproving this, the whole chain isnotyet there. Especially if we found
that the static jdks are really not viable, then this
(https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic) proposal will be
reverted, and the https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
cacneled.
But to be able to move forward, we have to try. If we dont, it will not know we are no
wrong track, and thus be unabel to try to figure backup plan.
IIUC, it is implied that when a new JDK comes out (jdk19 next), it
would be added immediately to all Fedora streams (35, 36, 37rawhide).
Yes, jdk 19 will be added to all fedoras. But not as new package - it will replace jdk18
inside java-latest-openjdk. jdk19 is STS, simialrly as jdk18 was. Once next LTS is out
jdk-21 in 2024, I hope we wil finally drop jdk8, so we wills
stay in 4 jdks.
introduce new JDKs to all existing Fedora streams, only add it to
rawhide so certification is only needed once.
That will unluckily not help. there would remain previous JDK in older Fedoras. In
addition, EOLed one.
certification; form same email as abvoe two huks, from Daniel P.
Berrangé.
+ Why do we need such certification? Fedora is a separate distribution, not related to
Oracle at all.
To call build of OpenJDK java, each binary ahve to pas TCK(as mentioned in thread). And
you have to do it on each binary you produce. So with dynamic lining in fedoras, I have to
certifie 12+ builds.
And update once they pass (with small exception in rawhide). With portable build, I can
build once, TCK it eg on super custom opensuse, and still do update (from this binary) to
all Fedoras.
TCK - are testing if all public apis forks as expected. Despite some tck are really weird,
and to pass we eg have to have balck background and shadows disabled and so, the TCK are
pretty good testsuite. Corenrcases are in other testssuites,
which we run too. As our build is based on OpenJDK with Hotspot, we do not need to prove
it, but must provide once asked.
Also the "one would have thought that any time a dependency got an update it would
invalidate certification too, even right down to any glibc update, or even kernel update
" is close to reality. But we really have to pass the binary on ANY
system. Including the one before release. So luckily not.
Is there an actual contractual requirement for Fedora to distribute
OpenJDK builds only after they have passed the TCK? That's just impossible with the
Fedora build system, and we would have to remove OpenJDK from Fedora to comply.
I'm not sure I follow. Why would we need to remove OpenJDK from fedora to comply? The
only issue I see is the Rawhide. But considering it is not officially released.. It should
be ok.
Each build we pass to updates, we are bound to prove it passes TCK. As we control
environment, we are usually able to do so.
Runing them is mandatory. The results reporting is on demand. The simple rename is not so
easy. I "m afraid that striping all "java" from bnaries and thus from
sources is maybe possbel to be done, but human impossible to maintian, and
will leave JDK mostly not working, and for sure useless and incomaptible with other
javas.
One of the side steps of this proposal is to be more compatible with other javas.
If current maintainers can't continue maintaining the
well-packaged OpenJDK, I think it's time to retire it. It would be better
Yes,
we can no longer maintian it. And I must contradict you - Seeing all the dependencies, we
really need them all. Loosing any one, wiould kill java ecosystemin Fedora.
You do not need to rebuild OpenJDK after the system library update
is installed.
We rebuild so often that this one is irrelevant.
That would also mean that the JDKs would lag any other Fedora
system-wide changes, such as compiler/library updates, build options that affect security,
etc.
Well, yes. But except GCC which we will try to support as writen above, and in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Rawhide...
But please not, that that is very common troubles for us. We do adapt to fedora changes -
eg crypto policies or so - but the bumps of libraries are unnecessary burden. As those
usully need bigger patching upstream. But please takeme with
reserve - a more upstream/native libs development included persn should elaborate.
in last decade, we proved one thing - each fedora change like crypto policies or so, when
finally tuned in JDK, was possible to backport to older fedoras. However changes due to
shared libs, not.
F35, F36, and rawhide need to be updated to a JDK built on F35...
which would mean that F36 gets released with an immediately obsolete JDK, to be replaced
with an untested (in the general sense, didn't go through OS beta and such) build.
Interesting point of view. Tyvm for it!
If the binary is identical, then what can go wrong? Already now tests portable comunity
builds on all live fedoras, and a distribution-specific issue is so rare, that I think
there was none even on long run.
Still I see yor point and possible issues you suggests out. Trhough tuccrent plan, your
assumption "F36, and rawhide need to be updated to a JDK built on F35." is
correct.
However the "t F36 gets released with an immediately obsolete JDK, to be replaced
with an untested (in the general sense, didn't go through OS beta and such)"
should not be correct.
There is ususaly no need to update immediately. It is actually even not desired. And here
is few weeks where original builder Fedora is still alive, and we can stay on it for a
while. But sooner or later the new "untested" from your point
of view Jdk will get there. The onl assurance it careful testing of Openjdk maintianers.
To make your sleep a bit easier,:
gJobsAllOtool | grep -e f35 -e f34 -e f36 | wc -l
2736
We run 2736 testsuites jenkins jobs on Fedoras. From those,
gJobsAllOtool | grep -e f35 -e f34 -e f36 | grep tck | wc -l
197
197 are TCK (which each includes over 100k of tests) jenkins jobs, as there are several
architectures, and even several variants of JDK which we wish to esnure. I expect the
testing burden to drop to 1/2, without actually loosing necessary
coveragein matrix, after the whole
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs is alive.
Or would rawhide get a build built on (oldest+1) rather than
(oldest)? So F36 would be tested and released with a build built on ...
Interesting idea. Tyvm for it!
No, I was considering simply latest live one. But no imediate repack is needed once it is
eoled. We can stay for a bit on eoled one, or not update from new oldest. In all cases the
heavy testing will preceded
In your description. It is indeed a bit of confusing
> JDKs from other vendors(Amazon, Azul, Oracle, etc.) are built in
exactly this way. W
Because they build it for all available GNU/Linux distributions. We shouldn't focus
on bad practices.
Well and there are many reasons to do so, as jdk is designed to be like this. for 10
years we tried to go against the main stream, and we managed a lot. But to keep peace and
compatibility and proper developer's support, we have to move
with mian stream now. The divergences we keep in rpms are right now blocking devloeprs to
use system jdsk as proper JDKs and are enforcing them to download Amazon, Azul, Oracle,
etc. blobs...
To keep Fedora competitive, this is currenlty necessary step.
I hope I addressed all,
Thanx a lot for contributions!
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
3:57 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
> I would rather have our shared maintenance and evolution of
font stuff be reused in Java too...
This is holy grail we have been pursuing for last 10 years. But now we gave up. To keep
java alive in Fedora, we have to take this one step back.
Why did you give up?
> This case appears different in that Fedora is still building
the binaries in one release stream,
Right. Thanx for describing it.
> certification; form same email as abvoe two huks, from Daniel P. Berrangé.
> + Why do we need such certification? Fedora is a separate distribution, not related
to Oracle at all.
To call build of OpenJDK java, each binary ahve to pas TCK(as mentioned in thread).
At one point AdoptOpenJDK distributed binaries that were not tested
against the TCK (https://dzone.com/articles/an-overview-on-jdk-vendors).
> Is there an actual contractual requirement for Fedora to
distribute OpenJDK builds only after they have passed the TCK? That's just impossible
with the Fedora build system, and we would have to remove OpenJDK from Fedora to comply.
I'm not sure I follow. Why would we need to remove OpenJDK from fedora to comply? The
only issue I see is the Rawhide. But considering it is not officially released.. It should
be ok.
Each build we pass to updates, we are bound to prove it passes TCK. As we control
environment, we are usually able to do so.
Runing them is mandatory. The results reporting is on demand. The simple rename is not
so easy. I "m afraid that striping all "java" from bnaries and thus from
sources is maybe possbel to be done, but human impossible to maintian, and
will leave JDK mostly not working, and for sure useless and incomaptible with other
javas.
Why is running the TCK such a burden? Is it due to hardware
resource limitations? Do we really need to claim that
we are Java SE compatible?
One of the side steps of this proposal is to be more compatible with
other javas.
> If current maintainers can't continue maintaining the well-packaged OpenJDK, I
think it's time to retire it. It would be better
Yes, we can no longer maintian it. And I must contradict you - Seeing all the
dependencies, we really need them all. Loosing any one, wiould kill java ecosystemin
Fedora.
Is this purely because of the TCK requirement? If so, I would prefer
that Fedora ship an uncertified binary, or ship both a certified
static binary and an uncertified dynamic binary, with the latter
being the default.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:45 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Why did you give up?
I'm unable to enumerate number of bugs we solved, or even dropped as unsolvable due to
dynamic nature of distribution-correct JDK.
At one point AdoptOpenJDK distributed binaries that were not tested
against the TCK (https://dzone.com/articles/an-overview-on-jdk-vendors).
They indeed did it once, and had pretty hard time fromthat. Now they TCK propelry.
Why is running the TCK such a burden? Is it due to hardware
resource limitations? Do we really need to claim that
we are Java SE compatible?
We ahve claim the comaptibility. Tck run in the paralel mode 24h per os and arch and jdk.
And there are tricky issues, and even more tricky failures. So both human and hw cycles
are heavily under preassure
Is this purely because of the TCK requirement? If so, I would prefer
that Fedora ship an uncertified binary, or ship both a certified
static binary and an uncertified dynamic binary, with the latter
being the default.
Interesting idea. Not sure if legally possible but worthy of shot.
12:27 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 06:45, jiri vanek wrote:
> Why did you give up?
>
I'm unable to enumerate number of bugs we solved, or even dropped as unsolvable due
to dynamic nature of distribution-correct JDK.
Can you provide an example of an unsolvable one?
> At one point AdoptOpenJDK distributed binaries that were not
tested
> against the TCK (https://dzone.com/articles/an-overview-on-jdk-vendors).
They indeed did it once, and had pretty hard time fromthat. Now they TCK propelry.
>
> Why is running the TCK such a burden? Is it due to hardware
> resource limitations? Do we really need to claim that
> we are Java SE compatible?
We ahve claim the comaptibility. Tck run in the paralel mode 24h per os and arch and jdk.
And there are tricky issues, and even more tricky failures. So both human and hw cycles
are heavily under preassure
Why is claiming compatibility necessary?
> Is this purely because of the TCK requirement? If so, I would
prefer
> that Fedora ship an uncertified binary, or ship both a certified
> static binary and an uncertified dynamic binary, with the latter
> being the default.
Interesting idea. Not sure if legally possible but worthy of shot.
If Fedora legally cannot ship a version of OpenJDK that hasn’t
passed the TCK, but which is still compatible with the vast majority
of Java code, then OpenJDK isn’t free software and Fedora cannot
ship it at all. Conversely, if OpenJDK is free software, then Fedora
can strip out any problematic trademarks without losing compatibility.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
midnight
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Demi Marie Obenour wrote:
If Fedora legally cannot ship a version of OpenJDK that hasn’t
passed the TCK, but which is still compatible with the vast majority
of Java code, then OpenJDK isn’t free software and Fedora cannot
ship it at all. Conversely, if OpenJDK is free software, then Fedora
can strip out any problematic trademarks without losing compatibility.
This abuse of trademarks to make Free Software not really free is an
alarming pattern. See also Firefox.
Kevin Kofler
11:35 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/19/22 01:00, Kevin Kofler via devel wrote:
Demi Marie Obenour wrote:
> If Fedora legally cannot ship a version of OpenJDK that hasn’t
> passed the TCK, but which is still compatible with the vast majority
> of Java code, then OpenJDK isn’t free software and Fedora cannot
> ship it at all. Conversely, if OpenJDK is free software, then Fedora
> can strip out any problematic trademarks without losing compatibility.
This abuse of trademarks to make Free Software not really free is an
alarming pattern. See also Firefox.
Firefox does not bother me too much: disabling branding was just a
configure switch last I checked, and the no-branding build will still
work fine. I believe seL4 just says if you ship a modified version
you have to call it something different, and I am fine with that too.
My main problem is when removing trademarks is technically difficult
and/or causes breakage.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:54 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Jiri Vanek wrote:
see the clarifications of most concerns:
Unfortunately, your mail does not clarify all that much for me. I actually
see several contradictions, e.g.:
> Are people really installing OpenJDK RPM packages, taking the
> "/usr/bin/java" binary, and putting it onto some other system?
No, no and no:)
vs.
To call build of OpenJDK java, each binary ahve to pas TCK(as
mentioned in
thread). And you have to do it on each binary you produce. So with dynamic
lining in fedoras, I have to certifie 12+ builds. And update once they
pass (with small exception in rawhide). With portable build, I can build
once, TCK it eg on super custom opensuse, and still do update (from this
binary) to all Fedoras.
so "putting [the binary] onto some other system", "eg on super custom
opensuse", is exactly what you want to be able to do.
Not necessarily. In small project, sure, bundled libraries will get
rotten, but project like OpenJDK, where 99% of its builds uses the in tree
copies, can not allow itself to have security holes in them. It already
happened in past that we have switched to the in-tree library because the
CVE there was already fixed, and moved back to system library once the fix
landed to live Fedora.
There will necessarily be a delay between a security hole being fixed in a
commonly used library such as zlib or freetype and the fix making it into an
OpenJDK release.
And in the case you describe (where the system version is not fixed yet when
OpenJDK upstream is), switching to the bundled version is the wrong thing to
do, you need to get the security update to the Fedora library pushed out as
quickly as possible, so everything benefits from the security fix. (Maybe
you or another OpenJDK maintainer needs provenpackager privileges for that.)
> Applications linking against libraries SHOULD link against
shared
> libraries not static versions.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
right, should. So strictly from law of guidelines, there is no rule to
stop this change. The bundling was always bad, but is necessary evil.
SHOULD still means you need to justify why you want to do otherwise. I do
not see a valid reason in this case.
See eg rsync - the bundled zlib is there because it is technically
not
possible to use dynamic one.
In the rsync case, it is actually also disputed whether this is really
necessary (I doubt that there is really no better way to solve their
problem), but at least there is a concrete issue there, which (IIRC) is wire
compatibility of checksums of compressed blocks.
Java is in the border - yes, you can use the dynamic libraries (and
it
really took several excellent engineers a decade to manage), but it have
pros and cons. Unluckily, the negatives are multiplying for years.
Although we are not happy with the change, it must be done if JDKs should
remain maintained and healthy in Fedora. s
I have not seen any issues with the dynamic builds over years of using
Fedora OpenJDK RPMs for production use.
> And upstream only incorporates security fixes once per quarter
Right, but downstream works well too. If such vulnerability occurs, be
sure we will patch RPMs asap, and also upstream project - maybe without
release - will react to.
And that is a lot of work you are trying to commit to, in the same mail
where you are stating that you already have a hard time keeping up with the
workload in the current state. I do not see how you can realistically get
this done without significant delays for security fixes in the bundled
libraries, especially if you are going to wait for TCK results for each and
every security backport to a bundled library.
> In this case upstream might actually get there first because
this CVE
> is not yet fixed in Fedora
And it already happeed in past, that jdk swithced to bundled version for a
while, and back to dynamic once the library was fixed in live Fedora.
And as I wrote above, that is entirely the wrong way to go at it.
> This sounds fascinating. Can anyone share details about this?
On the
I'm aware of some codecs, which are built in Fedora, then the binary is
sent to .. cisco(?), and if passed, they are repacked into all live
fedoras.
OpenH264 is actually *not* part of Fedora, as Red Hat is not allowed to ship
it under the patent license, only Cisco is. So it gets built on the Fedora
Koji in an unpublished tag, shipped from there to Cisco, and Cisco releases
it in a third-party repository that is enabled by default in the Fedora
repository configuration (but can be disabled by the user, e.g., I have it
disabled because the FFmpeg H.264 decoder and the x264 encoder, both from
RPM Fusion, are simply the better H.264 implementations). That is a very
special arrangement that is due to patent issues.
I do not see how OpenJDK qualifies for such a special arrangement, and even
if it does, what you want is exactly the opposite of what OpenH264 is doing:
You want to get a build *into* Fedora repositories that is not built in the
respective Koji buildroot (it may be built in Koji, but you want to build it
once for all Fedora releases, so not in the release's buildroot), whereas
OpenH264 is actually built *in* the release's Koji buildroot and then
shipped *elsewhere*.
As super cornercase of this may be packing of some firmwares as
binary blobs.
This is an exception specific to firmware (it is treated as content, not
code), which explicitly does *not* apply to anything running on the CPU in
kernel space or user space.
> versions in an RPM sounds like it would violate all the
guidelines
> under $foo to meet this threshold and claim it needs to avoid
> rebuilding for certification?
Right, you need fesco exception.
And I sure hope it would not be granted, as I do not see a valid rationale
for such a blatant guideline violation at all.
> I'm very confused on why this reduces certification burden.
In our
> crypto libraries this is exactly the kind of behavior we would *NOT*
> want packages to do because it increases our certification and support
> burden.
I believe this are two things.
First - our burden. We ahve to certify each binary. This is quite long and
lenghty process. Onl once it is certified, we can release it (with small
unwritten exception in rawhide)
So with repacked portabel build as described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs will
allow us to certify once (and even stop hoping for that small exception in
rawhide). Considering 4 jdks in 3 maintianed fedoras, that is incredible
work. If it reduced to 4 we will manage again. Second - I can understand
that you certify your libray, but if others bundle it, then it is theirs
choice, and they are on thier own, arent they? Also you highlight crypto
lib, we are not going to embed any crypto library. Crypto is loaded in
runtime, and build time have no idea about future system in this case. Can
you please elaborate more if still needed?
Andrew Hughes says you actually do not have to certify each binary, so
logically one of you must be mistaken.
> I would rather have our shared maintenance and evolution of
font stuff
> be reused in Java too...
This is holy grail we have been pursuing for last 10 years. But now we
gave up. To keep java alive in Fedora, we have to take this one step back.
At that point, I do not see the value of keeping Java alive in Fedora at
all. Better work with Adoptium to get their builds into an RPM repository
(hosted by them), if this kind of vanilla all-bundled builds are what you
want.
And maybe if you orphan the Fedora RPM, someone might pick it up. As a
Fedora packager and OpenJDK user, I might even sign up to comaintain, though
the time I can spend on it is limited.
I think the whole Java SIG needs to be restarted from scratch anyway, as
there is very little left from the Java ecosystem that was once packaged in
Fedora. OpenJDK is almost the last piece that is remaining.
There alre already prcednets, and even worse things - like packing
blobish
binary driver, are here.
Fedora does *not* package binary driver blobs. We do package binary firmware
blobs. The distinction between a driver and a firmware is that the driver
runs on the CPU, the firmware runs on the peripheral. (Then there is the
early boot firmware that runs before the OS (UEFI/BIOS) or gets loaded at
early boot to fix CPU bugs (CPU microcode), those are special cases.)
OpenJDK is *not* firmware. (And for that matter, it is not a driver either.)
As described above, keeping dynamic jdk proeprly working requires
huge
maintainance. In addition, jdks are expected to be static (only
distribution rpms do differently, and thats why developers often unpack
3rd party static jdk to develop on)
I have been developing in Java for a living for more than 8 years now. I
have never needed any other JDK than the OpenJDK RPMs from the Fedora
repository. So I have no idea what developers you are talking about.
and have futures like generating standalone binary native images and
so,
which are impossible with dynamic linking. Future of java looks pointing
pretty stright forward to such changes, so we have to move to.
I take it that those "standalone binary native images" really just bundle a
static java binary with the bytecode into an executable?
And what if I want to build the code on Fedora for a customer running
Windows, can I do that with this feature? It does not sound like I can.
Where I work, some of us developers run GNU/Linux (several different
distributions, I run Fedora) and some run Windows, the customers typically
all run Windows (though of course we could easily support customers running
GNU/Linux, as we do have all the JNI libraries and wrapper scripts in place
for us GNU/Linux-using developers). The ability to build once and run
anywhere is one of the reasons we are using Java to begin with.
In any case, we have never used this feature at work so far. I was not even
aware that it exists at all. We deliver Java code in 2 ways: 1. as JARs in a
ZIP or tarball (for anything that needs to run on the customer's
infrastructure), or 2. as a web service in Tomcat hosted on our servers
(which run Debian and the OpenJDK and Tomcat from the standard Debian
repositories). For JARs we deliver to our customers, we require a systemwide
JRE installation (and we can point them to the Adoptium Windows binaries if
they need a specific recommendation – as I wrote above, the customers
typically run Windows).
Exactly. With one addition - the jdk will be indeed portable, you
should
be able to bring it to most of the system,and it should work. Still glibc
limitations remains here. To stand on the safe ground, "usual" non
distribution providers of openjdk simply builds on oldest possible
supported system.
Well yes, that is what I do for the JNI shared objects we ship, too (and
mock is a great tool for that). But if you want such a build, then use a
non-distro OpenJDK build, not a distro one.
> This is so bad. The final death of Java on Fedora.
Actually just a opposite. This is future of java and without it java in
fedora my diminish and fade away.
Has it not already? OpenJDK is essentially the last piece that is left and
your proposal would make that package entirely uninteresting and pointless
too (by making it no different from Adoptium Temurin and the like).
I personally really do not like this change, and I agree with all
rebukes
taken here. But current OpenJDK maintainers (which are the same for last
decade) do not see other way. If it will really go bad, we will withdraw
and continue fighting.
Maybe at this point withdrawing would be the most honest thing to do? IMHO,
we need either new people willing to bring the Java ecosystem (and that
includes Maven, Eclipse and its platform, NetBeans and its platform, etc.)
back to Fedora, following Fedora rules and guidelines, and not constantly
trying to work around them (see the module-only packages in the past, and
now this proposal and its followups), or we need to admit failure and just
drop Java from Fedora altogether (and focus on getting a third-party
repository delivering Adoptium Temurin binaries up ASAP as a replacement /
upgrade path).
Where you are right with the interpreters/jits not being exempt,
I'm
afraid yo do not see current flow of java - to self contained native
images, and to share OpenJDK marketpalce. Even if wesomhow will be able to
pathc jdk to live with
system libraries, which is already close to impossible, and drop all
features which allows generate portable images, the problem with the
certification will persists. It isnot in human powers to maintain 4 JDKS
in 3 Fedoras.
As I wrote above, if it is not feasible (with the available manpower) to
maintain OpenJDK properly in Fedora, then it needs to be dropped.
> And this plan is entirely unacceptable. It is just plain not
allowed in
> Fedora to ship prebuilt binary blobs (even if they are built by Fedora
> developers)
This is wrong. The JDK will be always build from sources in koji. The
main reduce of load will be that webuilt once in koji, in oldest Fedora,
and repack to newer.
Building once in Koji, extracting it, and then resending the resulting blob
to Koji for all releases is not how the Fedora workflow works and still
violates the "no prebuilt binaries" rule, even if the binary technically has
been built in some Koji buildroot at some point.
At most, you may be able to build in Koji and then get that exact build
*tagged* for the different releases (so you do not send blobs to Koji, you
just tell Koji that the build output tagged, say, f35-updates, should also
get tagged with f36-updates and f37), but I believe this is a kind of
hackery we also stopped doing long ago.
In additon there are many excludes in various binary drivers.
As I explained above, Fedora does not ship binary drivers.
I am only aware of exceptions of this kind having been granted (in the past)
for huge data files. Maybe also firmware. But by definition, these are not
CPU executables and hence building them on different Fedora releases will
(or at least should) produce identical results. This is not the case for
OpenJDK executables.
Also, those have been handled using the tagging approach I have described
above, so that really the exact same RPMs are used on all releases, and then
the files had even been hardlinked on the master mirror and on mirrors that
support it. Otherwise, there would have been no benefit from doing this at
all for those huge data files.
And as far as I can tell, we also no longer do this. E.g., the huge 0ad-data
is built separately for each release:
https://koji.fedoraproject.org/koji/packageinfo?packageID=14763
It is not as simple. You are right that to call it java yoou must
pass
tck. But unluckily even IcedTea had to pass TCK. Maybe it is possible to
patch out all "java" from it, but I doubt jdk will remain working and
usefull,.
(Disclaimer: The following is not legal advice, I am not a lawyer.) I do not
see why you would have to rename, e.g., the java and javac executables or
the java.* and javax.* packages. To my knowledge, legal reviews have ruled
several times in similar cases that this kind of executable or package names
is part of an API and not trademarkable. (I do not know whether this has
ever been tested in court.) The Oracle proprietary license places several
restrictions on what you can do with the java.* and javax.* packages, but we
use OpenJDK under the GPL, not under that license, so I do not see why those
non-free license restrictions would affect us in any way. So I think it
would be enough to just rename, e.g., java-11-openjdk to openjdk-11 (and you
could still Obsolete and Provide java-11-openjdk for an upgrade path) and
remove the word "Java" from Summary and Description.
The simple rename is not so easy. I "m afraid that striping all
"java"
from bnaries and thus from sources is maybe possbel to be done, but human
impossible to maintian, and will leave JDK mostly not working, and for
sure useless and incomaptible with other javas.
(Disclaimer: The following is not legal advice, I am not a lawyer.) You do
not need to strip any mentions of Java that are required for
interoperability (see, e.g., Sega v. Accolade). Nor do you need to strip any
uses of the trademark that are not user-visible at all.
> If current maintainers can't continue maintaining the
well-packaged
> OpenJDK, I think it's time to retire it. It would be better
Yes, we can no longer maintian it. And I must contradict you - Seeing all
the dependencies, we really need them all. Loosing any one, wiould kill
java ecosystemin Fedora.
What is still left from it other than OpenJDK to begin with? But yes, of
course, retiring OpenJDK would also require retiring all other remaining
Java packages. That is obvious.
>> JDKs from other vendors(Amazon, Azul, Oracle, etc.) are
built in
>> exactly this way. W
> Because they build it for all available GNU/Linux distributions. We
> shouldn't focus on bad practices.
Well and there are many reasons to do so, as jdk is designed to be like
this. for 10 years we tried to go against the main stream, and we managed
a lot. But to keep peace and compatibility and proper developer's support,
we have to move with mian stream now. The divergences we keep in rpms are
right now blocking devloeprs to use system jdsk as proper JDKs and are
enforcing them to download Amazon, Azul, Oracle, etc. blobs... To keep
Fedora competitive, this is currenlty necessary step.
Which developers? The divergences are sure not blocking me.
If some Java developers (or even end users) want the blobs, then they should
just use the blobs. Nothing is stopping them. I see no value whatsoever in
providing the same kind of static all-bundled builds disguised as native
Fedora packages.
Kevin Kofler
5:59 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Mon, May 16, 2022 at 6:55 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> wrote:
Jiri Vanek wrote:
> > This sounds fascinating. Can anyone share details about this? On the
> I'm aware of some codecs, which are built in Fedora, then the binary is
> sent to .. cisco(?), and if passed, they are repacked into all live
> fedoras.
OpenH264 is actually *not* part of Fedora, as Red Hat is not allowed to ship
it under the patent license, only Cisco is. So it gets built on the Fedora
Koji in an unpublished tag, shipped from there to Cisco, and Cisco releases
it in a third-party repository that is enabled by default in the Fedora
repository configuration (but can be disabled by the user, e.g., I have it
disabled because the FFmpeg H.264 decoder and the x264 encoder, both from
RPM Fusion, are simply the better H.264 implementations). That is a very
special arrangement that is due to patent issues.
I do not see how OpenJDK qualifies for such a special arrangement, and even
if it does, what you want is exactly the opposite of what OpenH264 is doing:
You want to get a build *into* Fedora repositories that is not built in the
respective Koji buildroot (it may be built in Koji, but you want to build it
once for all Fedora releases, so not in the release's buildroot), whereas
OpenH264 is actually built *in* the release's Koji buildroot and then
shipped *elsewhere*.
I want to make a very important clarification here: we build OpenH264
for *all* Fedora releases and have Cisco host those binary RPMs for
us. This arrangement means we are still making per-release builds and
releasing those back into Fedora.
--
真実はいつも一つ！/ Always, there's only one truth!
5:46 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Yo are right. Then probably the only precedent I have is shmi.
6:50 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Jiri Vanek wrote:
Unfortunately, your mail does not clarify all that much for me. I actually
see several contradictions, e.g.:
vs.
so "putting [the binary] onto some other system", "eg on super custom
opensuse", is exactly what you want to be able to do.
I do not see it as condradiction, But I agree it was poor formulation.
In rpm world, including the statically linked jdk, it is not a goal to have portable
/usr/lib/jvm/java*
But it will be a partially consequence, if the whole
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs is implemented. You will
be indeed able to copy that somewhere else. and it will work. But , repeating, it is not
a goal.
There will necessarily be a delay between a security hole being fixed in a
commonly used library such as zlib or freetype and the fix making it into an
OpenJDK release.
Really, not necessarily. As writen in this thread several times.
And in the case you describe (where the system version is not fixed yet when
OpenJDK upstream is), switching to the bundled version is the wrong thing to
do, you need to get the security update to the Fedora library pushed out as
quickly as possible, so everything benefits from the security fix. (Maybe
you or another OpenJDK maintainer needs provenpackager privileges for that.)
We can release for fedora nytime we need wish or need. Both from random hash in upstream
repo or from release tag with any custom patch on top of it. And we do it pretty commonly.
If needed, if there is necessary or interesting patch, or if it is simply demanded. RH
OpenJDK QA team is doing quite a good work in ensurring those remains healthy
SHOULD still means you need to justify why you want to do otherwise. I do
not see a valid reason in this case.
I agree, but to lower TCK rate to aprox 1/4 and to lower bug rate and cancelded features
becasue of dynamic linking should be enough.
In the rsync case, it is actually also disputed whether this is really
necessary (I doubt that there is really no better way to solve their
problem), but at least there is a concrete issue there, which (IIRC) is wire
compatibility of checksums of compressed blocks.
I have not seen any issues with the dynamic builds over years of using
Fedora OpenJDK RPMs for production use.
Right. Because throng of excellent engineers was taking care about it:)
And that is a lot of work you are trying to commit to, in the same mail
where you are stating that you already have a hard time keeping up with the
workload in the current state. I do not see how you can realistically get
this done without significant delays for security fixes in the bundled
libraries, especially if you are going to wait for TCK results for each and
every security backport to a bundled library.
Interesting point. You are right, that I wil be TCKing 1/4 of builds, but most likely 2x
or even 3x more often. Still it is aprox 1/2 of current load.
In addition, the higher ranking CVEs in the mentioned libraries - jpg, png... are very
rare.
Highlight - no crypto libraries will be bundled. They will remain dynamically loaded in
runtime, because you can swithc crypto providers. And each crypto provider have different
backend.
And as I wrote above, that is entirely the wrong way to go at it.
OpenH264 is actually *not* part of Fedora, as Red Hat is not allowed to ship
it under the patent license, only Cisco is. So it gets built on the Fedora
Koji in an unpublished tag, shipped from there to Cisco, and Cisco releases
it in a third-party repository that is enabled by default in the Fedora
repository configuration (but can be disabled by the user, e.g., I have it
disabled because the FFmpeg H.264 decoder and the x264 encoder, both from
RPM Fusion, are simply the better H.264 implementations). That is a very
special arrangement that is due to patent issues.
I do not see how OpenJDK qualifies for such a special arrangement, and even
if it does, what you want is exactly the opposite of what OpenH264 is doing:
You want to get a build *into* Fedora repositories that is not built in the
respective Koji buildroot (it may be built in Koji, but you want to build it
once for all Fedora releases, so not in the release's buildroot), whereas
OpenH264 is actually built *in* the release's Koji buildroot and then
shipped *elsewhere*.
This is an exception specific to firmware (it is treated as content, not
code), which explicitly does *not* apply to anything running on the CPU in
kernel space or user space.
And I sure hope it would not be granted, as I do not see a valid rationale
for such a blatant guideline violation at all.
Andrew Hughes says you actually do not have to certify each binary, so
logically one of you must be mistaken.
That sounds like misunderstending, becasue I'm the one whoruns them, and I run them
for all bninaries. If i'm reading the license wrongly allthose years, with support and
agreement from OpenJDK community, ..it would be nasty face palm.
At that point, I do not see the value of keeping Java alive in Fedora at
all. Better work with Adoptium to get their builds into an RPM repository
(hosted by them), if this kind of vanilla all-bundled builds are what you
want.
That is very close to the final state of things:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
There is an effort of identical reproducible binaries in openjdk usptream. That says,
that
you build on several systems identical binaries, and thus you can TCK only one of them.
That was created by co work of Red hat, Debian, Adotpium and others, to solve the TCK
issue.
Still I'm afraid it will never work properly with dynamic linking.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
So in ideal world, fedora, debia, adoptium.. will share identical binary, buuilt in theirs
own build root. There is still long run to ideal world.
And maybe if you orphan the Fedora RPM, someone might pick it up. As a
Fedora packager and OpenJDK user, I might even sign up to comaintain, though
the time I can spend on it is limited.
For your own sanity, dont do that. But seeing this discussion, it may evolve like this.
I think the whole Java SIG needs to be restarted from scratch anyway, as
there is very little left from the Java ecosystem that was once packaged in
Fedora. OpenJDK is almost the last piece that is remaining.
Fabio did severe attempt todo so. I had best intentions to support him. Forsome reason it
do nto work. Meybe to much live versions of to much to small dependencies. But python
world is similar. HArd to say what is so wrong.
Fedora does *not* package binary driver blobs. We do package binary firmware
blobs. The distinction between a driver and a firmware is that the driver
runs on the CPU, the firmware runs on the peripheral. (Then there is the
early boot firmware that runs before the OS (UEFI/BIOS) or gets loaded at
early boot to fix CPU bugs (CPU microcode), those are special cases.)
OpenJDK is *not* firmware. (And for that matter, it is not a driver either.)
You are right, sorry for bad formualtion. I ment firmware.
Also you are right that openjdk is not an firmware.
Still it may be granted an exception based on certification reasons and on furhter
viability of OpenJDK.
If I wouldbe nitpicking, both openjdk and firnmware runss directly in on iron :) /joke
I have been developing in Java for a living for more than 8 years now. I
have never needed any other JDK than the OpenJDK RPMs from the Fedora
repository. So I have no idea what developers you are talking about.
jimage? Grail vm and MAndrel/Quarkus?
I take it that those "standalone binary native images" really just bundle a
static java binary with the bytecode into an executable?
Moreover correct.
And what if I want to build the code on Fedora for a customer running
Windows, can I do that with this feature? It does not sound like I can.
Where I work, some of us developers run GNU/Linux (several different
distributions, I run Fedora) and some run Windows, the customers typically
all run Windows (though of course we could easily support customers running
GNU/Linux, as we do have all the JNI libraries and wrapper scripts in place
for us GNU/Linux-using developers). The ability to build once and run
anywhere is one of the reasons we are using Java to begin with.
You are describing it pretty well. And from your comment one would guess why would anyody
need and native image. Still they does. And I would like to no longer exclude this feature
from Fedora.
In any case, we have never used this feature at work so far. I was not even
aware that it exists at all. We deliver Java code in 2 ways: 1. as JARs in a
ZIP or tarball (for anything that needs to run on the customer's
infrastructure), or 2. as a web service in Tomcat hosted on our servers
(which run Debian and the OpenJDK and Tomcat from the standard Debian
repositories). For JARs we deliver to our customers, we require a systemwide
JRE installation (and we can point them to the Adoptium Windows binaries if
they need a specific recommendation – as I wrote above, the customers
typically run Windows).
Well yes, that is what I do for the JNI shared objects we ship, too (and
mock is a great tool for that). But if you want such a build, then use a
non-distro OpenJDK build, not a distro one.
Right, sometimes non-distro jdk is necessary. So why nt to have proper distro-jdk, which
will allow you to do all?
Has it not already? OpenJDK is essentially the last piece that is left and
your proposal would make that package entirely uninteresting and pointless
too (by making it no different from Adoptium Temurin and the like).
Except being part of fedora and thus in koji build root.
Maybe at this point withdrawing would be the most honest thing to do? IMHO,
we need either new people willing to bring the Java ecosystem (and that
includes Maven, Eclipse and its platform, NetBeans and its platform, etc.)
back to Fedora, following Fedora rules and guidelines, and not constantly
trying to work around them (see the module-only packages in the past, and
now this proposal and its followups), or we need to admit failure and just
drop Java from Fedora altogether (and focus on getting a third-party
repository delivering Adoptium Temurin binaries up ASAP as a replacement /
upgrade path).
That may be an option. Thank you for seyng it clearly.
7:11 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 16/05/2022 21:13, Jiri Vanek wrote:
Not necessarily. In small project, sure, bundled libraries will get
rotten, but project like OpenJDK, where 99% of its builds uses the in
tree copies, can not allow itself to have security holes in them.
Not true. Popular packages like freetype, fontconfig, zlib are always
getting patched in Fedora soon. OpenJDK will only receive a patch in 2-3
months when a new patch version is released.
This is probably main issue we are aware about. Especially the system
configuration will be a hard issue, if solvable at all.
This will make the user's eyes bleed.
However IIRC, those features do nor work properly in java event hose
days, as java have to support all what lies below, and it simply can not, so the intree
libraries come to play.
OpenJDK 17 respects system configuration after adding the following
lines to the ~/.bashrc file:
export _JAVA_OPTIONS="-Dawt.useSystemAAFontSettings=lcd
-Dswing.aatext=true
-Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel
-Dswing.crossplatformlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel"
Note that we had to patch jdk in past to work properly after changes
in the system libraries. And that is not easy task.
Someone needs to grab the font patches from the JetBrains JRE fork and
upstream them.
But the current configuration of OpenJDK 17 on Fedora 36 also looks good
after changing _JAVA_OPTIONS as mentioned above.
The bundling was always bad, but is necessary evil.
No. I don't think so. Bundling is always evil and should be avoided as
much as possible.
See eg rsync - the bundled zlib is there because it is technically
not possible to use dynamic one.
"technically not possible" vs. "we just don't want to do additional
work".
Unluckily, the negatives are multiplying for years. Although we are
not happy with the change, it must be done if JDKs should remain maintained and healthy in
Fedora.
I've been using OpenJDK on Fedora for ages with NetBeans and even IDEA
and everything works great.
Right, but downstream works well too. If such vulnerability occurs,
be sure we will patch RPMs asap, and also upstream project - maybe without release - will
react to.
And maybe not and OpenJDK will be vulnerable for months until the next
release is out.
I'm aware of some codecs, which are built in Fedora, then the
binary is sent to .. cisco(?), and if passed, they are repacked into all live fedoras.
Fedora builds openh264 from sources for each supported Fedora release
and then submits RPMs to Cisco, because due to the legal reasons only
Cisco can redistribute it.
As super cornercase of this may be packing of some firmwares as
binary blobs.
Firmware is executed directly on the hardware and provided by manufacturers.
All software must be built from sources. No blobs are allowed.
Right, you need fesco exception.
I hope this exception is never granted.
First - our burden. We ahve to certify each binary. This is quite
long and lenghty process. Onl once it is certified, we can release it (with small
unwritten exception in rawhide)
Just stop doing TCK certification. Most of Fedora users don't need
"certified binaries".
Future of java looks pointing pretty stright forward to such changes,
so we have to move to.
There are no future after such destructive changes.
Actually just a opposite. This is future of java and without it java
in fedora my diminish and fade away. I personally really do not like this change, and I
agree with all rebukes taken here. But current OpenJDK maintainers (which are the same for
last decade) do not see other way.
If it will really go bad, we will withdraw and continue fighting.
The Java stack on Fedora is almost dead. We've already lost 99% of
popular Java applications: NetBeans, Eclipse, IDEA, etc.
This is wrong. The JDK will be always build from sources in koji.
The main reduce of load will be that webuilt once in koji, in oldest Fedora, and repack to
newer.
Rebuilding prebuilt binaries != building from sources. This is strictly
prohibited.
Quite a few packages are dleivered as blobs... Still. Be sure we are
NOT going to do that > In additon there are many excludes in various binary drivers.
Lie. Fedora doesn't have any binary drivers in repositories. All Fedora
packages (except linux-firmware) are built from sources without network
access.
To keep Fedora competitive, this is currenlty necessary step.
Fedora currently has the best OpenJDK builds.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:36 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, 17 May 2022 at 08:11, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
On 16/05/2022 21:13, Jiri Vanek wrote:
> Quite a few packages are dleivered as blobs... Still. Be sure we are NOT
going to do that > In additon there are many excludes in various binary
drivers.
Lie. Fedora doesn't have any binary drivers in repositories. All Fedora
packages (except linux-firmware) are built from sources without network
access.
I am going to ask you once to dial back your rhetoric. Calling people liars
for having definitions of firmware and drivers isn't helpful to this
conversation.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:30 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 17/05/2022 14:36, Stephen Smoogen wrote:
I am going to ask you once to dial back your rhetoric. Calling people
liars for having definitions of firmware and drivers isn't helpful to
this conversation.
I've never called people liars in this thread. Just said that the quoted
statement isn't true, i.e. lies.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:47 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tuesday, 17 May 2022 at 16:30, Vitaly Zaitsev via devel wrote:
On 17/05/2022 14:36, Stephen Smoogen wrote:
> I am going to ask you once to dial back your rhetoric. Calling people
> liars for having definitions of firmware and drivers isn't helpful to
> this conversation.
I've never called people liars in this thread. Just said that the quoted
statement isn't true, i.e. lies.
Then call it "incorrect". Saying it's a lie implies intent to mislead,
while there obviously was none.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
9:41 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 13:47, Dominik 'Rathann' Mierzejewski wrote:
Then call it "incorrect". Saying it's a lie implies
intent to mislead,
while there obviously was none.
Saying "lie" means "not true".
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:04 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, 18 May 2022 at 10:41, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
On 18/05/2022 13:47, Dominik 'Rathann' Mierzejewski wrote:
> Then call it "incorrect". Saying it's a lie implies intent to
mislead,
> while there obviously was none.
Saying "lie" means "not true".
It generally means and is interpreted as 'not true with the intention of
deceiving'. 'incorrect' is considered 'not true'.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
10:18 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 17:04, Stephen Smoogen wrote:
It generally means and is interpreted as 'not true with the
intention of
deceiving'. 'incorrect' is considered 'not true'.
The Oxford English Dictionary gives the following answer:
lie (noun) - an intentionally false statement
used with reference to a situation involving deception or founded on a
mistaken impression
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:46 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote:
On 18/05/2022 17:04, Stephen Smoogen wrote:
> It generally means and is interpreted as 'not true with the intention of
> deceiving'. 'incorrect' is considered 'not true'.
The Oxford English Dictionary gives the following answer:
lie (noun) - an intentionally false statement
used with reference to a situation involving deception or founded on a
mistaken impression
Exactly. So, you implied malicious intent where there was none.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
7:54 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:46, Dominik 'Rathann' Mierzejewski wrote:
Exactly. So, you implied malicious intent where there was none.
we don't know for sure.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:21 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
It is not so bad. and I definitely do not feel offended or even close to.
Many languages have very interesting words which go far beyond true/false untrue/not
false/ correct/incorrect right/left/lie
Thus saying many languages can not match to other langunages meaning of simple true/false
right/left/lie 1:1
And even if they can, there remain cases which only native speaker can recognize.
Thus saying, I was wrong write down driver, where I meant firmware. I was wrong and am
happy for correction.
It was sure form begining that this proposal will rise emotions - some one wrote it
perfectly: clash of cultures. And will take bilions of liens to explain.
And where it indeed rised a lot of emotions, lets leave the language details, and lets
turn back to topic.
Still thanx a lot alle, ven for this part language corner part. it was educative.
J.
On 5/20/22 14:46, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote:
> On 18/05/2022 17:04, Stephen Smoogen wrote:
>> It generally means and is interpreted as 'not true with the intention of
>> deceiving'. 'incorrect' is considered 'not true'.
>
> The Oxford English Dictionary gives the following answer:
>
> lie (noun) - an intentionally false statement
> used with reference to a situation involving deception or founded on a
> mistaken impression
Exactly. So, you implied malicious intent where there was none.
Regards,
Dominik
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
11:26 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Wednesday, 18 May 2022 15:41:17 BST Vitaly Zaitsev via devel wrote:
On 18/05/2022 13:47, Dominik 'Rathann' Mierzejewski wrote:
> Then call it "incorrect". Saying it's a lie implies intent to
mislead,
> while there obviously was none.
Saying "lie" means "not true".
In English, "lie" means "a statement made by someone knowing it is
not true".
It carries with it the idea that the person making the false statement knew it
was false, but claimed it was true anyway.
"Incorrect" or "not true" do not carry the implication that the person
making
the statement knew it was false.
--
Simon Farnsworth
11:48 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 18:26, Simon Farnsworth wrote:
In English, "lie" means "a statement made by someone
knowing it is not true".
It carries with it the idea that the person making the false statement knew it
was false, but claimed it was true anyway.
True, but we don't know for sure was it a mistake or an attempt to
justify inclusion of prebuilt blobs.
If this offended anyone, I apologize.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:45 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/17/22 08:11, Vitaly Zaitsev via devel wrote:
> Quite a few packages are dleivered as blobs... Still. Be sure we
are NOT going to do that > In additon there are many excludes in various binary
drivers.
Lie. Fedora doesn't have any binary drivers in repositories. All Fedora
packages (except linux-firmware) are built from sources without network
access.
I don’t think this was a lie. Whether or not it was accurate,
there was no malicious intent.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
9:20 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 02:11:03PM +0200, Vitaly Zaitsev via devel wrote:
> First - our burden. We ahve to certify each binary. This is
quite long
> and lenghty process. Onl once it is certified, we can release it (with
> small unwritten exception in rawhide)
Just stop doing TCK certification. Most of Fedora users don't need
"certified binaries".
Exactly. This change does not benefit Fedora, it is only to make
certification easier. Certification which is not needed.
--
Tomasz Torcz “(…) today's high-end is tomorrow's embedded processor.”
tomek(a)pipebreaker.pl — Mitchell Blank on LKML
10:08 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 04:20:56PM +0200, Tomasz Torcz wrote:
On Tue, May 17, 2022 at 02:11:03PM +0200, Vitaly Zaitsev via devel
wrote:
> > First - our burden. We ahve to certify each binary. This is quite long
> > and lenghty process. Onl once it is certified, we can release it (with
> > small unwritten exception in rawhide)
>
> Just stop doing TCK certification. Most of Fedora users don't need
> "certified binaries".
Exactly. This change does not benefit Fedora, it is only to make
certification easier. Certification which is not needed.
At its heart the certification is a "sticker" that asserts our
JDK has passed the TCK test suite. IOW, saying that we don't need
certification of JDK is effectively saying that we don't need to do
testing of JDK in Fedora. Comprehensive testing of software is
something that very much does benefit Fedora and its users, and we
could do with a whole lot more of it in general. Further elsewhere
in this thread it has been clearly said that users of JDKs do
indeed value the certification as a sign of quality. So I don't
think we can credibly claim that certification is not needed.
The challenege is how to make the certification managable for the
maintainers, while also having the packaging process be amenable
to Fedora processes. Eliminating testing of JDK is not a desirable
solution.
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 :|
10:17 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 5:09 PM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Tue, May 17, 2022 at 04:20:56PM +0200, Tomasz Torcz wrote:
> On Tue, May 17, 2022 at 02:11:03PM +0200, Vitaly Zaitsev via devel wrote:
> > > First - our burden. We ahve to certify each binary. This is quite long
> > > and lenghty process. Onl once it is certified, we can release it (with
> > > small unwritten exception in rawhide)
> >
> > Just stop doing TCK certification. Most of Fedora users don't need
> > "certified binaries".
>
> Exactly. This change does not benefit Fedora, it is only to make
> certification easier. Certification which is not needed.
At its heart the certification is a "sticker" that asserts our
JDK has passed the TCK test suite. IOW, saying that we don't need
certification of JDK is effectively saying that we don't need to do
testing of JDK in Fedora.
Correct me if I'm wrong in that specific case, but, purely logically,
"certification implies some testing" doesn't imply
"lack of certification abolishes all testing".
Comprehensive testing of software is
something that very much does benefit Fedora and its users, and we
could do with a whole lot more of it in general. Further elsewhere
in this thread it has been clearly said that users of JDKs do
indeed value the certification as a sign of quality. So I don't
think we can credibly claim that certification is not needed.
The challenege is how to make the certification managable for the
maintainers, while also having the packaging process be amenable
to Fedora processes. Eliminating testing of JDK is not a desirable
solution.
10:17 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 17, 2022 at 11:09 AM Daniel P. Berrangé <berrange(a)redhat.com> wrote:
On Tue, May 17, 2022 at 04:20:56PM +0200, Tomasz Torcz wrote:
> On Tue, May 17, 2022 at 02:11:03PM +0200, Vitaly Zaitsev via devel wrote:
> > > First - our burden. We ahve to certify each binary. This is quite long
> > > and lenghty process. Onl once it is certified, we can release it (with
> > > small unwritten exception in rawhide)
> >
> > Just stop doing TCK certification. Most of Fedora users don't need
> > "certified binaries".
>
> Exactly. This change does not benefit Fedora, it is only to make
> certification easier. Certification which is not needed.
At its heart the certification is a "sticker" that asserts our
JDK has passed the TCK test suite. IOW, saying that we don't need
certification of JDK is effectively saying that we don't need to do
testing of JDK in Fedora. Comprehensive testing of software is
something that very much does benefit Fedora and its users, and we
could do with a whole lot more of it in general. Further elsewhere
in this thread it has been clearly said that users of JDKs do
indeed value the certification as a sign of quality. So I don't
think we can credibly claim that certification is not needed.
The challenege is how to make the certification managable for the
maintainers, while also having the packaging process be amenable
to Fedora processes. Eliminating testing of JDK is not a desirable
solution.
I agree here. I don't know what the problems are with the TCK, though.
Is it something we can solve with automation? Is it something we need
more upstream engagement on? I'm not sure what we need. I've asked a
couple of times in this thread, I'm waiting for a response from the
proposal owners.
I'm also closely tracking the efforts around Project Wakefield, and
I'd rather not lose an opportunity to have that in Fedora ASAP because
we've stopped building for multiple Fedora releases.
--
真実はいつも一つ！/ Always, there's only one truth!
10:55 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite
complicated setup. The pull and setup and run is completely autoamted, but it is a lot of
HW you need (all architecures x all oses x all jdks). In adition, you need human power to
keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails...
and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with
usptream and TCK evolution. But it is not easy from human resources point of view.
11:01 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 11:55 AM jiri vanek <jvanek(a)redhat.com> wrote:
You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite
complicated setup. The pull and setup and run is completely autoamted, but it is a lot of
HW you need (all architecures x all oses x all jdks). In adition, you need human power to
keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails...
and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with
usptream and TCK evolution. But it is not easy from human resources point of view.
At this point, I'd rather have an OpenJDK in Fedora than not. If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.
Can we do this without going down the route of building only once at
one distribution tag and tagging the binary into everything else?
--
真実はいつも一つ！/ Always, there's only one truth!
11:22 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 6:04 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, May 18, 2022 at 11:55 AM jiri vanek <jvanek(a)redhat.com> wrote:
>
> You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite
complicated setup. The pull and setup and run is completely autoamted, but it is a lot of
HW you need (all architecures x all oses x all jdks). In adition, you need human power to
keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails...
and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with
usptream and TCK evolution. But it is not easy from human resources point of view.
At this point, I'd rather have an OpenJDK in Fedora than not. If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.
Can we do this without going down the route of building only once at
one distribution tag and tagging the binary into everything else?
I agree. Can we discuss alternative routes to reduce maintenance
burden for OpenJDK than what you're currently planning for the long
term?
Maybe we can think about whether it's absolutely necessary to keep
maintaining three different LTS versions of OpenJDK? Dropping at least
java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK
packages by over 25% (given that 1.8.0 seems to cause you most of the
problems recenty).
If statically linking against bundled versions of *some* dependencies
would really help that much, it might also be worth considering, as a
last resort, to keep OpenJDK packages in Fedora at all.
However, I personally am strongly against the "follow-up" proposal,
MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known
issues" section on this wiki page sounds to me like it should be
completely out of the question to actually go forward with the
proposal.
Some time ago, jiri vanek <jvanek(a)redhat.com> wrote:
We realy do no like this change, but we do not see another way.
I wonder how this happened? Has this issue been brewing for a while?
Or will Red Hat be downsizing the OpenJDK team in the near future? ;)
Fabio
7:26 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:22, Fabio Valentini wrote:
On Wed, May 18, 2022 at 6:04 PM Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
> On Wed, May 18, 2022 at 11:55 AM jiri vanek <jvanek(a)redhat.com> wrote:
>>
>> You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with
quite complicated setup. The pull and setup and run is completely autoamted, but it is a
lot of HW you need (all architecures x all oses x all jdks). In adition, you need human
power to keep with TCK evolution, sometimes to dapt setup, and to check resutls if they
fails... and.. to fix it. We have HW from Red hat, and we deal with failures we keep track
with usptream and TCK evolution. But it is not easy from human resources point of view.
>
> At this point, I'd rather have an OpenJDK in Fedora than not. If that
> means switching to bundled libraries, then fine. But all bundled
> libraries need to be documented in the spec file and that information
> needs to be kept up to date.
>
> Can we do this without going down the route of building only once at
> one distribution tag and tagging the binary into everything else?
I agree. Can we discuss alternative routes to reduce maintenance
burden for OpenJDK than what you're currently planning for the long
term?
thanx for this understanidng:(
Maybe we can think about whether it's absolutely necessary to keep
maintaining three different LTS versions of OpenJDK? Dropping at least
java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK
packages by over 25% (given that 1.8.0 seems to cause you most of the
problems recenty).
This would of course help, but I would rahter keep 4 different jdks packed once, then 1
jdk packed 4 times.
Still we will need to maintain usually 1, but very opften two system jdks, and we will
need to continue maintain java-latest-openjdk as we need it to bootsrap next main jdk.
Also we need java-lates-opnjdk live in release, not jsut in buidlroot, so we can tune
integration of future jdk fluently.
If statically linking against bundled versions of *some* dependencies
would really help that much, it might also be worth considering, as a
last resort, to keep OpenJDK packages in Fedora at all.
However, I personally am strongly against the "follow-up" proposal,
MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known
issues" section on this wiki page sounds to me like it should be
completely out of the question to actually go forward with the
proposal.
We are going to fix known issue. Unless the known issues are solved, we can not continue.
All except debuginfo are somehow solvable.
Can you please enumerate what parts of known issues toruel syou most? that would be super
valuable information.
I rate them all moreover in same level, as anoying, but really fixable (not jsut
workaround-able) for common benefit.
> Some time ago, jiri vanek <jvanek(a)redhat.com> wrote:
> We realy do no like this change, but we do not see another way.
I wonder how this happened? Has this issue been brewing for a while?
We have the issues which led to this proposal since jdk 11 appeared in fedora. The issue
was unluckily not getting away, and was jsut getting worse, until this proposal occured.
Or will Red Hat be downsizing the OpenJDK team in the near future? ;)
nope, but the multiplying of JDK employees is unluckily nor following multiplying of
JDKs...
Fabio
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
11:32 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 18:01, Neal Gompa wrote:
At this point, I'd rather have an OpenJDK in Fedora than not. If
that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.
They also want to bundle pre-built binaries into dependent packages.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:28 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:32, Vitaly Zaitsev via devel wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On 18/05/2022 18:01, Neal Gompa wrote:
> At this point, I'd rather have an OpenJDK in Fedora than not. If that
> means switching to bundled libraries, then fine. But all bundled
> libraries need to be documented in the spec file and that information
> needs to be kept up to date.
They also want to bundle pre-built binaries into dependent packages.
wait, what? What do you mean? And waht give you this impression?
Or are you already in the follwoing year, when the attempt will be doen to build each JDK
in koji just once, and ship it to al llive fedoras?
7:57 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:28, Jiri Vanek wrote:
wait, what? What do you mean? And waht give you this impression?
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
Make the normal rpms to not built jdk, but to repack the portable
rpms with all integration
Or are you already in the follwoing year, when the attempt will be
doen to build each JDK in koji just once, and ship it to al llive fedoras?
Repackaging of anything even it was built in Koji is strictly
prohibited. All packages must be built from sources. No exceptions.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:22 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On 20/05/2022 14:28, Jiri Vanek wrote:
> wait, what? What do you mean? And waht give you this impression?
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
> Make the normal rpms to not built jdk, but to repack the portable rpms with all
integration
thanx.
> Or are you already in the follwoing year, when the attempt will be doen to build each
JDK in koji just once, and ship it to al llive fedoras?
Repackaging of anything even it was built in Koji is strictly prohibited. All packages
must be built from sources. No exceptions.
shim?
6:22 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On 20/05/2022 14:28, Jiri Vanek wrote:
> wait, what? What do you mean? And waht give you this impression?
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
> Make the normal rpms to not built jdk, but to repack the portable rpms with all
integration
thanx.
> Or are you already in the follwoing year, when the attempt will be doen to build each
JDK in koji just once, and ship it to al llive fedoras?
Repackaging of anything even it was built in Koji is strictly prohibited. All packages
must be built from sources. No exceptions.
shim?
6:38 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Sat, May 21, 2022 at 7:28 AM Jiri Vanek <jvanek(a)redhat.com> wrote:
On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:
> On 20/05/2022 14:28, Jiri Vanek wrote:
>> wait, what? What do you mean? And waht give you this impression?
>
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
>
> > Make the normal rpms to not built jdk, but to repack the portable rpms with
all integration
thanx.
>
>> Or are you already in the follwoing year, when the attempt will be doen to build
each JDK in koji just once, and ship it to al llive fedoras?
>
> Repackaging of anything even it was built in Koji is strictly prohibited. All
packages must be built from sources. No exceptions.
shim?
Shim is technically built on Fedora infrastructure as shim-unsigned.
Microsoft signs that binary and the shim package has those binaries as
sources in that package.
OpenJDK is not that strict, and frankly I don't think we'd want to do
more than just that package that way. It's a massive pain and it's
pretty evident that this arrangement causes us serious problems too,
since it locks the Fedora community out of fixing issues at that
level.
--
真実はいつも一つ！/ Always, there's only one truth!
9:59 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/21/22 13:38, Neal Gompa wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On Sat, May 21, 2022 at 7:28 AM Jiri Vanek <jvanek(a)redhat.com>
wrote:
>
>
>
> On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:
>> On 20/05/2022 14:28, Jiri Vanek wrote:
>>> wait, what? What do you mean? And waht give you this impression?
>>
>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
>>
>> > Make the normal rpms to not built jdk, but to repack the portable rpms
with all integration
>
> thanx.
>
>>
>>> Or are you already in the follwoing year, when the attempt will be doen to
build each JDK in koji just once, and ship it to al llive fedoras?
>>
>> Repackaging of anything even it was built in Koji is strictly prohibited. All
packages must be built from sources. No exceptions.
>
> shim?
Shim is technically built on Fedora infrastructure as shim-unsigned.
Microsoft signs that binary and the shim package has those binaries as
sources in that package.
OpenJDK is not that strict, and frankly I don't think we'd want to do
more than just that package that way. It's a massive pain and it's
pretty evident that this arrangement causes us serious problems too,
since it locks the Fedora community out of fixing issues at that
level.
Hm. For "silent observer" (in case of shmi and codecs) the burden seemed not so
high, But as Kevinlater described, it was a bit underestimated.
6:51 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 21/05/2022 13:22, Jiri Vanek wrote:
shim?
Built on Koji from sources as shim-unsigned, then uploaded to Microsoft
for signing.
This is a special legal case, just like openh264 and Cisco.
Both of them built from sources on Fedora infra.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:40 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
So, just replying here since this is a nice monster of a thread. ;(
First, just to clear up some previous coments, shim does build against
the oldest stable Fedora in koji and then is manually tagged into newer
ones. This is not at all a good process. It only gets a bodhi update for
the one release (and sometimes not even that), so it never gets good
testing. It requires manual intervention from releng each time there's
an update. I think the only reason this has kept going is that shim is
very small and simple and updates rarely. If we need to do this for tons
of openjdk updates, we really should revisit the process, although I am
not sure how to make it more open to testing and less a burden on
releng. ;(
Next, My understanding of the current process for openjdks (openjdki?):
for each openjdk:
Build dyanmically linking against system libraries in all fedoras.
Submit to TCK and wait for them all to process.
Fix any TCK failures and repeat
Once there's no failures, push the builds to updates
Is that right? And keeping the dynamic builds passing is taking more
cycles than you have to give for the number of jdks?
What about the possibility of adding CI _upstream_ to test against the
dynamic version? Then TCK failures would be caught upstream and not
downstream where it's a lot of work for you to fix?
Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?
I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.
Thanks,
kevin
9:57 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/23/22 20:40, Kevin Fenzi wrote:
So, just replying here since this is a nice monster of a thread. ;(
First, just to clear up some previous coments, shim does build against
the oldest stable Fedora in koji and then is manually tagged into newer
ones. This is not at all a good process. It only gets a bodhi update for
the one release (and sometimes not even that), so it never gets good
testing. It requires manual intervention from releng each time there's
an update. I think the only reason this has kept going is that shim is
very small and simple and updates rarely. If we need to do this for tons
of openjdk updates, we really should revisit the process, although I am
not sure how to make it more open to testing and less a burden on
releng. ;(
Thanx for bringing up additional details!
Next, My understanding of the current process for openjdks (openjdki?):
for each openjdk:
Build dyanmically linking against system libraries in all fedoras.
Submit to TCK and wait for them all to process.
Fix any TCK failures and repeat
Once there's no failures, push the builds to updates
Is that right? And keeping the dynamic builds passing is taking more
cycles than you have to give for the number of jdks?
super correct.
What about the possibility of adding CI _upstream_ to test against the
dynamic version? Then TCK failures would be caught upstream and not
downstream where it's a lot of work for you to fix?
We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so we have to.
But that is much easier, as the usptream is static within intree libraries. And we have to
run also for 17 and 18/19 as we need this reference run,
to be sure that downstream is guilty, not vanilla jdk. Thus we test the (source x build)
just once. And we can test the binary on some known system where we always pass.
But in downstream, new issues usually appear due to the dynamic linking and nature of
system where only it can be installed. Also for dowstram, each sources are built N times,
so N times tested in thsoe N systems - usually each with its
psecific failures.
Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?
As I described in another reply, it is both human and hw. Hw to run all those swarm of
builds on all platforms, and humans to verify the issue and to fix it.
TCK are very complex, and you need at least three machines in distributed system to run
them. At least two of those slaves are not trivial (krb master and system where tck are
running).
Generally saying, I have autoamtion to prepare that all, but second part is
reproducibility. If the "non mine" setup run will fail for some reason, can I
rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.
I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.
I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4
years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs
it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next system JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17.
Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be
felt by fedora users more, then having static jdk from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as
secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks
x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but usually
the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for
backport, and 49 for not. Even with knwoledge of TCK burden.
If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
With this shortage, we would have
2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That sound like a
reasonable drop, but only for very short period of time, duriong which we will nee to have
capcity reserved for ppreparation of next
system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, With much
more stress about possible integration issues and with - imo(!) - considerable negative
imapct to fedora.
TYVM!
1:48 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 10:57, Jiri Vanek wrote:
On 5/23/22 20:40, Kevin Fenzi wrote:
> So, just replying here since this is a nice monster of a thread. ;(
>
> First, just to clear up some previous coments, shim does build against
> the oldest stable Fedora in koji and then is manually tagged into newer
> ones. This is not at all a good process. It only gets a bodhi update for
> the one release (and sometimes not even that), so it never gets good
> testing. It requires manual intervention from releng each time there's
> an update. I think the only reason this has kept going is that shim is
> very small and simple and updates rarely. If we need to do this for tons
> of openjdk updates, we really should revisit the process, although I am
> not sure how to make it more open to testing and less a burden on
> releng. ;(
Thanx for bringing up additional details!
>
> Next, My understanding of the current process for openjdks (openjdki?):
>
> for each openjdk:
>
> Build dyanmically linking against system libraries in all fedoras.
> Submit to TCK and wait for them all to process.
> Fix any TCK failures and repeat
> Once there's no failures, push the builds to updates
>
> Is that right? And keeping the dynamic builds passing is taking more
> cycles than you have to give for the number of jdks?
super correct.
>
> What about the possibility of adding CI _upstream_ to test against the
> dynamic version? Then TCK failures would be caught upstream and not
> downstream where it's a lot of work for you to fix?
We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so we have to.
But that is much easier, as the usptream is static within intree libraries. And we have
to run also for 17 and 18/19 as we need this reference run,
to be sure that downstream is guilty, not vanilla jdk. Thus we test the (source x build)
just once. And we can test the binary on some known system where we always pass.
But in downstream, new issues usually appear due to the dynamic linking and nature of
system where only it can be installed. Also for dowstram, each sources are built N times,
so N times tested in thsoe N systems - usually each with its
psecific failures.
Kevin’s suggestion is for upstream to test dynamic builds, not just
static ones, in its CI. That means that if the dynamic build breaks,
it would be upstream’s problem.
In other words: Instead of shipping a static JDK in Fedora, make the
dynamic JDK a first-class citizen upstream.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
3:02 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4
years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs
it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next system
JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17.
Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be
felt by fedora users more, then having static jdk from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as
secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks
x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but usually
the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for
backport, and 49 for not. Even with knwoledge of TCK burden.
Is this based on user requests, or is this only what you *think* users
of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.
What would you think about the following scenario:
- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases
You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.
This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:
- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk
With much more stress about possible integration issues and with -
imo(!) - considerable negative imapct to fedora.
Would this reduced set of supported OpenJDK versions, but keeping the
"latest" version, address this "considerable negative impact"?
Fabio
8:16 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 22:02, Fabio Valentini wrote:
Thanx a lot!
J.
On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jvanek(a)redhat.com>
wrote:
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in
some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It
needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next system
JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and
17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will
be felt by fedora users more, then having static jdk from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it
as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3
jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, but
usually the users want us to do so. tbh, I do not have strong preference on it. it is like
51 for backport, and 49 for not. Even with knwoledge of TCK burden.
Is this based on user requests, or is this only what you *think* users
I'm not sure what you mean - from above - what is based on mine/wider thinking
Generally waht I wrote here it is based on judgmeent of about 10 people around OpenJDK
pacages in Fedora.
The equations above are based on realistic view and experience. Do you yo find some
misscalcualtion above?
I really appreciate you opinions, and would be happyt answer more precisely.
of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.
Are you really sure? Many applications runtime requiter non system jdk, so they pull it
in and use, and maybe you have not even noticed.
Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I need to
compile jimage) and the switch as needed.
What would you think about the following scenario:
- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases
This is possible solution. It will lower the TCK burden to aprox 3/5 with lost of most
widely used JDKs from repositories.
I'm open to this proposal. But the removal will hurt and way back will be much harder
then swithing static builds back to dynamic.
You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.
Taht is very valid point. Cost is it will force huge number of uses to download 3rd party
latest STS jdk. it is where all new features live.
This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:
- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk
it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish to cut all
those jdks from fedora?
To me the static repacked build sill somehow seems as smaller evil then drop practically
all interesting jdks out of distro.
So here I need to rephrase your question - is it based on your's thinking or on what
fedora users really needs?
I think the oposite - they need all jdks which are around. Proeprly integrated with
system. How they are built .. they do not care.
If update to neewer Fedora wil lmake some older JDK disapear, or if need of new one will
force me to update Fedora when I don't want or cant. I call it much worse user
expereince
> With much more stress about possible integration issues and with
- imo(!) - considerable negative imapct to fedora.
Would this reduced set of supported OpenJDK versions, but keeping the
"latest" version, address this "considerable negative impact"?
Of course it will. But afaik the imapct is really mch worse then it seems.
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
8:28 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 25, 2022 at 9:17 AM Jiri Vanek <jvanek(a)redhat.com> wrote:
On 5/24/22 22:02, Fabio Valentini wrote:
> On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
>> I replied it already in that thread, but happy to repeat:
>> It will help, but less then it seems so.
>> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is
in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
>> but we can not droop 11, as it is system jdk in f35
>> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK.
It needs it time to be tuned before being proposed as system jdk.
>> And we can not drop java-latest-openjdk, becasue it is necessary to boot next
system JDK.
>> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on
latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11
(and 8) will be felt by fedora users more, then having static jdk from repos.
>> Unluckily, with new future system jdk, we will need to boostrap it by latest,
keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be
in 3 jdks x 3 systems.
>> Sure, we do not need to backport newest future system jdk to older fedoras, but
usually the users want us to do so. tbh, I do not have strong preference on it. it is like
51 for backport, and 49 for not. Even with knwoledge of TCK burden.
>
> Is this based on user requests, or is this only what you *think* users
I'm not sure what you mean - from above - what is based on mine/wider thinking
Generally waht I wrote here it is based on judgmeent of about 10 people around OpenJDK
pacages in Fedora.
The equations above are based on realistic view and experience. Do you yo find some
misscalcualtion above?
I really appreciate you opinions, and would be happyt answer more precisely.
> of OpenJDK on Fedora need?
> Speaking for myself, I have never used anything other than the default
> "system JDK" for running Java applications on Fedora.
Are you really sure? Many applications runtime requiter non system jdk, so they pull it
in and use, and maybe you have not even noticed.
Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I need to
compile jimage) and the switch as needed.
>
> What would you think about the following scenario:
>
> - Fedora X defaults to new OpenJDK LTS N
> - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
> - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
> the default for one release
> - do not backport OpenJDK n to Fedora X-1 and X-2
> - keep java-latest-openjdk, as you seen to need this for bootstrapping
> new OpenJDK releases
This is possible solution. It will lower the TCK burden to aprox 3/5 with lost of most
widely used JDKs from repositories.
I'm open to this proposal. But the removal will hurt and way back will be much harder
then swithing static builds back to dynamic.
>
> You could even drop java-latest-openjdk from all branches but rawhide,
> since it's only needed for bootstrapping there.
Taht is very valid point. Cost is it will force huge number of uses to download 3rd
party latest STS jdk. it is where all new features live.
> This should pretty dramatically reduce the size of your test matrix.
> Applying the current numbers:
>
> - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
> default needs to be switched back), java-latest-openjdk
> - Fedora 35: java-11-openjdk, java-latest-openjdk
>
it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish to cut
all those jdks from fedora?
To me the static repacked build sill somehow seems as smaller evil then drop practically
all interesting jdks out of distro.
So here I need to rephrase your question - is it based on your's thinking or on what
fedora users really needs?
I think the oposite - they need all jdks which are around. Proeprly integrated with
system. How they are built .. they do not care.
If update to neewer Fedora wil lmake some older JDK disapear, or if need of new one will
force me to update Fedora when I don't want or cant. I call it much worse user
expereince
What about only making the older JDKs use bundled static libraries,
and the latest LTS and STS versions continue to use dynamic? That
would significantly cut down TCK versions and allow you to focus
dynamic support where it matters (latest Java runtime code).
--
真実はいつも一つ！/ Always, there's only one truth!
8:38 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/25/22 15:28, Neal Gompa wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On Wed, May 25, 2022 at 9:17 AM Jiri Vanek <jvanek(a)redhat.com>
wrote:
>
>
>
> On 5/24/22 22:02, Fabio Valentini wrote:
>> On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
>>> I replied it already in that thread, but happy to repeat:
>>> It will help, but less then it seems so.
>>> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8
is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
>>> but we can not droop 11, as it is system jdk in f35
>>> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system
JDK. It needs it time to be tuned before being proposed as system jdk.
>>> And we can not drop java-latest-openjdk, becasue it is necessary to boot next
system JDK.
>>> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on
latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11
(and 8) will be felt by fedora users more, then having static jdk from repos.
>>> Unluckily, with new future system jdk, we will need to boostrap it by latest,
keep it as secondary jdk at least for one , better two, fedora cycles, so again we will be
in 3 jdks x 3 systems.
>>> Sure, we do not need to backport newest future system jdk to older fedoras,
but usually the users want us to do so. tbh, I do not have strong preference on it. it is
like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.
>>
>> Is this based on user requests, or is this only what you *think* users
>
> I'm not sure what you mean - from above - what is based on mine/wider thinking
> Generally waht I wrote here it is based on judgmeent of about 10 people around
OpenJDK pacages in Fedora.
> The equations above are based on realistic view and experience. Do you yo find some
misscalcualtion above?
>
> I really appreciate you opinions, and would be happyt answer more precisely.
>
>
>> of OpenJDK on Fedora need?
>> Speaking for myself, I have never used anything other than the default
>> "system JDK" for running Java applications on Fedora.
>
> Are you really sure? Many applications runtime requiter non system jdk, so they pull
it in and use, and maybe you have not even noticed.
> Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I need to
compile jimage) and the switch as needed.
>
>>
>> What would you think about the following scenario:
>>
>> - Fedora X defaults to new OpenJDK LTS N
>> - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
>> - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
>> the default for one release
>> - do not backport OpenJDK n to Fedora X-1 and X-2
>> - keep java-latest-openjdk, as you seen to need this for bootstrapping
>> new OpenJDK releases
>
> This is possible solution. It will lower the TCK burden to aprox 3/5 with lost of
most widely used JDKs from repositories.
> I'm open to this proposal. But the removal will hurt and way back will be much
harder then swithing static builds back to dynamic.
>>
>> You could even drop java-latest-openjdk from all branches but rawhide,
>> since it's only needed for bootstrapping there.
>
> Taht is very valid point. Cost is it will force huge number of uses to download 3rd
party latest STS jdk. it is where all new features live.
>> This should pretty dramatically reduce the size of your test matrix.
>> Applying the current numbers:
>>
>> - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
>> - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
>> default needs to be switched back), java-latest-openjdk
>> - Fedora 35: java-11-openjdk, java-latest-openjdk
>>
>
> it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish to
cut all those jdks from fedora?
> To me the static repacked build sill somehow seems as smaller evil then drop
practically all interesting jdks out of distro.
>
> So here I need to rephrase your question - is it based on your's thinking or on
what fedora users really needs?
> I think the oposite - they need all jdks which are around. Proeprly integrated with
system. How they are built .. they do not care.
> If update to neewer Fedora wil lmake some older JDK disapear, or if need of new one
will force me to update Fedora when I don't want or cant. I call it much worse user
expereince
>
What about only making the older JDKs use bundled static libraries,
and the latest LTS and STS versions continue to use dynamic? That
would significantly cut down TCK versions and allow you to focus
dynamic support where it matters (latest Java runtime code).
Quite a fresh thinking!
What about all jdks except system one being static (and repacked), but the system one
dynamic. That can go below 1/2 of QA runs, without any cut of jdks in fedora.
There exists Quite a high risk, that the system jdk will trasnfer form static to dynamic
in some point (or oposite), and that will lead to unknown new issues prety late in
lifecycle.
8:46 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 25, 2022 at 9:38 AM Jiri Vanek <jvanek(a)redhat.com> wrote:
On 5/25/22 15:28, Neal Gompa wrote:
> On Wed, May 25, 2022 at 9:17 AM Jiri Vanek <jvanek(a)redhat.com> wrote:
>>
>>
>>
>> On 5/24/22 22:02, Fabio Valentini wrote:
>>> On Tue, May 24, 2022 at 5:03 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
>>>> I replied it already in that thread, but happy to repeat:
>>>> It will help, but less then it seems so.
>>>> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of
jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs
down.
>>>> but we can not droop 11, as it is system jdk in f35
>>>> Similarly, we couldn't introduce fresh jdk17 directly to f36 as
system JDK. It needs it time to be tuned before being proposed as system jdk.
>>>> And we can not drop java-latest-openjdk, becasue it is necessary to boot
next system JDK.
>>>> Yes, in 8 months, we would be able to drop 11. And live for 1 year only
on latest and 17. Which is putting load for one year to 1/2. But the cost of not having 11
(and 8) will be felt by fedora users more, then having static jdk from repos.
>>>> Unluckily, with new future system jdk, we will need to boostrap it by
latest, keep it as secondary jdk at least for one , better two, fedora cycles, so again we
will be in 3 jdks x 3 systems.
>>>> Sure, we do not need to backport newest future system jdk to older
fedoras, but usually the users want us to do so. tbh, I do not have strong preference on
it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.
>>>
>>> Is this based on user requests, or is this only what you *think* users
>>
>> I'm not sure what you mean - from above - what is based on mine/wider
thinking
>> Generally waht I wrote here it is based on judgmeent of about 10 people around
OpenJDK pacages in Fedora.
>> The equations above are based on realistic view and experience. Do you yo find
some misscalcualtion above?
>>
>> I really appreciate you opinions, and would be happyt answer more precisely.
>>
>>
>>> of OpenJDK on Fedora need?
>>> Speaking for myself, I have never used anything other than the default
>>> "system JDK" for running Java applications on Fedora.
>>
>> Are you really sure? Many applications runtime requiter non system jdk, so they
pull it in and use, and maybe you have not even noticed.
>> Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I
need to compile jimage) and the switch as needed.
>>
>>>
>>> What would you think about the following scenario:
>>>
>>> - Fedora X defaults to new OpenJDK LTS N
>>> - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
>>> - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
>>> the default for one release
>>> - do not backport OpenJDK n to Fedora X-1 and X-2
>>> - keep java-latest-openjdk, as you seen to need this for bootstrapping
>>> new OpenJDK releases
>>
>> This is possible solution. It will lower the TCK burden to aprox 3/5 with lost
of most widely used JDKs from repositories.
>> I'm open to this proposal. But the removal will hurt and way back will be
much harder then swithing static builds back to dynamic.
>>>
>>> You could even drop java-latest-openjdk from all branches but rawhide,
>>> since it's only needed for bootstrapping there.
>>
>> Taht is very valid point. Cost is it will force huge number of uses to download
3rd party latest STS jdk. it is where all new features live.
>>> This should pretty dramatically reduce the size of your test matrix.
>>> Applying the current numbers:
>>>
>>> - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
>>> - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
>>> default needs to be switched back), java-latest-openjdk
>>> - Fedora 35: java-11-openjdk, java-latest-openjdk
>>>
>>
>> it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish
to cut all those jdks from fedora?
>> To me the static repacked build sill somehow seems as smaller evil then drop
practically all interesting jdks out of distro.
>>
>> So here I need to rephrase your question - is it based on your's thinking
or on what fedora users really needs?
>> I think the oposite - they need all jdks which are around. Proeprly integrated
with system. How they are built .. they do not care.
>> If update to neewer Fedora wil lmake some older JDK disapear, or if need of new
one will force me to update Fedora when I don't want or cant. I call it much worse
user expereince
>>
>
> What about only making the older JDKs use bundled static libraries,
> and the latest LTS and STS versions continue to use dynamic? That
> would significantly cut down TCK versions and allow you to focus
> dynamic support where it matters (latest Java runtime code).
Quite a fresh thinking!
What about all jdks except system one being static (and repacked), but the system one
dynamic. That can go below 1/2 of QA runs, without any cut of jdks in fedora.
There exists Quite a high risk, that the system jdk will trasnfer form static to dynamic
in some point (or oposite), and that will lead to unknown new issues prety late in
lifecycle.
I did think of that, that's why I figured doing the latest STS and
LTS, because it ensures the STS->LTS bootstrap is going to be
reasonable. It can also be coupled with switching the system JDK to
the latest LTS.
--
真実はいつも一つ！/ Always, there's only one truth!
8:40 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 25, 2022 at 3:17 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
On 5/24/22 22:02, Fabio Valentini wrote:
> Is this based on user requests, or is this only what you *think* users
I'm not sure what you mean - from above - what is based on mine/wider thinking
Generally waht I wrote here it is based on judgmeent of about 10 people around OpenJDK
pacages in Fedora.
The equations above are based on realistic view and experience. Do you yo find some
misscalcualtion above?
I really appreciate you opinions, and would be happyt answer more precisely.
Thank you for your response, I appreciate that you're engaging with
feedback here.
The way I understood your last message, it seemed to me that you were
claiming that actual Fedora users are requesting that you ship so many
different OpenJDK versions.
However, in this thread, I see the opposite - almost everybody is
asking you to consider dropping support for at least some non-default
OpenJDK versions, and nobody is advocating for keeping all of them. So
my question was whether you have actual user feedback requesting that
so many different versions are available on Fedora.
> of OpenJDK on Fedora need?
> Speaking for myself, I have never used anything other than the default
> "system JDK" for running Java applications on Fedora.
Are you really sure? Many applications runtime requiter non system jdk, so they pull it
in and use, and maybe you have not even noticed.
Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I need to
compile jimage) and the switch as needed.
I'm quite sure, though I'm not using as many Java applications as I used to.
The Minecraft "Java Edition" has always worked fine with the "system /
default JDK", so I never needed to install another one.
And the JetBrains IDEs have bundled their own JDK for a while now, I
think, so I don't have to deal with those, either (and I wouldn't even
want to mess with my main development environment to make it use
something other than the JDK it ships with).
>
> What would you think about the following scenario:
>
> - Fedora X defaults to new OpenJDK LTS N
> - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
> - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
> the default for one release
> - do not backport OpenJDK n to Fedora X-1 and X-2
> - keep java-latest-openjdk, as you seen to need this for bootstrapping
> new OpenJDK releases
This is possible solution. It will lower the TCK burden to aprox 3/5 with lost of most
widely used JDKs from repositories.
I'm open to this proposal. But the removal will hurt and way back will be much harder
then swithing static builds back to dynamic.
>
> You could even drop java-latest-openjdk from all branches but rawhide,
> since it's only needed for bootstrapping there.
Taht is very valid point. Cost is it will force huge number of uses to download 3rd
party latest STS jdk. it is where all new features live.
Are there really that many Fedora users who need and install
java-latest-openjdk? Do you have estimates of how many people do this,
compared to how many users just use the default system JDK?
> This should pretty dramatically reduce the size of your test
matrix.
> Applying the current numbers:
>
> - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
> default needs to be switched back), java-latest-openjdk
> - Fedora 35: java-11-openjdk, java-latest-openjdk
>
it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish to cut
all those jdks from fedora?
To me the static repacked build sill somehow seems as smaller evil then drop practically
all interesting jdks out of distro.
Yeah, why not? I'm asking whether it's actually worth your time to
keep them around. Given that there's probably limited userbase and the
resources that are needed to keep them around, this is a valid
question, I think. Speaking for myself, I'd rather have the default,
integrated, system JDK be of the high quality it has been in Fedora,
rather than having many different, less-integrated versions around.
So here I need to rephrase your question - is it based on your's
thinking or on what fedora users really needs?
I think the oposite - they need all jdks which are around. Proeprly integrated with
system. How they are built .. they do not care.
If update to neewer Fedora wil lmake some older JDK disapear, or if need of new one will
force me to update Fedora when I don't want or cant. I call it much worse user
expereince
Well, isn't that the point?
BTW, I noticed that despite java-17-openjdk being the default system
JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when
I upgraded from Fedora 35. That sounds like the change proposal wasn't
fully implemented, either?
Fabio
8:53 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-25 at 15:40 +0200, Fabio Valentini wrote:
On Wed, May 25, 2022 at 3:17 PM Jiri Vanek <jvanek(a)redhat.com>
wrote:
>
> On 5/24/22 22:02, Fabio Valentini wrote:
> > Is this based on user requests, or is this only what you *think*
> > users
>
> I'm not sure what you mean - from above - what is based on
> mine/wider thinking
> Generally waht I wrote here it is based on judgmeent of about 10
> people around OpenJDK pacages in Fedora.
> The equations above are based on realistic view and experience. Do
> you yo find some misscalcualtion above?
>
> I really appreciate you opinions, and would be happyt answer more
> precisely.
Thank you for your response, I appreciate that you're engaging with
feedback here.
The way I understood your last message, it seemed to me that you were
claiming that actual Fedora users are requesting that you ship so
many
different OpenJDK versions.
However, in this thread, I see the opposite - almost everybody is
asking you to consider dropping support for at least some non-default
OpenJDK versions, and nobody is advocating for keeping all of them.
So
my question was whether you have actual user feedback requesting that
so many different versions are available on Fedora.
> > of OpenJDK on Fedora need?
> > Speaking for myself, I have never used anything other than the
> > default
> > "system JDK" for running Java applications on Fedora.
>
> Are you really sure? Many applications runtime requiter non system
> jdk, so they pull it in and use, and maybe you have not even
> noticed.
> Many develoeprs ahve installe dmany JDKS (in my case all from
> repos, unless I need to compile jimage) and the switch as needed.
I'm quite sure, though I'm not using as many Java applications as I
used to.
The Minecraft "Java Edition" has always worked fine with the "system
/
default JDK", so I never needed to install another one.
And the JetBrains IDEs have bundled their own JDK for a while now, I
think, so I don't have to deal with those, either (and I wouldn't
even
want to mess with my main development environment to make it use
something other than the JDK it ships with).
> >
> > What would you think about the following scenario:
> >
> > - Fedora X defaults to new OpenJDK LTS N
> > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the
> > change
> > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was
> > already
> > the default for one release
> > - do not backport OpenJDK n to Fedora X-1 and X-2
> > - keep java-latest-openjdk, as you seen to need this for
> > bootstrapping
> > new OpenJDK releases
>
> This is possible solution. It will lower the TCK burden to aprox
> 3/5 with lost of most widely used JDKs from repositories.
> I'm open to this proposal. But the removal will hurt and way back
> will be much harder then swithing static builds back to dynamic.
> >
> > You could even drop java-latest-openjdk from all branches but
> > rawhide,
> > since it's only needed for bootstrapping there.
>
> Taht is very valid point. Cost is it will force huge number of
> uses to download 3rd party latest STS jdk. it is where all new
> features live.
Are there really that many Fedora users who need and install
java-latest-openjdk? Do you have estimates of how many people do
this,
compared to how many users just use the default system JDK?
> > This should pretty dramatically reduce the size of your test
> > matrix.
> > Applying the current numbers:
> >
> > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case
> > the
> > default needs to be switched back), java-latest-openjdk
> > - Fedora 35: java-11-openjdk, java-latest-openjdk
> >
>
> it is a bit less then I wrote, - about 3/5 of current load but do
> yoreally wish to cut all those jdks from fedora?
> To me the static repacked build sill somehow seems as smaller evil
> then drop practically all interesting jdks out of distro.
Yeah, why not? I'm asking whether it's actually worth your time to
keep them around. Given that there's probably limited userbase and
the
resources that are needed to keep them around, this is a valid
question, I think. Speaking for myself, I'd rather have the default,
integrated, system JDK be of the high quality it has been in Fedora,
rather than having many different, less-integrated versions around.
> So here I need to rephrase your question - is it based on your's
> thinking or on what fedora users really needs?
> I think the oposite - they need all jdks which are around. Proeprly
> integrated with system. How they are built .. they do not care.
> If update to neewer Fedora wil lmake some older JDK disapear, or if
> need of new one will force me to update Fedora when I don't want or
> cant. I call it much worse user expereince
Well, isn't that the point?
BTW, I noticed that despite java-17-openjdk being the default system
JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when
I upgraded from Fedora 35. That sounds like the change proposal
wasn't
fully implemented, either?
Wouldn't the upgrade approach leave the installed
JDK as default? Just
asking since I have the default installed on F36 (17) and I also have
the latest(18) which I didn't explicitly install. Just asking
Stephen
Fabio
_______________________________________________
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
9:02 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
>
> BTW, I noticed that despite java-17-openjdk being the default system
> JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when
> I upgraded from Fedora 35. That sounds like the change proposal
> wasn't
That sounds like super severe bug. I had tried it manytimes, in testing environemtn with
various basic pre-update setups when I was finishing the change, and was ok.
When I updated my three personal machnes to f36 al was ok. But I''m afraid here
jdk8, jdk11 and jdk17 and jdk18.
> fully implemented, either?
Wouldn't the upgrade approach leave the installed JDK as default? Just
asking since I have the default installed on F36 (17) and I also have
the latest(18) which I didn't explicitly install. Just asking
If we consider the unlikely super basic usecase, wehn you had only jdk17 in f35, then the
upgrade to f36 should add jdk 17. So btoh jdk11 and 17 will be there, and jdk17 will
become selected.
If you have lets say 8 and 11, and you *manually* select 8, then after update there will
be 8,11 and 17, and 8 will remain selected. Alternatives honor your selction. The system
jdk wil not be affeted byt maual selection of jdk -
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_...
J.
3:14 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:
We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
so we have to. But that is much easier, as the usptream is static within
intree libraries. And we have to run also for 17 and 18/19 as we need this
reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
we test the (source x build) just once. And we can test the binary on some
known system where we always pass.
Well, I meant test the _dynamic_ build that Fedora does now...
But in downstream, new issues usually appear due to the dynamic
linking and
nature of system where only it can be installed. Also for dowstram, each
sources are built N times, so N times tested in thsoe N systems - usually
each with its psecific failures.
>
> Could we integrate the TCK testing in our CI to save you overhead of
> managing submitting, etc? Or where is the most time spent in this
> workflow?
As I described in another reply, it is both human and hw. Hw to run all those swarm of
builds on all platforms, and humans to verify the issue and to fix it.
TCK are very complex, and you need at least three machines in distributed system to run
them. At least two of those slaves are not trivial (krb master and system where tck are
running).
Generally saying, I have autoamtion to prepare that all, but second part is
reproducibility. If the "non mine" setup run will fail for some reason, can I
rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.
Would it help to have some cloud resources to do this in?
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds.
> I know others have suggested fewer openjdk streams to reduce
workload,
> but I didn't see any reply on that from change owners.
>
I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in some 4
years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It needs
it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next system
JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and 17.
Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will be
felt by fedora users more, then having static jdk from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it as
secondary jdk at least for one , better two, fedora cycles, so again we will be in 3 jdks
x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but usually
the users want us to do so. tbh, I do not have strong preference on it. it is like 51 for
backport, and 49 for not. Even with knwoledge of TCK burden.
If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
With this shortage, we would have
2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That sound like
a reasonable drop, but only for very short period of time, duriong which we will nee to
have capcity reserved for ppreparation of next
system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, With much
more stress about possible integration issues and with - imo(!) - considerable negative
imapct to fedora.
ok, sorry I missed a previous reply on this. ;)
So, what would you then think about just:
1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and
2. switching fedora to the static system libraries so you didn't need to
keep the dynamic ones in sync.
but then trying to see if that reduces your workload to a sustainable
level and avoid the 'build once, certify' thing that is going to end up
being a lot of trouble.
kevin
8:28 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 22:14, Kevin Fenzi wrote:
On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:
>
> We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
> so we have to. But that is much easier, as the usptream is static within
> intree libraries. And we have to run also for 17 and 18/19 as we need this
> reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
> we test the (source x build) just once. And we can test the binary on some
> known system where we always pass.
Well, I meant test the _dynamic_ build that Fedora does now...
Yy , I got that. What made you think I did not?
> But in downstream, new issues usually appear due to the dynamic linking and
> nature of system where only it can be installed. Also for dowstram, each
> sources are built N times, so N times tested in thsoe N systems - usually
> each with its psecific failures.
>
>>
>> Could we integrate the TCK testing in our CI to save you overhead of
>> managing submitting, etc? Or where is the most time spent in this
>> workflow?
>
> As I described in another reply, it is both human and hw. Hw to run all those swarm
of builds on all platforms, and humans to verify the issue and to fix it.
> TCK are very complex, and you need at least three machines in distributed system to
run them. At least two of those slaves are not trivial (krb master and system where tck
are running).
> Generally saying, I have autoamtion to prepare that all, but second part is
reproducibility. If the "non mine" setup run will fail for some reason, can I
rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.
Would it help to have some cloud resources to do this in?
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds.
it is quite hard to imagine better testing resources then I have in Red hat.
Since some amount of HW/remote 3rd party clusters - which we reached - you really do not
want to continue take care of it. Also HW and infra failures will suddenly multiply to
the level that tehre are still some.
And at the end, who wil watch results? And will debugging remain smooth?
So generall sayong - yes more hw would help. But with more HW one needs more pople to
contorl that and fix, and to check results. So no, really since soem amount of workload,
jsut more HW is not solution.
Of course that imply possible heavy reorganization JDK team in RH which cares about Fedora
rpms in theirs free time, maybe have to do.
>> I know others have suggested fewer openjdk streams to reduce workload,
>> but I didn't see any reply on that from change owners.
>>
>
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is in
some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It
needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next system
JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on latest and
17. Which is putting load for one year to 1/2. But the cost of not having 11 (and 8) will
be felt by fedora users more, then having static jdk from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, keep it
as secondary jdk at least for one , better two, fedora cycles, so again we will be in 3
jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, but
usually the users want us to do so. tbh, I do not have strong preference on it. it is like
51 for backport, and 49 for not. Even with knwoledge of TCK burden.
>
> If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
> With this shortage, we would have
> 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That sound
like a reasonable drop, but only for very short period of time, duriong which we will nee
to have capcity reserved for ppreparation of next
> system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage, With
much more stress about possible integration issues and with - imo(!) - considerable
negative imapct to fedora.
ok, sorry I missed a previous reply on this. ;)
So, what would you then think about just:
1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and
Nope. I really ahve huge HW capacity. yes, we reached its capacity. Addng more capacity
woudl help, but with that will arrive need of more poeple.
2. switching fedora to the static system libraries so you didn't
need to
keep the dynamic ones in sync.
Taht is first step. Maybe we will really find that we can not do it in distro, and cut of
JDK packed will follow (maybe with return to dynamic linking)
but then trying to see if that reduces your workload to a sustainable
level and avoid the 'build once, certify' thing that is going to end up
being a lot of trouble.
I guess you can imagine it better then me. If we try static builds and they fails, we are
back. If we try static buidls and they works, we will try the reapck. If it works, it
works if not, then we will yet again cut number of jdks in
fedoras and probably return to dynamic jdks.
I really cant say. This is not exactly charted path. the reply form this trehad is pretty
clear.. Similarly our standing is pretty clear.
Thanx!
J.
9:31 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/21/22 13:51, Vitaly Zaitsev via devel wrote:
On 21/05/2022 13:22, Jiri Vanek wrote:
> shim?
Built on Koji from sources as shim-unsigned, then uploaded to Microsoft for signing.
This is a special legal case, just like openh264 and Cisco.
Both of them built from sources on Fedora infra.
I repeat, aprox 21st time - I will never ever use blob. I will always build from sources
in koji.
The goal is to go as shim and cisco - to build in koji, certify, and repack.
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
11:37 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 24/05/2022 16:31, Jiri Vanek wrote:
The goal is to go as shim and cisco - to build in koji, certify, and
repack.
shim and openh264 have a good reason for this - legal issues. OpenJDK
doesn't. Sorry, but I can't treat the laziness of the maintainers as a
good reason.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
12:40 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Once upon a time, Vitaly Zaitsev <vitaly(a)easycoding.org> said:
Sorry, but I can't treat the laziness of the
maintainers as a good reason.
Can you PLEASE stop with the personal attacks?
--
Chris Adams <linux(a)cmadams.net>
2 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 18:37, Vitaly Zaitsev via devel wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On 24/05/2022 16:31, Jiri Vanek wrote:
> The goal is to go as shim and cisco - to build in koji, certify, and repack.
shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. Sorry,
but I can't treat the laziness of the maintainers as a good reason.
Even if you woulf call 10 years of 5 engineers to keep dynamic builds (and generlay jdk in
Fedora) alivem, tt had become human-impossible to continue in current way of things.
It will lead to lost of JDK or heavy rework of how JDK s handled now
I repeat what was told several times.We really do no t like this change, especially in its
full sound of one static build repacked to all ive fedoras, but we have nto found a better
way.
Really sorry,
J.
2:41 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 24/05/2022 21:00, Jiri Vanek wrote:
I repeat what was told several times.We really do no t like this
change,
especially in its full sound of one static build repacked to all ive
fedoras, but we have nto found a better way.
1. Stop doing TCK certification. Most Fedora OpenJDK users don't need
certified binaries. All they need is a working and well packaged OpenJDK.
2. Reduce the number of OpenJDK branches in the repositories. I think
the latest LTS version will be enough.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:03 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On 24/05/2022 21:00, Jiri Vanek wrote:
> I repeat what was told several times.We really do no t like this change, especially
in its full sound of one static build repacked to all ive fedoras, but we have nto found a
better way.
1. Stop doing TCK certification. Most Fedora OpenJDK users don't need certified
binaries.
We can not ship uncerified JDK. Sooner or later a swarm of lawyers would
appear.
All they need is a working and well packaged OpenJDK.
From point of view of JDK, the jdk will remain working. From point of JDK and generric
java world the jdk will be even better.
From view of distributions standarts it will become weird misshape. Serving it purpose in
build root well, serving as system or distribution jdk well. But yeah... all was said on
this toppic already:(
2. Reduce the number of OpenJDK branches in the repositories. I think
the latest LTS version will be enough.
I wish it is so simple. Please see my reply to Kevin when I enumerated, that we can not
keep "jsut latest" lts.
8:19 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, 25 May 2022 at 09:04, Jiri Vanek <jvanek(a)redhat.com> wrote:
On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> On 24/05/2022 21:00, Jiri Vanek wrote:
>> I repeat what was told several times.We really do no t like this
change, especially in its full sound of one static build repacked to all
ive fedoras, but we have nto found a better way.
>
> 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need
certified binaries.
We can not ship uncerified JDK. Sooner or later a swarm of lawyers would
appear.
So could it be shipped instead as a icedtea?
The reason I am asking is that I think we need to look seriously at the
alternatives and see how much work the community is going to need to do.
1. Fedora no longer ships a trademarked 'coffee-themed language'. Instead
it adds an external repository where your team is able to focus on what
they can deliver.
2. Fedora no longer ships a trademarked 'coffee-themed language'. Instead,
a volunteer driven SIG puts in an icedtea back into into Fedora instead.
3. Fedora no longer ships a trademarked 'coffee-themed language'. Instead
people wanting it will need to find an external place which builds it.
4. Fedora ships a trademarked 'coffee-themed language' that is static.
However this doesn't decrease the workload enough and we need to move to
1-3 in 2 to 3 years.
> All they need is a working and well packaged OpenJDK.
>
From point of view of JDK, the jdk will remain working. From point of
JDK and generric java world the jdk will be even better.
From view of distributions standarts it will become weird misshape.
Serving it purpose in build root well, serving as system or distribution
jdk well. But yeah... all was said on this toppic already:(
> 2. Reduce the number of OpenJDK branches in the repositories. I think
the latest LTS version will be enough.
I wish it is so simple. Please see my reply to Kevin when I enumerated,
that we can not keep "jsut latest" lts.
>
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
_______________________________________________
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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
8:34 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/25/22 15:19, Stephen Smoogen wrote:
On Wed, 25 May 2022 at 09:04, Jiri Vanek <jvanek(a)redhat.com
<mailto:jvanek@redhat.com>> wrote:
On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> On 24/05/2022 21:00, Jiri Vanek wrote:
>> I repeat what was told several times.We really do no t like this change,
especially in its full sound of one static build repacked to all ive fedoras, but we have
nto found a better way.
>
> 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need
certified binaries.
We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear.
So could it be shipped instead as a icedtea?
When we were shipping icedtea6 and later icedtea7, it still required TCK, so iced tea is
not an option.
I added bot Andrews to cc, as they remains masters of IcedTea even now, when it is agesd
dead (maybe technically beyond resurrection)
IIRC, icedtea is set of patches on top of openjdk. So it remains Opendk. So it reqwuires
TCK. Pelase anybody if yo really know, correct me. I'm also not lawyer.
Thanx a lot for writting this down
The reason I am asking is that I think we need to look seriously at the alternatives and
see how much work the community is going to need to do.
1. Fedora no longer ships a trademarked 'coffee-themed language'. Instead it adds
an external repository where your team is able to focus on what they can deliver.
2. Fedora no longer ships a trademarked 'coffee-themed language'. Instead, a
volunteer driven SIG puts in an icedtea back into into Fedora instead.
3. Fedora no longer ships a trademarked 'coffee-themed language'. Instead people
wanting it will need to find an external place which builds it.
4. Fedora ships a trademarked 'coffee-themed language' that is static. However
this doesn't decrease the workload enough and we need to move to 1-3 in 2 to 3 years.
If we exclude Red hat from Openjdk and it will remain purely on community, and if they
will be good enogh to really maintian JDKs fo fedora, I cant predict impact of Law, when
..someone .. finds it is driven by anonymous without signed
agreement and without TCK. I realy do not know.
Thanx!!!
J.
8:47 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, 25 May 2022 at 09:34, Jiri Vanek <jvanek(a)redhat.com> wrote:
On 5/25/22 15:19, Stephen Smoogen wrote:
>
>
> On Wed, 25 May 2022 at 09:04, Jiri Vanek <jvanek(a)redhat.com <mailto:
jvanek(a)redhat.com>> wrote:
>
>
>
> On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> > On 24/05/2022 21:00, Jiri Vanek wrote:
> >> I repeat what was told several times.We really do no t like this
change, especially in its full sound of one static build repacked to all
ive fedoras, but we have nto found a better way.
> >
> > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't
need certified binaries.
> We can not ship uncerified JDK. Sooner or later a swarm of lawyers
would appear.
>
>
> So could it be shipped instead as a icedtea?
When we were shipping icedtea6 and later icedtea7, it still required TCK,
so iced tea is not an option.
I added bot Andrews to cc, as they remains masters of IcedTea even now,
when it is agesd dead (maybe technically beyond resurrection)
IIRC, icedtea is set of patches on top of openjdk. So it remains Opendk.
So it reqwuires TCK. Pelase anybody if yo really know, correct me. I'm also
not lawyer.
Thanx a lot for writting this down
By icedtea I was assuming a cleanout of trademarks like Firefox and Mozilla
is done in Debian. This was not how the previous icedtea was done but it
may be what needs to be reviewed. It does require a legal review and that
would be something for this team to ask the Board and internal Red Hat to
do.
If the licenses for how the coffee-themed language requires a TCK no matter
what, then I would say that JDK is not open/free in a way that is easily
distributable and that would be another thing Fedora board needs to deal
with. In either case it is not you or your team's fault here... and people
saying so need to back off.
>
> The reason I am asking is that I think we need to look seriously at the
alternatives and see how much work the community is going to need to do.
> 1. Fedora no longer ships a trademarked 'coffee-themed language'.
Instead it adds an external repository where your team is able to focus on
what they can deliver.
> 2. Fedora no longer ships a trademarked 'coffee-themed language'.
Instead, a volunteer driven SIG puts in an icedtea back into into Fedora
instead.
> 3. Fedora no longer ships a trademarked 'coffee-themed language'.
Instead people wanting it will need to find an external place which builds
it.
> 4. Fedora ships a trademarked 'coffee-themed language' that is static.
However this doesn't decrease the workload enough and we need to move to
1-3 in 2 to 3 years.
If we exclude Red hat from Openjdk and it will remain purely on community,
and if they will be good enogh to really maintian JDKs fo fedora, I cant
predict impact of Law, when ..someone .. finds it is driven by anonymous
without signed
agreement and without TCK. I realy do not know.
Thanx!!!
J.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
11:09 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 25/05/2022 15:34, Jiri Vanek wrote:
When we were shipping icedtea6 and later icedtea7, it still required
TCK, so iced tea is not an option.
Easy fix: java-XX-openjdk -> coffee-named-language-XX.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:36 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-25 at 15:03 +0200, Jiri Vanek wrote:
On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> On 24/05/2022 21:00, Jiri Vanek wrote:
> > I repeat what was told several times.We really do no t like this
> > change, especially in its full sound of one static build repacked
> > to all ive fedoras, but we have nto found a better way.
>
> 1. Stop doing TCK certification. Most Fedora OpenJDK users don't
> need certified binaries.
We can not ship uncerified JDK. Sooner or later a swarm of lawyers
would appear.
100%, though I am not one, I understand as much from the TCK itslef.
> All they need is a working and well packaged OpenJDK.
>
From point of view of JDK, the jdk will remain working. From point
of JDK and generric java world the jdk will be even better.
From view of distributions standarts it will become weird misshape.
Serving it purpose in build root well, serving as system or
distribution jdk well. But yeah... all was said on this toppic
already:(
As a user of the JDK as Fedora Linux currently ships it, I can say I am
very grateful for the efforts being made to accomodate it.
> 2. Reduce the number of OpenJDK branches in the repositories. I
> think the latest LTS version will be enough.
I have also suggested this, but in historical context JDK 6 hung around
about 10 years longer than expected I think due in large part to the
inertia built by it's prolific use in enterprise systems. This will
undoubtably hold true for JDK 8 as well, since it is currently the
preferred choice by most. Technically speaking WRT JDK releases, some
fall by the wayside (jdk 9 and jdk 10 are two recent).
I wish it is so simple. Please see my reply to Kevin when I
enumerated, that we can not keep "jsut latest" lts.
>
Regards,
Stephen Snow
just some dude who can program ... whatever
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
_______________________________________________
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
11:01 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 25/05/2022 15:03, Jiri Vanek wrote:
We can not ship uncerified JDK. Sooner or later a swarm of lawyers
would
appear.
Let's rename it to icedtea then.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
12:49 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
The rename will really not help.
On 5/25/22 18:01, Vitaly Zaitsev via devel wrote:
On 25/05/2022 15:03, Jiri Vanek wrote:
> We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear.
Let's rename it to icedtea then.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
5:02 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/25/22 13:49, Jiri Vanek wrote:
The rename will really not help.
If it is not possible to ship an uncertified version then OpenJDK is
not free software and Fedora should not have it at all, in which
case the whole discussion is moot. Otherwise, it is possible
to ship a compatible version without the trademarks and without
TCK certification. IANAL, but I believe APIs are not eligible for
trademark protection, so Fedora would only need to change the stuff
that is *not* part of the API.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
5:55 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 00:02, Demi Marie Obenour wrote:
IANAL, but I believe APIs are not eligible for
trademark protection, so Fedora would only need to change the stuff
that is*not* part of the API.
Yes. Google won a lawsuit against Oracle in the Supreme Court.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:04 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
There sure seems to be confusion here around what exactly the TCK or
JCK actually is. First off it is not a license. It is however a
technical compatability certification which guarantees technical
compatability between the different flavours of OpenJDK available out
there, like RedHats
(https://www.redhat.com/en/resources/build-of-openjdk-datasheet)
Who signed the agreement (OTCLA) to get the TCK/JCK obviously
The license aspect is found at
https://openjdk.java.net/legal/OCTLA-JDK9+.pdf and is the agreement you
sign to get access to the certification toolkit.
Yes, everyone who distributes a version of OpenJDK does this, and I
would think outside of hobby or education purposes, if you develop in
Java you want this too.
Regards,
Stephen Snow
On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote:
On 26/05/2022 00:02, Demi Marie Obenour wrote:
> IANAL, but I believe APIs are not eligible for
> trademark protection, so Fedora would only need to change the stuff
> that is*not* part of the API.
Yes. Google won a lawsuit against Oracle in the Supreme Court.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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
7:17 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
Also, it may be good to take a look at what AdoptOpenJDK is doing with
the Eclipse Foundation based Adoptium Project, specifically the Eclipse
Temurin subproject
https://projects.eclipse.org/proposals/eclipse-temurin-compliance which
is going to handle the compliance requirements.
In this scenerio the Eclipse Foundation is the license holder and the
Adoptium project submits to the Temurin project to get certified.
Maybe Fedora could use something similar with RH, who are signatories
on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project.
Just another thought on it.
On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote:
On 26/05/2022 00:02, Demi Marie Obenour wrote:
> IANAL, but I believe APIs are not eligible for
> trademark protection, so Fedora would only need to change the stuff
> that is*not* part of the API.
Yes. Google won a lawsuit against Oracle in the Supreme Court.
What law suit, and how does it apply to our situation?
Regards,
Stephen Snow
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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
10:06 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Thu, 26 May 2022 at 08:19, Stephen Snow <s40w5s(a)gmail.com> wrote:
On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote:
> On 26/05/2022 00:02, Demi Marie Obenour wrote:
> > IANAL, but I believe APIs are not eligible for
> > trademark protection, so Fedora would only need to change the stuff
> > that is*not* part of the API.
>
> Yes. Google won a lawsuit against Oracle in the Supreme Court.
>
What law suit, and how does it apply to our situation?
The only lawsuit I know of is
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc. where
while Google 'won' parts, many issues have been remanded back to a lower
court and are still outstanding. [This means that they could still be
interpreted as a win for Oracle on narrower bands.] It is unclear enough
that various groups have had different interpretations. That said there are
several trademark lawsuits on the usage of 'coffee-themed-languages' which
have been posted in the past by Oracle ranging from Starbucks to various
smaller software companies. Trademark and copyright sound like they are the
same thing but they are different parts of the law and can 'override' one
another in different ways.
In any case, I think this needs an official review by the Fedora Council:
0. Are the outside requirements on how 'coffee-themed languages' must be
published making them non-Free/Open in the way Fedora Project expects
things to be?
1. What are the legal concerns that the Fedora Project must do to
distribute OpenJDK?
2. Are there ways that a non-TCK compliant version could be distributed?
3. Clearer guidance to the volunteers on how to deal with these
requirements.
These are deeper issues which I think need to be dealt with before we can
even think about the F37 change proposal.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
10:31 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 11:06, Stephen Smoogen wrote:
2. Are there ways that a non-TCK compliant version could be
distributed?
I would suggest phrasing that slightly differently: the version being
distributed could very well be fully compliant (would pass the TCK if
tested), but may not have been tested.
--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
10:38 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Thu, 26 May 2022 at 11:32, Kevin P. Fleming <kpfleming(a)redhat.com> wrote:
On 5/26/22 11:06, Stephen Smoogen wrote:
> 2. Are there ways that a non-TCK compliant version could be distributed?
I would suggest phrasing that slightly differently: the version being
distributed could very well be fully compliant (would pass the TCK if
tested), but may not have been tested.
Yes, that goes into the my misunderstanding of what TCK is. Some systems
can only say they are 'compliant' if they are 'certified' and anything
else
is 'fraudulent'. Others allow for 'complaint' and 'certified' to
be
different.
In either case, I should have clarified with 'certified'.
--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
_______________________________________________
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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
1:18 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
So my take on the TCK is that Red Hat signed the OCTLA and Fedora
Community get's to test their OpenJDK against it as a subequence. I
didn't think Fedora the project, had any legal except what Red Hat
provides, maybe I'm mistaken though so someone should clarify if they
know for sure. Not only that, if we (Fedora Project) were the
signatories, we would need auditing internally and externally to comply
with requirements of the OCTLA from what I understand, which I imagine
we do not have, nor want to entertain since it would require
significant dedicated support likely. Basically anytime you use the TCK
you need the paper trail.
I still think the original proposal has some merrit at least of raisng
the point of the workload required to maintain Fedora Lunix's java
development stack. A rethink here would be good overall and really the
technical build issues Jiri Vanik presented need to be overcome and
should be the projects focus, not legal. Perhaps Fedora Project lead
could discuss this with RH legal to get their perspective. I'm sure
they're aware of the arrangement as it has been used by Fedora, and
Fedora is not listed as signatory, and someone had to sign the
agreement to get the TCK in the first place.
From that POV, to me as OpenJDK is still GPL3 released, and Fedora
Project get's to use Red Hat's TCK to verify certification of
compliance, so win win. Red Hat needs it for their own OpenJDK, which
we no doubt have some involvement with, so again win win.
Regards,
Stephen Snow
On Thu, 2022-05-26 at 11:38 -0400, Stephen Smoogen wrote:
On Thu, 26 May 2022 at 11:32, Kevin P. Fleming <kpfleming(a)redhat.com>
wrote:
> On 5/26/22 11:06, Stephen Smoogen wrote:
> > 2. Are there ways that a non-TCK compliant version could be
> distributed?
>
> I would suggest phrasing that slightly differently: the version
> being
> distributed could very well be fully compliant (would pass the TCK
> if
> tested), but may not have been tested.
>
>
Yes, that goes into the my misunderstanding of what TCK is. Some
systems can only say they are 'compliant' if they are 'certified' and
anything else is 'fraudulent'. Others allow for 'complaint' and
'certified' to be different.
In either case, I should have clarified with 'certified'.
> --
> Kevin P. Fleming
> He/Him/His
> Principal Program Manager, RHEL
> Red Hat US/Eastern Time Zone
> _______________________________________________
> 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
_______________________________________________
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
10:40 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Thursday, May 26, 2022, Kevin P. Fleming <kpfleming(a)redhat.com> wrote:
On 5/26/22 11:06, Stephen Smoogen wrote:
> 2. Are there ways that a non-TCK compliant version could be distributed?
>
I would suggest phrasing that slightly differently: the version being
distributed could very well be fully compliant (would pass the TCK if
tested), but may not have been tested.
Why would we do that? Is the build process really more important than
shipping tested software?
--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
_______________________________________________
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.or
g/archives/list/devel(a)lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
11:11 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 10:40, drago01 wrote:
Why would we do that? Is the build process really more important than
shipping tested software?
For Fedora? Yes.
Fedora includes lots of untested (in the formal, TCK sense) software.
It does not include non-FLOSS software (except maybe in very specific
circumstances such as firmware).
--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================
12:31 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Thursday, May 26, 2022, Ian Pilcher <arequipeno(a)gmail.com> wrote:
On 5/26/22 10:40, drago01 wrote:
> Why would we do that? Is the build process really more important than
> shipping tested software?
>
For Fedora? Yes.
Fedora includes lots of untested (in the formal, TCK sense) software.
It does not include non-FLOSS software (except maybe in very specific
circumstances such as firmware).
I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled libs
and properly tested / certified vs dynamic linking and less testing / no
certification.
--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================
_______________________________________________
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.or
g/archives/list/devel(a)lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
1:07 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote:
I am not talking about FLOSS vs non FLOSS, that's obvious. But
bundled libs
and properly tested / certified vs dynamic linking and less testing / no
certification.
I've been following this circular thread from the outset (And I do make
use of Fedora's JDK packages), but one thing I don't recall seeing is a
specific (or even general) example of the sort of failures/problems that
have come from linking against system libraries vs just using the
bundled ones.
Relatedly, I think it would also be very valuable to know if these
problems are mostly one-off (eg a major release of the jdk or dependent
library lands in rawhide and breakage ensues), or occur throughout a
specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a critical
security update which leads to a failure to pass TCK, or quarterly
java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to fedora's
bundled library libfoo version)
I mean, it's been strongly implied (if not outright stated) that
resolving these unspecified TCK failures, caused by using non-bundled
libraries, is the real burden, not the act of running the TCK for each
build -- but is the TCK (or upstream JDK) really that _brittle_?
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (libra.chat)
1:29 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
On Thu, 2022-05-26 at 14:07 -0400, Solomon Peachy wrote:
On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote:
> I am not talking about FLOSS vs non FLOSS, that's obvious. But
> bundled libs
> and properly tested / certified vs dynamic linking and less testing
> / no
> certification.
I've been following this circular thread from the outset (And I do
make
use of Fedora's JDK packages), but one thing I don't recall seeing is
a
specific (or even general) example of the sort of failures/problems
that
have come from linking against system libraries vs just using the
bundled ones.
Relatedly, I think it would also be very valuable to know if these
problems are mostly one-off (eg a major release of the jdk or
dependent
library lands in rawhide and breakage ensues), or occur throughout a
specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a
critical
security update which leads to a failure to pass TCK, or quarterly
java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to
fedora's
bundled library libfoo version)
I don't think that was the gist of it. I believe that it relates to the
numbers of OpenJDK we carry, and the difficulty faced by the packagers
of that to comply with packaging in Fedora's ecosystem when doing it.
Libraries are bundled into jars not the source, etc... this all
snowballs across what 4 version now supported? I don't remeber reading
about unspecified TCK failures, just the workload as a result of our
packaging requirements.
I mean, it's been strongly implied (if not outright stated) that
resolving these unspecified TCK failures, caused by using non-bundled
libraries, is the real burden, not the act of running the TCK for
each
build -- but is the TCK (or upstream JDK) really that _brittle_?
I built Netbeans for F36 Silverblue and when building it from source,
it still uses maven repo to download binary tools (maven plugin's) to
build with, this would be in violation of the packaging guidelines I
think. So to package it I would need to also package all of those
plugin's along side to support it in the Fedora Project ecosystem, just
for the actual build process.
Regards,
Stephen Snow
- Solomon
_______________________________________________
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
7:03 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 20:29, Stephen Snow wrote:
Libraries are bundled into jars not the source, etc... this all
snowballs across what 4 version now supported?
OpenJDK is a native ELF binary, not a JAR.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:26 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 12:31, drago01 wrote:
I am not talking about FLOSS vs non FLOSS, that's obvious. But
bundled
libs and properly tested / certified vs dynamic linking and less testing
/ no certification.
But if OpenJDK-based binaries can't be distributed without passing the
TCK, then it isn't really FLOSS.
--
========================================================================
Google Where SkyNet meets Idiocracy
========================================================================
7 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 19:31, drago01 wrote:
But bundled libs and properly tested / certified vs dynamic linking
and
less testing / no certification.
Bundled libraries are always outdated and even vulnerable. We should
avoid bundling as much as possible.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:30 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org>:
Bundled libraries are always outdated and even vulnerable.
Really sorry, but such a statement is simply intellectual bullshit. Unfortunately, it is
not possible to formulate this in a more friendly yet unambiguous way. And in this thread
in particular, the many allegations, unclouded by any expertise but made all the more
decisively, are simply annoying - and a huge waste of everyone’s time in the long run.
With technically correct workflow, there is at least a time x where the included libs are
not outdated and where vulnerability is unknown at worst. How someone comes up with
"always" is beyond me.
And whether to include a lib in a package is a tradeoff between various pros and cons.
Depending on the circumstances, the result is different.
The Change proposal correctly includes several reasons for consideration. And no viable
argument has yet been put forward as to why the consideration given is *necessarily*
incorrect.
Several conceivable alternatives would also be viable. But as long as no one is directly
affected in a negative way and no one comes forward to do the work involved with an
alternative, ....
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
10:37 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 27/05/2022 15:30, Peter Boy wrote:
Really sorry, but such a statement is simply intellectual bullshit.
Unfortunately, it is not possible to formulate this in a more friendly yet unambiguous
way. And in this thread in particular, the many allegations, unclouded by any expertise
but made all the more decisively, are simply annoying - and a huge waste of everyone’s
time in the long run.
But it's true.
One of my packages had a bundled library with 6 critical vulnerabilities
(outdated for 5 years). The upstream developers said they didn't care
because they needed their app to run under Ubuntu 12.04 LTS. Fixed it
manually by switching to the packaged version.
Another package had bundled OpenSSL, which was 3 years out of date.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11:36 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 27.05.2022 um 17:37 schrieb Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org>:
On 27/05/2022 15:30, Peter Boy wrote:
> Really sorry, but such a statement is simply intellectual bullshit. Unfortunately, it
is not possible to formulate this in a more friendly yet unambiguous way. And in this
thread in particular, the many allegations, unclouded by any expertise but made all the
more decisively, are simply annoying - and a huge waste of everyone’s time in the long
run.
But it's true.
One of my packages had a bundled library with 6 critical vulnerabilities (outdated for 5
years). The upstream developers said they didn't care because they needed their app to
run under Ubuntu 12.04 LTS. Fixed it manually by switching to the packaged version.
Another package had bundled OpenSSL, which was 3 years out of date.
Yes, but your examples and experiences are not related to a lib bundled or not, but it is
about the effort a maintainer puts in their package. We had also (unbundled) libs, which
were outdated and we had to wait a long time until a vulnerability was fixed.
And given the high quality of our openjdk packages and given experiences of the last
nearly 2 decades with the regularity of updates, I’m sure we get an openjdk update as soon
as an issue with one of the bundled libs arises.
And as an afterthought:
Sorry for the wording. I was (and I am) seriously annoyed by this thread (and some others
of that kind).
We have had such excellent Java JDKs for years and right now in the last 4 major JDK
versions in parallel, that is just great! It is allowing any developer to test their
software in a comprehensive and enterprise ready manner.
This deserves unrestricted respect and not this nagging about problems that are claimed
but do not exist. If someone is not so well versed in Java universe, no problem. Everyone
is welcome to ask questions, but not to throw any wild assertions into the room.
Thanks
Peter
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
9:04 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org>:
Bundled libraries are always outdated and even vulnerable.
Really sorry, but such a statement is simply intellectual bullshit. Unfortunately, it is
not possible to formulate this in a more friendly yet unambiguous way. And in this thread
in particular, the many allegations, unclouded by any expertise but made all the more
decisively, are simply annoying - and a huge waste of everyone’s time in the long run.
With technically correct workflow, there is at least a time x where the included libs are
not outdated and where vulnerability is unknown at worst. How someone comes up with
"always" is beyond me.
And whether to include a lib in a package is a tradeoff between various pros and cons.
Depending on the circumstances, the result is different.
The Change proposal correctly includes several reasons for consideration. And no viable
argument has yet been put forward as to why the consideration given is *necessarily*
incorrect.
Several conceivable alternatives would also be viable. But as long as no one is directly
affected in a negative way and no one comes forward to do the work involved with an
alternative, ....
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast
12:31 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Friday, May 27, 2022, Vitaly Zaitsev via devel <
devel(a)lists.fedoraproject.org> wrote:
On 26/05/2022 19:31, drago01 wrote:
> But bundled libs and properly tested / certified vs dynamic linking and
> less testing / no certification.
>
Bundled libraries are always outdated and even vulnerable. We should avoid
bundling as much as possible.
That's incorrect. They can be outdated, but there is no inherit reason why
they have to be.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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.or
g/archives/list/devel(a)lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
1:52 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 28/05/2022 19:31, drago01 wrote:
That's incorrect. They can be outdated, but there is no inherit
reason
why they have to be.
Most upstreams don't care about bundled libraries. They bundle them once
and then forget.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:04 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Sat, May 28, 2022 at 2:53 PM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 28/05/2022 19:31, drago01 wrote:
> That's incorrect. They can be outdated, but there is no inherit reason
> why they have to be.
Most upstreams don't care about bundled libraries. They bundle them once
and then forget.
Internally bundled libraries are an issue. I deal with it in the Samba
backports, enabling the Heimdal kerberos rather than Fedora and RHEL
built-in MIT Kerberos for better support from the Samba project. The
python s3transfer includes internal modules, as do the latest
ansible-core packages, and subversion has been a nightmare with SQLite
and other internal library dependencies on various platforms. It can
be quite difficult to keep them up to date.
7:57 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
On Sat, 28 May 2022 20:52:51 +0200, you wrote:
On 28/05/2022 19:31, drago01 wrote:
> That's incorrect. They can be outdated, but there is no inherit reason
> why they have to be.
Most upstreams don't care about bundled libraries. They bundle them once
and then forget.
But most != all as you claimed.
There is no indication that the JDK is such a thing - in fact given
the packagers are struggling that is a good indication that the JDK is
being regularly updated.
1:22 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Sun, May 29, 2022 at 2:57 AM Gerald Henriksen <ghenriks(a)gmail.com> wrote:
On Sat, 28 May 2022 20:52:51 +0200, you wrote:
>On 28/05/2022 19:31, drago01 wrote:
>> That's incorrect. They can be outdated, but there is no inherit reason
>> why they have to be.
>
>Most upstreams don't care about bundled libraries. They bundle them once
>and then forget.
But most != all as you claimed.
There is no indication that the JDK is such a thing - in fact given
the packagers are struggling that is a good indication that the JDK is
being regularly updated.
It could also imply the opposite (that is, the bundled libraries are
*not* being updated), if TCK failures are occurring simply because
we're dynamically linking those libraries.
--
真実はいつも一つ！/ Always, there's only one truth!
2:59 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 29/05/2022 02:57, Gerald Henriksen wrote:
There is no indication that the JDK is such a thing - in fact given
the packagers are struggling that is a good indication that the JDK is
being regularly updated.
Every 3 months in a patch release. I don't think maintainers will
manually backport patches to the bundled libraries.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:59 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 26/05/2022 17:40, drago01 wrote:
Why would we do that? Is the build process really more important than
shipping tested software?
Yes.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:48 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/26/22 14:17, Stephen Snow wrote:
Also, it may be good to take a look at what AdoptOpenJDK is doing
with
the Eclipse Foundation based Adoptium Project, specifically the Eclipse
Temurin subproject
https://projects.eclipse.org/proposals/eclipse-temurin-compliance which
is going to handle the compliance requirements.
In this scenerio the Eclipse Foundation is the license holder and the
Adoptium project submits to the Temurin project to get certified.
Maybe Fedora could use something similar with RH, who are signatories
on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project.
Just another thought on it.
That is just correct summary. That is exactly what wea re doing.
We certify with RH signatories.
J.
12:14 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18 2022 at 12:01:33 PM -0400, Neal Gompa
<ngompa13(a)gmail.com> wrote:
At this point, I'd rather have an OpenJDK in Fedora than not.
I'll bite: why? Just so that it's easily available via RPM? It's
starting to sound like Fedora would be providing very little value here
on top of what is offered by upstream. At a certain point, getting your
software directly from upstream might make more sense.
If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.
Provides: bundled(foo) is very important. With this, every time a CVE
is found in a dependent library, Product Security is going to report a
bug against Java, and it will be expected to be fixed in Java. It's a
lot of extra responsibility. Without the Provides, tracking such issues
is impractical. Every bundled library needs a Provides, not only the
ones that would be affected by this change.
Michael
12:32 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 19:14, Michael Catanzaro wrote:
Every bundled library needs a Provides, not only the ones that would
be
affected by this change.
Yes. And maintainers must include and keep up to date this information
in SPECs:
All packages whose upstreams have no mechanism to build against
system libraries MAY opt to carry bundled libraries, but if they do, they MUST include an
indication of what they bundle.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:29 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 19:14, Michael Catanzaro wrote:
On Wed, May 18 2022 at 12:01:33 PM -0400, Neal Gompa
<ngompa13(a)gmail.com> wrote:
> At this point, I'd rather have an OpenJDK in Fedora than not.
I'll bite: why? Just so that it's easily available via RPM? It's starting to
sound like Fedora would be providing very little value here on top of what is offered by
upstream. At a certain point, getting your software directly from upstream
might make more sense.
For leaf application this is siple. But for uttermost root of one huge depndency chain, it
would be bad.
> If that
> means switching to bundled libraries, then fine. But all bundled
> libraries need to be documented in the spec file and that information
> needs to be kept up to date.
Provides: bundled(foo) is very important. With this, every time a CVE is found in a
dependent library, Product Security is going to report a bug against Java, and it will be
expected to be fixed in Java. It's a lot of extra responsibility.
Without the Provides, tracking such issues is impractical. Every bundled library needs a
Provides, not only the ones that would be affected by this change.
I agree. and it will be there/
Michael
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
7:11 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:01, Neal Gompa wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On Wed, May 18, 2022 at 11:55 AM jiri vanek <jvanek(a)redhat.com>
wrote:
>
> You can imagine TCK as gigantic and pretty good testsuite, runing 24hours with quite
complicated setup. The pull and setup and run is completely autoamted, but it is a lot of
HW you need (all architecures x all oses x all jdks). In adition, you need human power to
keep with TCK evolution, sometimes to dapt setup, and to check resutls if they fails...
and.. to fix it. We have HW from Red hat, and we deal with failures we keep track with
usptream and TCK evolution. But it is not easy from human resources point of view.
At this point, I'd rather have an OpenJDK in Fedora than not. If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.
I deeply appreciate your understanding.
Can we do this without going down the route of building only once at
one distribution tag and tagging the binary into everything else?
If we do only this dirst part, then the TCK burden would not be lifted.
Still it make maintaneace much more easy.
11:32 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Hi Neal!
We are participating on Wakefield too. Why do you think JDK in feora should miss it ?
It does nto metter if it is static or dynamic one, it will just run correctly under
wayaland. Or do I miss something?
11:36 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 12:33 PM jiri vanek <jvanek(a)redhat.com> wrote:
Hi Neal!
We are participating on Wakefield too. Why do you think JDK in feora should miss it ?
It does nto metter if it is static or dynamic one, it will just run correctly under
wayaland. Or do I miss something?
The runtime libraries for integrating into Wayland are evolving at a
fast pace. Moreover, if you build only once on the oldest distribution
and tag up, it becomes even more difficult to take advantage of
improvements to Wayland components in the distribution. My gut feeling
is that changing OpenJDK to not rely on system libraries will make
this considerably harder because we will have to wait for upstream to
sync up and then pull it down. Additionally, depending on what their
CI target is, it may wind up being even more difficult because older
distributions *cannot* build some newer libraries because of missing
build or runtime components.
I've been dealing with that enough with KDE Plasma in Fedora and EPEL
that I'm concerned we'd be in trouble with Wakefield on Fedora with
this proposal.
--
真実はいつも一つ！/ Always, there's only one truth!
7:32 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:36, Neal Gompa wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On Wed, May 18, 2022 at 12:33 PM jiri vanek <jvanek(a)redhat.com>
wrote:
>
> Hi Neal!
>
> We are participating on Wakefield too. Why do you think JDK in feora should miss it
?
> It does nto metter if it is static or dynamic one, it will just run correctly under
wayaland. Or do I miss something?
The runtime libraries for integrating into Wayland are evolving at a
fast pace. Moreover, if you build only once on the oldest distribution
and tag up, it becomes even more difficult to take advantage of
improvements to Wayland components in the distribution. My gut feeling
is that changing OpenJDK to not rely on system libraries will make
this considerably harder because we will have to wait for upstream to
sync up and then pull it down. Additionally, depending on what their
CI target is, it may wind up being even more difficult because older
distributions *cannot* build some newer libraries because of missing
build or runtime components.
I've been dealing with that enough with KDE Plasma in Fedora and EPEL
that I'm concerned we'd be in trouble with Wakefield on Fedora with
this proposal.
Thanx for writing it up. As wakefield is targetting jdk 20 at soonest, I wil both keep it
in mind for wakefile project, and for Fedora jdk, this may be an interesting testing how
the bundling actually works.
My rough assumtpion would be, that it will remain runtime-laoding part, as JDK have to
decide, if it is on X or Wayland, and load acordingly.
10:29 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Once upon a time, Daniel P. Berrangé <berrange(a)redhat.com> said:
At its heart the certification is a "sticker" that asserts
our
JDK has passed the TCK test suite. IOW, saying that we don't need
certification of JDK is effectively saying that we don't need to do
testing of JDK in Fedora. Comprehensive testing of software is
something that very much does benefit Fedora and its users, and we
could do with a whole lot more of it in general. Further elsewhere
in this thread it has been clearly said that users of JDKs do
indeed value the certification as a sign of quality. So I don't
think we can credibly claim that certification is not needed.
In this thread it was claimed (I believe by a packager) that TCK is
important to Java users, but I haven't seen any users say that.
I'm not a Java user... I had never heard of TCK. I just went searching,
and I don't see anything right off that shows that Fedora's OpenJDK is
certified in any way. How would I even know?
--
Chris Adams <linux(a)cmadams.net>
7:09 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams
wrote:(snip unrelated) ...
In this thread it was claimed (I believe by a packager) that TCK is
important to Java users, but I haven't seen any users say that.
I'm not a Java user... I had never heard of TCK. I just went
searching,
and I don't see anything right off that shows that Fedora's OpenJDK
is
certified in any way. How would I even know?
Below is the link to the JCK/TCK and to be able to use the OpenJDK name
you must sign the agreement and then you get access to the JCK which is
the certification test API. Then you get to run certification tests for
every build, if I read the agreement correctly.
https://openjdk.java.net/groups/conformance/JckAccess/
If I could just add one more thing to this discussion. I would like to
point out Fedora's First foundation as applicable WRT the java
ecosystem. Do we need OpenJDK 8? I mean I would think that Latest +1 in
Rawhide, Latest and latest -1 on current Fedora Release, then latest
and latest -1 and latest -2 on the due to eol at next release Fedora.
I too use the system OpenJDK for java development, and the packaged ant
and the packaged Maven, successfully and consistently on Fedora Linux
for some years. Just yesterday I built the Netbeans IDE 13 using them
in a toolbox container on my Silverblue box.All I had to install in the
toolbox was java-17-openjdk-devel.x86_64 and ant from the Fedora Linux
repos.
I haven't had a need to use OpenJDK 8 in over two years now, and the
last time I had to do anything with OpenJDK 11 was some 8 months ago. I
don't have much Enterprise level development/support requirements so my
use cases are sot like others, but the bulk of my java development is
with OpenJDK 17 and with the packaged Fedora OpenJDK.
If I remember the IDE exodus correctly, it was driven by issue overload
on the part of upstream, in some cases I think those packaging for
Fedora didn't get the attention needed to keep successfully packaging.
I also think it was distro agnostic, meaning it happened everywhere.
Hence flatpaks and snap apps.
One more point, the reason I built Netbeans instead of using the
Flatpak version available was it works better for me as a host package.
The flatpak version has issue finding the system libraries which forces
you to copy in multiple jar libraries for one.
Thank you everyone who helps maintain the current offering of Java and
tools.
Regards,
Stephen
--
Chris Adams <linux(a)cmadams.net>
_______________________________________________
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
7:27 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Once upon a time, Stephen Snow <s40w5s(a)gmail.com> said:
Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams
wrote:(snip unrelated) ...
> In this thread it was claimed (I believe by a packager) that TCK is
> important to Java users, but I haven't seen any users say that.
>
> I'm not a Java user... I had never heard of TCK. I just went
> searching,
> and I don't see anything right off that shows that Fedora's OpenJDK
> is
> certified in any way. How would I even know?
>
Below is the link to the JCK/TCK and to be able to use the OpenJDK name
you must sign the agreement and then you get access to the JCK which is
the certification test API. Then you get to run certification tests for
every build, if I read the agreement correctly.
https://openjdk.java.net/groups/conformance/JckAccess/
That's a list of organizations that have signed the agreement (which
notably for this discussion, does not include Fedora). I don't see a
list of "passed the test", nor do I see something on the Fedora packages
that says "passed the test". The claim was made that this test is
important for Java users, yet I can't find any indication that Fedora's
(or anybody's for that matter) pass it.
Testing is great and important, but saying that users care about the
results of the testing is hard to understand when the test results
appear to be undocumented.
--
Chris Adams <linux(a)cmadams.net>
7:55 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-18 at 07:27 -0500, Chris Adams wrote:
Once upon a time, Stephen Snow <s40w5s(a)gmail.com> said:
> Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams
> wrote:(snip unrelated) ...
> > In this thread it was claimed (I believe by a packager) that TCK
> > is
> > important to Java users, but I haven't seen any users say that.
> >
> > I'm not a Java user... I had never heard of TCK. I just went
> > searching,
> > and I don't see anything right off that shows that Fedora's
> > OpenJDK
> > is
> > certified in any way. How would I even know?
> >
> Below is the link to the JCK/TCK and to be able to use the OpenJDK
> name
> you must sign the agreement and then you get access to the JCK
> which is
> the certification test API. Then you get to run certification tests
> for
> every build, if I read the agreement correctly.
> https://openjdk.java.net/groups/conformance/JckAccess/
That's a list of organizations that have signed the agreement (which
notably for this discussion, does not include Fedora).
But does include Redhat,
which in this case obviously supports Fedora.
I don't see a
list of "passed the test", nor do I see something on the Fedora
packages
that says "passed the test". The claim was made that this test is
important for Java users, yet I can't find any indication that
Fedora's
(or anybody's for that matter) pass it.
It's a licensing agreement effectively. It provides the distribution
with early access toolkits and Technology Compatability Kits AFAIK from
reading the licensing agreement. There is also some emphasis on being a
good community member and contributing, but it looks like a purely
legal intent being applied to technical compatability source code.
Testing is great and important, but saying that users care about the
results of the testing is hard to understand when the test results
appear to be undocumented.
I would think the "Technical Compatability" benefit is self evident,
even for "users". For one thing it helps continue the build once
distribute anywhere slogan of Java, but it also gives a modicum of
confidence to users that there is a "standard" being applied.
So, from reading the info, the tests are likely part of the toolkit and
you don't get to see the toolkit until you sign the papers. This seems
sort of the antithesis of FOSS don't it?
Regards,
Stephen
--
Chris Adams <linux(a)cmadams.net>
_______________________________________________
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
7:39 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
V Wed, May 18, 2022 at 08:09:06AM -0400, Stephen Snow napsal(a):
Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams
wrote:(snip unrelated) ...
> In this thread it was claimed (I believe by a packager) that TCK is
> important to Java users, but I haven't seen any users say that.
>
> I'm not a Java user... I had never heard of TCK. I just went searching,
> and I don't see anything right off that shows that Fedora's OpenJDK is
> certified in any way. How would I even know?
>
Below is the link to the JCK/TCK and to be able to use the OpenJDK name you
must sign the agreement and then you get access to the JCK which is the
certification test API. Then you get to run certification tests for every
build, if I read the agreement correctly.
https://openjdk.java.net/groups/conformance/JckAccess/
Is that (OpenJDK) still a free software? I mean the rights to modify and
redistribute? If it isn't, is it suitable for Fedora? Or is too big to fail
like the case of Firefox which we cannot call Firefox if we patch it.
-- Petr
8:09 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
On Wed, 2022-05-18 at 14:39 +0200, Petr Pisar wrote:
V Wed, May 18, 2022 at 08:09:06AM -0400, Stephen Snow napsal(a):
> Once upon a time On Tue, 2022-05-17 at 10:29 -0500, Chris Adams
> wrote:(snip unrelated) ...
> > In this thread it was claimed (I believe by a packager) that TCK
> > is
> > important to Java users, but I haven't seen any users say that.
> >
> > I'm not a Java user... I had never heard of TCK. I just went
> > searching,
> > and I don't see anything right off that shows that Fedora's
> > OpenJDK is
> > certified in any way. How would I even know?
> >
> Below is the link to the JCK/TCK and to be able to use the OpenJDK
> name you
> must sign the agreement and then you get access to the JCK which is
> the
> certification test API. Then you get to run certification tests for
> every
> build, if I read the agreement correctly.
> https://openjdk.java.net/groups/conformance/JckAccess/
>
Is that (OpenJDK) still a free software? I mean the rights to modify
and
redistribute? If it isn't, is it suitable for Fedora? Or is too big
to fail
like the case of Firefox which we cannot call Firefox if we patch it.
Sorry my bad, the agreement is for being a contributor to the Oracle
Open Community at https://oca.opensource.oracle.com/ not licensing for
redistribution. I am not in any way giving legal advice here, just
providing the info I could find. I think this is still a necessary if
you want to seriously have any Java development stack available to
Fedora Linux users though. Otherwise, it is totally doable in a self
supported way by each dev, and I'm sure they all know how to but, I
really like the fact that my distribution provides this now, it works.
Stephen
-- Petr
_______________________________________________
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
9:44 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 14:09, Stephen Snow wrote:
Below is the link to the JCK/TCK and to be able to use the OpenJDK
name
you must sign the agreement and then you get access to the JCK which is
the certification test API.
That means that OpenJDK is no longer a free software and can't be
distributed by Fedora at all.
CC: Fedora Legal team.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:56 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
One one side it is good testsuite, on second something yo have to pass to publish. So if
users in fedora should have distribution-packed JDKs, someone have to run (At least)
them.
10:51 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
You can not put uncertified JDK to fedora. And we can no longer properly support
certified dynamic builds. We realy do no like this change, but we do not see another way.
11:34 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 18/05/2022 17:51, jiri vanek wrote:
You can not put uncertified JDK to fedora.
Why not?
And we can no longer properly support certified dynamic builds
Hire new maintainers who can.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
7:33 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/18/22 18:34, Vitaly Zaitsev via devel wrote:
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
On 18/05/2022 17:51, jiri vanek wrote:
> You can not put uncertified JDK to fedora.
Why not?
> And we can no longer properly support certified dynamic builds
Hire new maintainers who can.
Who shold hire them. You? Me? Fedoraproject?
7:58 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 20/05/2022 14:33, Jiri Vanek wrote:
Who shold hire them. You? Me? Fedoraproject?
Red Hat.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:43 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Mon, May 16, 2022 at 09:13:32PM +0200, Jiri Vanek wrote:
Hello!
My apologies, I had accidentally dropped out of computer world for a while, and here a
world spins ahead! Thanx a lot for many valuable feedback!
see the clarifications of most concerns:
This mail appears to have copied in quoted text from many differnt
messages in this thread, with no attribution of the author. This
is very confusing and disruptive for following the conversation :-(
Ideally please reply inline to the original mails.
> I cannot see how Fedora RPM packages for OpenJDK can
redistributing pre-built binaries would ever be considered acceptable.
no, no and no again, Please see the linked
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
In long run, we will build in koji once, and repack this to all live fedoras. There alre
already prcednets, and even worse things - like packing blobish binary driver, are here.
If we consider Fedora koji tag inheritance, to a limited degree we do
implicitly already have the ability to build once and have it deployed
on multiple Fedora versions. It just only applies to Fedora versions
that arrive after the original build.
eg if you built a package in Rawhide today, and never rebuilt it again
for the next year, the one binary RPM would end up shipped to users in
Fedora 37, 38 and 39. To some extent this does happen - on my Fedora
36 install, I've got about 40 packages with an fc35 dist-tag in the
RPM release, and 2 with an fc34 dist-tag.
In practice the mass rebuilds happen frequently enough to kill off
inheritance across releases for most packages. Then for any non-trivial
app there is usually a need for bug fix releases, which again kill off
the inheritance.
The point is that, AFAICT, there's no hard Fedora rule that forbids
us having one binary RPM build shipped to multiple Fedora relases.
(Or if there is such a rule, we're not enforcing it). It is just
the practicalities of mass rebuilds and bug fix releases that mean
it ends up being quite an exceptional case to share binaries across
releases.
Lets say we have a single JDK build that was done in Fedora 35
a year ago, and thus now present in F35, F36 & F37-rawhide.
If a bug fix is needed, we can't simply build in current F35 build
roots, since they include all subsequent F35 updates.
We have a record of all the packages there were in the original
F35 rawhide build root though. It would conceptually be viable
to populate a build root with that original deps set, do a bug
fix build, and tag that result into all subsequent releases.
We don't have a way to actually put that into practice, which
I guess motivates some of the re-packaging hoops the JDK proposal
is wanting to jump through. Perhaps we can come up with a more
supportable way to achieve this goal instead.
NB, I'm assuming the shared libs that JDK depends on don't do
ELF soname changes. I presume this is where the desire for static
linking starts to come into play. Again static linking is not
something totally excluded by Fedora - it just requires a good
justification to be made
> One downside with building in F35 and then re-tagging into newer
Fedora
releases, is that we loose any insight into problems coming down the pipe.
Currently a Fedora rawhide mass rebuild will often highlight pre-existing
bugs in applications, and/or highlight bugs in newly rebased GCC
toolchain....Detecting bugs early in both applications and GCC toolchain,
via builds in rawhide...
Right you are, and it is already described in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Rawhide...
We are very well aware of this benefit, and we will do our best to keep it running - eg
to build portbales also in rawhide, although not to repack them. Just for this single -
but huge - case.
We deeply agree with your description of rawhide and gcc bumps. Thanx a lot for
highligting it.
I wonder if it is possible to have the best of both worlds with two
streams.
What if new major JDKs were *only* added to rawhide, not existing releases.
IOW, Fedora 35 would be frozen with the set of JDK major versions that
existed at time of F35 branching off rawhide. Thereafter it only gets bug
fix releases of existing major versions.
In addition the certification is only done for the initial new major
version build in rawhide, not subsequent bug fix builds.
This would let the main Fedora JDK packages be fairly normal in terms
of maintenence approach, and reduce the JDK certification process burden.
Separate from that, have a module stream for portable JDK. The module
build root populated with the oldest current Fedora stable release,
minus any updates. Builds can be done static linked, and the module
results made available to all Fedora streams. Every bug fix build
goes through ceritfication, and adding new JDK major versions doesnt
have combinatorial expansion of certification.
Of course the obvious problem here is how to explain to users which
JDK they should be preferring. If we just tell people to always use
the portable version, then having the "regular" distro strweam version
is kinda pointless and vica-verca.
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 :|
1:14 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
Hi,
Ben Cotton <bcotton(a)redhat.com> writes:
According to short investigations, there are already precedents,
where
certification is a reason to build once, certificate, and repack.
This sounds fascinating. Can anyone share details about this? On the
surface, building something once and packaging that up for all Fedora
versions in an RPM sounds like it would violate all the guidelines under
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
Is there a sense of what defines "certification" in this context? What
would it take for a random package $foo to meet this threshold and claim
it needs to avoid rebuilding for certification?
Thanks,
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
4:20 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 6:29 AM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This is initial step to move JDKs to be more like other JDKs, to build
proper transferable images, and to lower certification burden of each
binary. Long storyshort, first step in:
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
This first step will move, one by one, individual JDKs in F37 to be
built `--with-stdc++lib=static` and against in-tree (bundeld)
libraries: `--with-zlib="bundled" --with-freetype="bundled"
--with-libjpeg="bundled" --with-giflib="bundled"
--withlibpng="bundled" --with-lcms="bundled"
--with-harfbuzz="bundled" `
We already made a heavy testing of the behavior, and user should not
face negative experience. I'm not sure if this is
I'm very confused on why this reduces certification burden. In our
crypto libraries this is exactly the kind of behavior we would *NOT*
want packages to do because it increases our certification and support
burden.
bob
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
for whole picture
Please see
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JD...
for this particular step. I would rather keep the details in the main
page then here.
== Feedback ==
According to short investigations, there are already precedents, where
certification is a reason to build once, certificate, and repack.
According to developers, the non-portbale JDK is causing upredicted
behavior different from other JDK vendors
According to JDK packagers and testers, there is to much JDKs now, and
the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fe...
is the only way out
== Benefit to Fedora ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation
for whole picture.
This particular proposal's main benefit will be that Fedora's JDKs as
packed in RPMs will again start to resemble upstream JDKs and other
vendors build, and some platform specific issues disappear, while JDKs
remain same in view of system integration and user experience
== Scope ==
* Proposal owners: push improved version of
https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#re...
to all JDKs - one by one from latest, over 17 to 11 and 8. Once
settled down in F37 the backport to F36 is expected.
* Other developers: really, nothing. If there will be unexpected
impact to other developers, the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may
need rework
* Release engineering: N/A [https://pagure.io/releng/issues #Releng
issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The compatibility and upgrade path should remain completely smooth.
== How To Test ==
Install system JDK (java-17-openjdk) and ru your favorite application
or development. No regression should be noted.
== User Experience ==
Because of in-tree libraries, minimal image or font rendering
differences canbe spotted after very detailed investigations -
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_ef...
- still, no of th e
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_i...
should be hit by this proposal.
== Dependencies ==
No dependent packages should notice the change.
== Contingency Plan ==
* Contingency mechanism: Revert the patches and rework
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
* Contingency deadline: before f37 release
* Blocks release? Unless the java-stack will become completely borked then no.
== Documentation ==
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
4:50 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 5:20 PM Robert Relyea <rrelyea(a)redhat.com> wrote:
On 5/10/22 6:29 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
>
> This first step will move, one by one, individual JDKs in F37 to be
> built `--with-stdc++lib=static` and against in-tree (bundeld)
> libraries: `--with-zlib="bundled" --with-freetype="bundled"
> --with-libjpeg="bundled" --with-giflib="bundled"
> --withlibpng="bundled" --with-lcms="bundled"
> --with-harfbuzz="bundled" `
>
> We already made a heavy testing of the behavior, and user should not
> face negative experience. I'm not sure if this is
I'm very confused on why this reduces certification burden. In our
crypto libraries this is exactly the kind of behavior we would *NOT*
want packages to do because it increases our certification and support
burden.
I'm confused how this would not negatively impact the user experience,
because things like FreeType and HarfBuzz in Fedora have features and
configuration that are non-default that improve the font rendering
capabilities of applications that link to FreeType. I would rather
have our shared maintenance and evolution of font stuff be reused in
Java too...
--
真実はいつも一つ！/ Always, there's only one truth!
5:58 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 11:51 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, May 10, 2022 at 5:20 PM Robert Relyea <rrelyea(a)redhat.com> wrote:
>
> On 5/10/22 6:29 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > This is initial step to move JDKs to be more like other JDKs, to build
> > proper transferable images, and to lower certification burden of each
> > binary. Long storyshort, first step in:
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> >
> > This first step will move, one by one, individual JDKs in F37 to be
> > built `--with-stdc++lib=static` and against in-tree (bundeld)
> > libraries: `--with-zlib="bundled"
--with-freetype="bundled"
> > --with-libjpeg="bundled" --with-giflib="bundled"
> > --withlibpng="bundled" --with-lcms="bundled"
> > --with-harfbuzz="bundled" `
> >
> > We already made a heavy testing of the behavior, and user should not
> > face negative experience. I'm not sure if this is
>
> I'm very confused on why this reduces certification burden. In our
> crypto libraries this is exactly the kind of behavior we would *NOT*
> want packages to do because it increases our certification and support
> burden.
>
I'm confused how this would not negatively impact the user experience,
because things like FreeType and HarfBuzz in Fedora have features and
configuration that are non-default that improve the font rendering
capabilities of applications that link to FreeType. I would rather
have our shared maintenance and evolution of font stuff be reused in
Java too...
I agree, I don't think there's positives for the user experience here.
And I don't understand what actual problem this change is trying to
solve?
Are people really installing OpenJDK RPM packages, taking the
"/usr/bin/java" binary, and putting it onto some other system?
Unless that's really the case (and I don't think that should even ever
be supported for distro packages), I don't see a reason to change how
we build OpenJDK.
Also, I am particularly concerned with this statement from the linked
follow-up change:
"After this change is in air, we will certificate each binary only
once, and redistribute."
I cannot see how Fedora RPM packages for OpenJDK can redistributing
pre-built binaries would ever be considered acceptable.
Fabio
3:44 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 11, 2022 at 12:58:22AM +0200, Fabio Valentini wrote:
On Tue, May 10, 2022 at 11:51 PM Neal Gompa
<ngompa13(a)gmail.com> wrote:
>
> On Tue, May 10, 2022 at 5:20 PM Robert Relyea <rrelyea(a)redhat.com> wrote:
> >
> > On 5/10/22 6:29 AM, Ben Cotton wrote:
> > > https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> > >
> > > This document represents a proposed Change. As part of the Changes
> > > process, proposals are publicly announced in order to receive
> > > community feedback. This proposal will only be implemented if approved
> > > by the Fedora Engineering Steering Committee.
> > >
> > > == Summary ==
> > > This is initial step to move JDKs to be more like other JDKs, to build
> > > proper transferable images, and to lower certification burden of each
> > > binary. Long storyshort, first step in:
> > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> > >
> > > This first step will move, one by one, individual JDKs in F37 to be
> > > built `--with-stdc++lib=static` and against in-tree (bundeld)
> > > libraries: `--with-zlib="bundled"
--with-freetype="bundled"
> > > --with-libjpeg="bundled" --with-giflib="bundled"
> > > --withlibpng="bundled" --with-lcms="bundled"
> > > --with-harfbuzz="bundled" `
> > >
> > > We already made a heavy testing of the behavior, and user should not
> > > face negative experience. I'm not sure if this is
> >
> > I'm very confused on why this reduces certification burden. In our
> > crypto libraries this is exactly the kind of behavior we would *NOT*
> > want packages to do because it increases our certification and support
> > burden.
> >
>
> I'm confused how this would not negatively impact the user experience,
> because things like FreeType and HarfBuzz in Fedora have features and
> configuration that are non-default that improve the font rendering
> capabilities of applications that link to FreeType. I would rather
> have our shared maintenance and evolution of font stuff be reused in
> Java too...
I agree, I don't think there's positives for the user experience here.
And I don't understand what actual problem this change is trying to
solve?
Are people really installing OpenJDK RPM packages, taking the
"/usr/bin/java" binary, and putting it onto some other system?
Unless that's really the case (and I don't think that should even ever
be supported for distro packages), I don't see a reason to change how
we build OpenJDK.
When the change talks about being "portable", my understanding is that
means within the context of Fedora. eg they want to be able to build the
JDK version in a Fedora 35 build root once, and then ship that built
binary in Fedora 35, Fedora 36 and Fedora rawhide (37) by just tagging
the F35 build into the newer Fedora koji tags too, instead of rebuilding
for each Fedora version.
Also, I am particularly concerned with this statement from the
linked
follow-up change:
"After this change is in air, we will certificate each binary only
once, and redistribute."
I cannot see how Fedora RPM packages for OpenJDK can redistributing
pre-built binaries would ever be considered acceptable.
Normally when we talk about forbidding pre-built binaries, it is
because said binaries were built by a 3rd party into whose build
system Fdora has no visibility. This case appears different in
that Fedora is still building the binaries in one release stream,
but these pre-built binarijes are then copied into another
releases stream. Thus Fedora would still have visibility into the
build process, albeit in a rather convoluted way, compared to
normally maintained package.
One downside with building in F35 and then re-tagging into newer
Fedora releases, is that we loose any insight into problems coming
down the pipe. Currently a Fedora rawhide mass rebuild will often
highlight pre-existing bugs in applications, and/or highlight bugs
in newly rebased GCC toolchain.
If the JDK is only really being built in the oldest stable Fedora
release, then we loose this early detection of problems. If a GCC
rebase has a bug that impacts JDK, we'd potentially only discover
it many many months later once that rawhide becomes the oldest
stable Fedora release, and an attempt is made to build new JDK.
Detecting bugs early in both applications and GCC toolchain, via
builds in rawhide is a really critical aspect of our dev model.
IME rawhide is the place where it is cheapest to fix problems &
least disruptive to our users, because we have time to find and
fix issues before they get into release.
Yes, it is tedious for package maintainers when their specific
app breaks in rawhide due to a toolchain regression, but it is
a win for Fedora as a whole to find these problems quickly.
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 :|
4:33 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 11/05/2022 10:44, Daniel P. Berrangé wrote:
JDK version in a Fedora 35 build root once, and then ship that built
binary in Fedora 35, Fedora 36 and Fedora rawhide (37) by just tagging
the F35 build into the newer Fedora koji tags too, instead of rebuilding
for each Fedora version.
This is so bad. The final death of Java on Fedora.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:48 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 11:52 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
I'm confused how this would not negatively impact the user
experience,
because things like FreeType and HarfBuzz in Fedora have features and
configuration that are non-default that improve the font rendering
capabilities of applications that link to FreeType. I would rather
have our shared maintenance and evolution of font stuff be reused in
Java too...
The rendering is always done in OpenJDK, those libraries are not used
for the actual rendering.
The generation of glyphs types and the metrics are obtained via those
libraries, but it's been ages since the old patented algorithms would
produce better quality, and anyway those would not be available in
Fedora anyway.
There are settings that influence the rendering, which is why
sometimes users have worse quality on KDE vs Gnome, but those aren't
settings in the libraries, are configurations such as environment
variables or gnome properties.
If you experience font quality differences, I would pretty much like
to know, this would be a bug.
They would also be very surprising though, applications such as
IntelliJ bundle their own JDKs, I recall once one argument was exactly
because of "better" font rendering, which is clearly not an actual
argument.
Btw, I know this because I fixed a gazillion font related bugs in
OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I
rarely ever had to touch 8 or later.
Cheers,
Mario
--
Mario Torre
Manager, Software Engineering, OpenJDK
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
Red Hat GmbH, Registered seat: Werner von Siemens Ring 14, D-85630
Grasbrunn, Germany
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross
9:22 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 18, 2022 at 9:49 AM Mario Torre <neugens(a)redhat.com> wrote:
On Tue, May 10, 2022 at 11:52 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> I'm confused how this would not negatively impact the user experience,
> because things like FreeType and HarfBuzz in Fedora have features and
> configuration that are non-default that improve the font rendering
> capabilities of applications that link to FreeType. I would rather
> have our shared maintenance and evolution of font stuff be reused in
> Java too...
The rendering is always done in OpenJDK, those libraries are not used
for the actual rendering.
The generation of glyphs types and the metrics are obtained via those
libraries, but it's been ages since the old patented algorithms would
produce better quality, and anyway those would not be available in
Fedora anyway.
There are settings that influence the rendering, which is why
sometimes users have worse quality on KDE vs Gnome, but those aren't
settings in the libraries, are configurations such as environment
variables or gnome properties.
If you experience font quality differences, I would pretty much like
to know, this would be a bug.
They would also be very surprising though, applications such as
IntelliJ bundle their own JDKs, I recall once one argument was exactly
because of "better" font rendering, which is clearly not an actual
argument.
Btw, I know this because I fixed a gazillion font related bugs in
OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I
rarely ever had to touch 8 or later.
I make my own IntelliJ packages for my own use that rips out their
Java runtime and uses Fedora's OpenJDK. :)
--
真実はいつも一つ！/ Always, there's only one truth!
7:06 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
> Btw, I know this because I fixed a gazillion font related bugs
in
> OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I
> rarely ever had to touch 8 or later.
>
I make my own IntelliJ packages for my own use that rips out their
Java runtime and uses Fedora's OpenJDK. :)
Idea still provides that JBR-less tarball isnt it?
Also the idealauncher honour java_home, so it can work with "any" jdk.
I run idea only with fedora system jdk, and if I find some trace of JBR, it is removed
withotu compromises.
HAd issues with thsi just recenlty, after f36 udpate, which have java-17-oepnjdk suddnely,
whch idea was not ready. dnf install of 11 resovled it withotu issues
7:09 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Just to repeat i one more times, and maybe a bit more loudly - the rendering seems to be
SAME for both static and dynamic linking.
Please anybody who complains in this thread, can yo have any proof that dynamic linking
really makes yor eyes bleed??
J.
On 5/18/22 15:48, Mario Torre wrote:
On Tue, May 10, 2022 at 11:52 PM Neal Gompa
<ngompa13(a)gmail.com> wrote:
> I'm confused how this would not negatively impact the user experience,
> because things like FreeType and HarfBuzz in Fedora have features and
> configuration that are non-default that improve the font rendering
> capabilities of applications that link to FreeType. I would rather
> have our shared maintenance and evolution of font stuff be reused in
> Java too...
The rendering is always done in OpenJDK, those libraries are not used
for the actual rendering.
The generation of glyphs types and the metrics are obtained via those
libraries, but it's been ages since the old patented algorithms would
produce better quality, and anyway those would not be available in
Fedora anyway.
There are settings that influence the rendering, which is why
sometimes users have worse quality on KDE vs Gnome, but those aren't
settings in the libraries, are configurations such as environment
variables or gnome properties.
If you experience font quality differences, I would pretty much like
to know, this would be a bug.
They would also be very surprising though, applications such as
IntelliJ bundle their own JDKs, I recall once one argument was exactly
because of "better" font rendering, which is clearly not an actual
argument.
Btw, I know this because I fixed a gazillion font related bugs in
OpenJDK in the past, most of which in the OpenJDK 6 and 7 era, I
rarely ever had to touch 8 or later.
Cheers,
Mario
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
6:07 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Ben Cotton wrote:
== Summary ==
This is initial step to move JDKs to be more like other JDKs, to build
proper transferable images, and to lower certification burden of each
binary. Long storyshort, first step in:
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
This first step will move, one by one, individual JDKs in F37 to be
built `--with-stdc++lib=static` and against in-tree (bundeld)
libraries: `--with-zlib="bundled" --with-freetype="bundled"
--with-libjpeg="bundled" --with-giflib="bundled"
--withlibpng="bundled" --with-lcms="bundled"
--with-harfbuzz="bundled" `
We already made a heavy testing of the behavior, and user should not
face negative experience. I'm not sure if this is
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
Let me join the train of -1 votes. I consider this a step entirely in the
wrong direction. The JDK should be linked to system libraries wherever
possible just like our other packages. Language interpreters/JITs are not
exempt from that. In fact, I see very little value in providing JDK packages
at all if they are built that way.
== Detailed Description ==
Please see
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for
whole picture
And this plan is entirely unacceptable. It is just plain not allowed in
Fedora to ship prebuilt binary blobs (even if they are built by Fedora
developers), packages are required to be built from source, and that
requirement is there for good reasons. There have so far been no exceptions
whatsoever to this rule (except temporarily for bootstrapping purposes,
conditional on replacing the prebuilt binary with a rebuilt bootstrapped
package before releasing it). I do not see any reason why Java should get an
exception there.
If passing the TCK is such an issue, then please just go back to shipping
the packages under the name IcedTea or some other name not trademarked by
Oracle. With Provides and Obsoletes in place, this will make very little
difference in practice for the end user.
Kevin Kofler
9:53 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 01:07 Wed 11 May , Kevin Kofler via devel wrote:
Ben Cotton wrote:
> == Summary ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
>
> This first step will move, one by one, individual JDKs in F37 to be
> built `--with-stdc++lib=static` and against in-tree (bundeld)
> libraries: `--with-zlib="bundled" --with-freetype="bundled"
> --with-libjpeg="bundled" --with-giflib="bundled"
> --withlibpng="bundled" --with-lcms="bundled"
> --with-harfbuzz="bundled" `
>
> We already made a heavy testing of the behavior, and user should not
> face negative experience. I'm not sure if this is
>
> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> * Email: jvanek(a)redhat.com
Let me join the train of -1 votes. I consider this a step entirely in the
wrong direction. The JDK should be linked to system libraries wherever
possible just like our other packages. Language interpreters/JITs are not
exempt from that. In fact, I see very little value in providing JDK packages
at all if they are built that way.
I expect JDK users would disagree with you. JDKs from other vendors
(Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and
likely other GNU/Linux distributions) are the exception here.
> == Detailed Description ==
> Please see
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs for
> whole picture
And this plan is entirely unacceptable. It is just plain not allowed in
Fedora to ship prebuilt binary blobs (even if they are built by Fedora
developers), packages are required to be built from source, and that
requirement is there for good reasons. There have so far been no exceptions
whatsoever to this rule (except temporarily for bootstrapping purposes,
conditional on replacing the prebuilt binary with a rebuilt bootstrapped
package before releasing it). I do not see any reason why Java should get an
exception there.
If passing the TCK is such an issue, then please just go back to shipping
the packages under the name IcedTea or some other name not trademarked by
Oracle. With Provides and Obsoletes in place, this will make very little
difference in practice for the end user.
It's not a trademark issue [0], but one of user confidence in what is
being provided. The "OpenJDK" name can be used as long as it's OpenJDK
code that is being built, and not, say, the OpenJDK libraries combined
with a non-OpenJDK virtual machine.
I think the alternative would be that we reduced testing in a similar way
e.g. only run the TCK on the latest released Fedora for each JDK.
Kevin Kofler
_______________________________________________
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
[0] https://openjdk.java.net/legal/openjdk-trademark-notice.html
--
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
10:18 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 16/05/2022 16:53, Andrew Hughes wrote:
I expect JDK users would disagree with you. JDKs from other vendors
(Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and
likely other GNU/Linux distributions) are the exception here.
Because they build it for all available GNU/Linux distributions. We
shouldn't focus on bad practices.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:15 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)
Andrew Hughes wrote:
On 01:07 Wed 11 May , Kevin Kofler via devel wrote:
> Let me join the train of -1 votes. I consider this a step entirely in the
> wrong direction. The JDK should be linked to system libraries wherever
> possible just like our other packages. Language interpreters/JITs are not
> exempt from that. In fact, I see very little value in providing JDK
> packages at all if they are built that way.
I expect JDK users would disagree with you.
I *am* a JDK user. I use the JDK and JRE for work. I have been using the
Fedora-provided OpenJDK RPMs all this time, and I have never encountered any
issue caused by how they are built.
In fact, quite the opposite: Our servers' Let's Encrypt certificates just
worked out of the box with the Fedora-provided OpenJDK (due to the use of
the system root CA list) whereas Windows JDK builds had required workarounds
for quite a while until Oracle finally fixed their CA list.
In my experience, the packages are 100% compatible with other OpenJDK
builds, including the proprietary Oracle JDK, and the fact that they pass
the TCK actually more or less proves that they are.
Use of system libraries is exactly what I expect from a distribution package
of OpenJDK.
JDKs from other vendors (Amazon, Azul, Oracle, etc.) are built in
exactly
this way. We (and likely other GNU/Linux distributions) are the exception
here.
And that difference is the entire point of building distribution packages of
OpenJDK at all. I see very little value in a "Fedora" OpenJDK build over
just using Adoptium Temurin binaries if they are built the exact same way.
Well, there is the ease of installing and updating due to being packaged in
an RPM, but an RPM repository could also be provided by Red Hat through
Adoptium.
I expect from a package in the Fedora repository to follow Fedora guidelines
and best practices, which includes using system libraries wherever possible,
and being built on the Fedora release for which it is shipped (or for the
initial version in a new Fedora release, on a Rawhide no older than the
latest mass rebuild).
It's not a trademark issue [0], but one of user confidence in
what is
being provided. The "OpenJDK" name can be used as long as it's OpenJDK
code that is being built, and not, say, the OpenJDK libraries combined
with a non-OpenJDK virtual machine.
I think the alternative would be that we reduced testing in a similar way
e.g. only run the TCK on the latest released Fedora for each JDK.
I think reducing TCK runs would be an acceptable compromise. After all, that
is where the bottleneck lies.
Maybe you could also run the TCK asynchronously *after* the security update
went out (or while it is queued), and try to fix in a later update any
regressions that unexpectedly show up?
Kevin Kofler
5:10 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Mon, May 16, 2022 at 4:54 PM Andrew Hughes <gnu.andrew(a)redhat.com> wrote:
>
> Let me join the train of -1 votes. I consider this a step entirely in the
> wrong direction. The JDK should be linked to system libraries wherever
> possible just like our other packages. Language interpreters/JITs are not
> exempt from that. In fact, I see very little value in providing JDK packages
> at all if they are built that way.
>
I expect JDK users would disagree with you. JDKs from other vendors
(Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and
likely other GNU/Linux distributions) are the exception here.
I don't think this is a valid argument, because you're looking at
OpenJDK in isolation.
As far as I know, almost all compilers and runtimes we ship in Fedora
are built with a certain amount of downstream patches that make them
"slightly different" than what you might install in binary form from
"$foo-lang.org" (if only to make them usable to build other packages
that use them), so OpenJDK is not an exception here at all.
I would even argue that users are *aware* that the compilers /
runtimes that are provided by Linux distributions are at least
*slightly modified* (if only to cater to linux distribution use
cases), and will already fall back to "official" binaries, when
necessary.
If you really want to lower your maintenance burden for OpenJDK
packages, I'd start by not shipping four (or soon five?) different
versions of them.
For example, do we really still need java-1.8.0-openjdk? Or is it time
to retire the ancient Java packages that only still work on a Java
runtime that's almost a decade old?
Or, can even java-11-openjdk be dropped in the near future, since
java-17-openjdk is the default for Fedora 36 and future Fedora
releases?
And do we actually need the "java-latest-openjdk" version at all? If
anybody needs such an up-to-date Java compiler / runtime for their
development work, they'll surely already download an official binary
distribution.
Fabio
6:45 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/17/22 00:10, Fabio Valentini wrote:
On Mon, May 16, 2022 at 4:54 PM Andrew Hughes
<gnu.andrew(a)redhat.com> wrote:
>
>>
>> Let me join the train of -1 votes. I consider this a step entirely in the
>> wrong direction. The JDK should be linked to system libraries wherever
>> possible just like our other packages. Language interpreters/JITs are not
>> exempt from that. In fact, I see very little value in providing JDK packages
>> at all if they are built that way.
>>
>
> I expect JDK users would disagree with you. JDKs from other vendors
> (Amazon, Azul, Oracle, etc.) are built in exactly this way. We (and
> likely other GNU/Linux distributions) are the exception here.
I don't think this is a valid argument, because you're looking at
OpenJDK in isolation.
As far as I know, almost all compilers and runtimes we ship in Fedora
are built with a certain amount of downstream patches that make them
"slightly different" than what you might install in binary form from
"$foo-lang.org" (if only to make them usable to build other packages
that use them), so OpenJDK is not an exception here at all.
I would even argue that users are *aware* that the compilers /
runtimes that are provided by Linux distributions are at least
*slightly modified* (if only to cater to linux distribution use
cases), and will already fall back to "official" binaries, when
necessary.
If you really want to lower your maintenance burden for OpenJDK
packages, I'd start by not shipping four (or soon five?) different
versions of them.
For example, do we really still need java-1.8.0-openjdk? Or is it time
to retire the ancient Java packages that only still work on a Java
runtime that's almost a decade old?
Or, can even java-11-openjdk be dropped in the near future, since
java-17-openjdk is the default for Fedora 36 and future Fedora
releases?
And do we actually need the "java-latest-openjdk" version at all? If
anybody needs such an up-to-date Java compiler / runtime for their
development work, they'll surely already download an official binary
distribution.
Well yes. Taht is of course option to support only system jdk and be done with that.
We will need to continue t build - but never release- -latest- package, so we are able to
bootsrap next system jdk (21 or what)
Note one super huge bad side effect - the new system jdk will be totally untested,
including integration.
Thus saying, I woudl ratehr support 4 static different fully jdks tested, then 1 jdk build
4times, which is fully untested
Thanx!
J.
Fabio
_______________________________________________
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
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
2:51 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 10/05/2022 15:29, Ben Cotton wrote:
Make the normal rpms to not built jdk, but to repack the portable
rpms with all integration
No way. This violates Fedora policy. All packages **must** be built from
sources. No exceptions.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:03 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Tue, May 10, 2022 at 09:29:35AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This is initial step to move JDKs to be more like other JDKs, to build
proper transferable images, and to lower certification burden of each
binary. Long storyshort, first step in:
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
Reading this whole doc is really key, because it is clear that
(if approved) further changes are going to follow this one in
Fedora 38. So the decision on whether to approve this first
feature really needs to consider the acceptability of the overall
plan, not just this first step in isolation.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
for whole picture
Please see
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JD...
for this particular step. I would rather keep the details in the main
page then here.
== Feedback ==
According to short investigations, there are already precedents, where
certification is a reason to build once, certificate, and repack.
It would be useful to have more details about how the certification
is taking place for JDK in Fedora today, so we have a better understanding
of how it is impacting the maintainer currently. When is certification
currently done, what rules need to be followed, etc.
According to developers, the non-portbale JDK is causing upredicted
behavior different from other JDK vendors
IIUC, the Java certification is intended to identify any non-compliant
behaviour between JDK builds. Is this statement indicating that Fedora
builds are not passing the certification, or that we're introducing
regressions into JDK after the certification is done (eg through later
3rd party RPM updates), or is the breadth of JDK cert coverage simply
insufficient to detect enough problems upfront ?
According to JDK packagers and testers, there is to much JDKs now,
and
the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fe...
is the only way out
According to the doc we currently have jdk8, jdk11, jdk17 and jdk18,
across 3 Fedora releases (35, 36, 37-rawhde). So 12 build streams
effectively. IIUC, it is implied that when a new JDK comes out (jdk19
next), it would be added immediately to all Fedora streams (35, 36,
37rawhide).
If separate builds for done for each release, it sounds like it is
meaning JDK certification is needed for each release separate. So
a new jdk19 would need certifying separately for (35, 36, 37-rawhide)
One way to reduce this burden is to not introduce new JDKs to all
existing Fedora streams, only add it to rawhide so certification is
only needed once.
Having said that I'm still not clear on the real impact of the
certification. Presumably thue certification is not re-done in each
JDK RPM re-build, nor on every RPM re-build of a library it depends
on. If so, then do we really need to do certification for every
Fedora release stream when adding a new JDK. Can we do a build for
35, certify it, and then do what is effectively no-change import
and rebuild for 36/37-rawhide and just consider the 35-certification
to cover those streams.
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 :|
4:48 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 11/05/2022 11:03, Daniel P. Berrangé wrote:
It would be useful to have more details about how the certification
is taking place for JDK in Fedora today, so we have a better understanding
of how it is impacting the maintainer currently. When is certification
currently done, what rules need to be followed, etc.
Why do we need such certification? Fedora is a separate distribution,
not related to Oracle at all.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:37 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
Hi,
Daniel P. Berrangé <berrange(a)redhat.com> writes:
One way to reduce this burden is to not introduce new JDKs to all
existing Fedora streams, only add it to rawhide so certification is
only needed once.
Having said that I'm still not clear on the real impact of the
certification. Presumably thue certification is not re-done in each
JDK RPM re-build, nor on every RPM re-build of a library it depends
on. If so, then do we really need to do certification for every
Fedora release stream when adding a new JDK. Can we do a build for
35, certify it, and then do what is effectively no-change import
and rebuild for 36/37-rawhide and just consider the 35-certification
to cover those streams.
As I understand it, the certification (TCK) is only done on a binary
level, and only applies to the OpenJDK package itself. It's not a
one-time thing when a new version of the OpenJDK is added; it needs to
be re-done on every single rebuild and/or update of OpenJDK.
AFAIK, even if you rebuild the exact same sources with the exact same
toolchain with the exact same compiler flags, you still can't claim TCK
certification status from one build carries over to the next.
If we import a binary (RPM) from one Fedora version to the other, then
we can continue claiming that the original binary is still certified.
Please note that it has been more than 5 years since I was last involved
with Java, so things might have changed. I might also be mis-remembering
something. But hopefully that gives some context on why the
certification (TCK) burden is so huge.
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
9:55 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Wed, May 11, 2022 at 10:37:31AM -0400, Omair Majid wrote:
Hi,
Daniel P. Berrangé <berrange(a)redhat.com> writes:
> One way to reduce this burden is to not introduce new JDKs to all
> existing Fedora streams, only add it to rawhide so certification is
> only needed once.
>
> Having said that I'm still not clear on the real impact of the
> certification. Presumably thue certification is not re-done in each
> JDK RPM re-build, nor on every RPM re-build of a library it depends
> on. If so, then do we really need to do certification for every
> Fedora release stream when adding a new JDK. Can we do a build for
> 35, certify it, and then do what is effectively no-change import
> and rebuild for 36/37-rawhide and just consider the 35-certification
> to cover those streams.
As I understand it, the certification (TCK) is only done on a binary
level, and only applies to the OpenJDK package itself. It's not a
one-time thing when a new version of the OpenJDK is added; it needs to
be re-done on every single rebuild and/or update of OpenJDK.
AFAIK, even if you rebuild the exact same sources with the exact same
toolchain with the exact same compiler flags, you still can't claim TCK
certification status from one build carries over to the next.
With such a strict interpretation, then I would have thought that
any time a dependency got an update it would invalidate certification
too, even right down to any glibc update, or even kernel update ?
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 :|
10:20 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree
libraries and with static stdc++lib (System-Wide Change proposal)
* Daniel P. Berrangé:
On Wed, May 11, 2022 at 10:37:31AM -0400, Omair Majid wrote:
> AFAIK, even if you rebuild the exact same sources with the exact same
> toolchain with the exact same compiler flags, you still can't claim TCK
> certification status from one build carries over to the next.
With such a strict interpretation, then I would have thought that
any time a dependency got an update it would invalidate certification
too, even right down to any glibc update, or even kernel update ?
I think most TCK users do not control an entire operating system like
Fedora does.
Is there an actual contractual requirement for Fedora to distribute
OpenJDK builds only after they have passed the TCK? That's just
impossible with the Fedora build system, and we would have to remove
OpenJDK from Fedora to comply. Or maybe there is something we can do to
with the OpenJDK vendor strings to escape TCK testing requirements.
That would still be unfortunate because some Java software looks at
these strings and alters its behavior, so everyone loses because of the
reduced test coverage, but it's probably better than shipping no OpenJDK
at all.
If running the TCK is optional, then the TCK testing could be restricted
to a single Fedora release, plus testing of the RC of a new Fedora
release. Fedora couldn't claim TCK compliance, of course, but it does
not look like we currently do anyway:
<https://fedoraproject.org/wiki/Java>
<https://fedoraproject.org/w/index.php?title=Special%3ASearch&search=T...
“TCK” isn't mentioned on docs.fedoraproject.org, either.
Thanks,
Florian
9:33 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 17:20 Wed 11 May , Florian Weimer wrote:
* Daniel P. Berrangé:
> On Wed, May 11, 2022 at 10:37:31AM -0400, Omair Majid wrote:
>> AFAIK, even if you rebuild the exact same sources with the exact same
>> toolchain with the exact same compiler flags, you still can't claim TCK
>> certification status from one build carries over to the next.
>
> With such a strict interpretation, then I would have thought that
> any time a dependency got an update it would invalidate certification
> too, even right down to any glibc update, or even kernel update ?
I think most TCK users do not control an entire operating system like
Fedora does.
Is there an actual contractual requirement for Fedora to distribute
OpenJDK builds only after they have passed the TCK? That's just
impossible with the Fedora build system, and we would have to remove
OpenJDK from Fedora to comply. Or maybe there is something we can do to
with the OpenJDK vendor strings to escape TCK testing requirements.
That would still be unfortunate because some Java software looks at
these strings and alters its behavior, so everyone loses because of the
reduced test coverage, but it's probably better than shipping no OpenJDK
at all.
If running the TCK is optional, then the TCK testing could be restricted
to a single Fedora release, plus testing of the RC of a new Fedora
release. Fedora couldn't claim TCK compliance, of course, but it does
not look like we currently do anyway:
<https://fedoraproject.org/wiki/Java>
<https://fedoraproject.org/w/index.php?title=Special%3ASearch&search=T...
“TCK” isn't mentioned on docs.fedoraproject.org, either.
Thanks,
Florian
_______________________________________________
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
No, there is no contractual requirement as far as I'm aware. Access to
the TCK comes with certain provisions, but these are related to what
about it can be made public (basically, you can only say a binary has
passed, nothing more detailed)
The impetus is more from other providers of JDK binaries. Thanks to
its chequered history in FOSS distributions, there is a tendency for
end users to download a JDK from a vendor rather than using what is
available in their distribution. If those binaries have passed the
TCK, and the ones in Fedora have not, that is another reason for
someone to download an external JDK.
Over the decade and a half since OpenJDK started, there has been a lot
of effort from those in the Red Hat Java team and others to push
people back towards using a FOSS Java stack. Weakening our test regime
would be a reason for people to go back to using other binaries.
The aim of this set of proposals (which can only really be considered
as a whole) is to move to a situation where the JDK is built from
source once on Fedora and then that binary is tested and deployed on
multiple versions of Fedora, which sounds similar to what you propose
by only testing on the one release.
It's not something I'm completely keen on myself. We've spent a lot of
time over the years making it possible to use system dependencies (at
the start, this was all local patches). However, with the current
burden of JDKs and platforms on our team (which is only set to further
increase over time), we need to consider whether everything we are
doing is necessary and worthwhile.
Using system libraries means our JDKs also get their own unique bugs
as well as features. It's not a simple benefit as it may first appear.
I'm sure this is the case for other projects too. Likewise, with
security fixes; it may mean we pick up a security fix early via the
system library being updated, but it may also mean we are later than
other JDKs because we are waiting on system library updates as well.
These proposals do ask for exceptional treatment for the JDKs on
Fedora, but it's an attempt to move away from what is an exceptional
way of building the JDK that differs from other vendors and puts
the Fedora JDK at a disadvantage in many situations.
If there is significant opposition to this, I believe we would have to
look at reducing builds and testing on Fedora in other ways.
Thanks,
--
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
9:54 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 16/05/2022 16:33, Andrew Hughes wrote:
These proposals do ask for exceptional treatment for the JDKs on
Fedora, but it's an attempt to move away from what is an exceptional
way of building the JDK that differs from other vendors and puts
the Fedora JDK at a disadvantage in many situations.
If current maintainers can't continue maintaining the well-packaged
OpenJDK, I think it's time to retire it. It would be better not to have
OpenJDK on Fedora than to have statically linked blobs with ugly fonts
that make the user's eyes bleed.
Likewise, with
security fixes; it may mean we pick up a security fix early via the
system library being updated, but it may also mean we are later than
other JDKs because we are waiting on system library updates as well.
1. You can always send a PR to the system library package with CVE fix.
2. You do not need to rebuild OpenJDK after the system library update is
installed.
If there is significant opposition to this, I believe we would have
to
look at reducing builds and testing on Fedora in other ways.
You can focus on building only one major LTS version, but against system
libraries.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:42 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 10:37 Wed 11 May , Omair Majid wrote:
Hi,
Daniel P. Berrangé <berrange(a)redhat.com> writes:
> One way to reduce this burden is to not introduce new JDKs to all
> existing Fedora streams, only add it to rawhide so certification is
> only needed once.
>
> Having said that I'm still not clear on the real impact of the
> certification. Presumably thue certification is not re-done in each
> JDK RPM re-build, nor on every RPM re-build of a library it depends
> on. If so, then do we really need to do certification for every
> Fedora release stream when adding a new JDK. Can we do a build for
> 35, certify it, and then do what is effectively no-change import
> and rebuild for 36/37-rawhide and just consider the 35-certification
> to cover those streams.
As I understand it, the certification (TCK) is only done on a binary
level, and only applies to the OpenJDK package itself. It's not a
one-time thing when a new version of the OpenJDK is added; it needs to
be re-done on every single rebuild and/or update of OpenJDK.
AFAIK, even if you rebuild the exact same sources with the exact same
toolchain with the exact same compiler flags, you still can't claim TCK
certification status from one build carries over to the next.
I believe there are some minor exceptions, but this is mostly correct,
yes. Certainly, we'd usually prefer to re-certify than not.
If we import a binary (RPM) from one Fedora version to the other,
then
we can continue claiming that the original binary is still certified.
Please note that it has been more than 5 years since I was last involved
with Java, so things might have changed. I might also be mis-remembering
something. But hopefully that gives some context on why the
certification (TCK) burden is so huge.
Yes, I believe this is what other vendors do; each JDK build is tested
on a specific platform but users may use that build elsewhere. The
expectation is that someone else could reproduce the same result by
using the same build on the same platform. Vendors tend to use some
older OS release to increase the chance that it will still work
against the few libraries that are dynamically linked (e.g. the C
library). For example, Red Hat currently provides a "portable" JDK
that is built on RHEL 7.
The idea here is that we'd do something similar in Fedora; build on
the oldest supported release, but provide that version on all
supported releases.
That should at least halve the testing burden, which is currently
three JDKs on two or three versions of Fedora.
Omair
--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0
_______________________________________________
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
--
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
10:04 a.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Once upon a time, Andrew Hughes <gnu.andrew(a)redhat.com> said:
The idea here is that we'd do something similar in Fedora; build
on
the oldest supported release, but provide that version on all
supported releases.
That would also mean that the JDKs would lag any other Fedora
system-wide changes, such as compiler/library updates, build options
that affect security, etc. I think that's a bad idea.
How would this actually be implemented at new release time? For
example, let's say F34, F35, and rawhide were all getting a JDK built on
F34. When F36 comes out (and then later F34 is EOLed)... how would that
work? F35, F36, and rawhide need to be updated to a JDK built on F35...
which would mean that F36 gets released with an immediately obsolete
JDK, to be replaced with an untested (in the general sense, didn't go
through OS beta and such) build.
Or would rawhide get a build built on (oldest+1) rather than (oldest)?
So F36 would be tested and released with a build built on (but not
released for) F35, until F34 goes EOL and F35 gets updated?
This would seem to be a very confusing way of doing things.
--
Chris Adams <linux(a)cmadams.net>
7:26 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On 5/10/22 06:29, Ben Cotton wrote:
According to developers, the non-portbale JDK is causing upredicted
behavior different from other JDK vendors
Similar to what Kevin has mentioned, I've also been using the Fedora
openjdk builds for work for many years with no issues in a very large
project.
I have tried searching around and I can't find what this certification
requirement is. openjdk only says that you have to mostly using their
sources. The Java trademark requirement is harder to find and I only
found some old mentions. Do you have a reference?
Do you really need to test every build before it's released? I can't
imagine that every little change needs a full test run. Can you instead
run tests as time is available? I don't even really see that we're
calling it "Java" as opposed to just openjdk and I haven't seen the Java
logo anywhere.
8 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
On Mon, May 16, 2022 at 8:27 PM Samuel Sieb <samuel(a)sieb.net> wrote:
On 5/10/22 06:29, Ben Cotton wrote:
> According to developers, the non-portbale JDK is causing upredicted
> behavior different from other JDK vendors
Similar to what Kevin has mentioned, I've also been using the Fedora
openjdk builds for work for many years with no issues in a very large
project.
I have tried searching around and I can't find what this certification
requirement is. openjdk only says that you have to mostly using their
sources. The Java trademark requirement is harder to find and I only
found some old mentions. Do you have a reference?
Do you really need to test every build before it's released? I can't
imagine that every little change needs a full test run. Can you instead
run tests as time is available? I don't even really see that we're
calling it "Java" as opposed to just openjdk and I haven't seen the Java
logo anywhere.
I'm pretty sure we don't even include the Java logo for historical
reasons. Our OpenJDK originates from the IcedTea project[1], and while
most of that project is gone now, one consequence of that is that our
Java runtime has always been considered fully functional without the
Java TCK approval and we have been used to not using 100% code from
Sun/Oracle even after we finally got the TCK to run it against.
That said, I'm concerned that validating against the Java TCK is
considered so burdensome that this proposal is even being seriously
bandied about. Has there been any upstream discussions about this?
[1]:
https://web.archive.org/web/20080716054009/http://fedoraproject.org/wiki/...
(As an aside, apparently this page was lost at some point in the past
few years, our wiki doesn't have this page)
--
真実はいつも一つ！/ Always, there's only one truth!
2:20 p.m.
New subject: F37 proposal: Build all JDKs in Fedora against in-tree libraries
and with static stdc++lib (System-Wide Change proposal)
Hi,
Il giorno 10 mag 2022, alle ore 15:29, Ben Cotton
<bcotton(a)redhat.com> ha scritto:
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This is initial step to move JDKs to be more like other JDKs, to build
proper transferable images, and to lower certification burden of each
binary. Long storyshort, first step in:
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
This first step will move, one by one, individual JDKs in F37 to be
built `--with-stdc++lib=static` and against in-tree (bundeld)
libraries: `--with-zlib="bundled" --with-freetype="bundled"
--with-libjpeg="bundled" --with-giflib="bundled"
--withlibpng="bundled" --with-lcms="bundled"
--with-harfbuzz="bundled" `
-1 here, we should avoid bundled libraries
We already made a heavy testing of the behavior, and user should not
face negative experience. I'm not sure if this is
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: jvanek(a)redhat.com
== Detailed Description ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
for whole picture
Please see
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JD...
for this particular step. I would rather keep the details in the main
page then here.
== Feedback ==
According to short investigations, there are already precedents, where
certification is a reason to build once, certificate, and repack.
According to developers, the non-portbale JDK is causing upredicted
behavior different from other JDK vendors
According to JDK packagers and testers, there is to much JDKs now, and
the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fe...
is the only way out
== Benefit to Fedora ==
Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation
for whole picture.
This particular proposal's main benefit will be that Fedora's JDKs as
packed in RPMs will again start to resemble upstream JDKs and other
vendors build, and some platform specific issues disappear, while JDKs
remain same in view of system integration and user experience
== Scope ==
* Proposal owners: push improved version of
https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#re...
to all JDKs - one by one from latest, over 17 to 11 and 8. Once
settled down in F37 the backport to F36 is expected.
* Other developers: really, nothing. If there will be unexpected
impact to other developers, the
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may
need rework
* Release engineering: N/A [https://pagure.io/releng/issues #Releng
issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The compatibility and upgrade path should remain completely smooth.
== How To Test ==
Install system JDK (java-17-openjdk) and ru your favorite application
or development. No regression should be noted.
== User Experience ==
Because of in-tree libraries, minimal image or font rendering
differences canbe spotted after very detailed investigations -
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_ef...
- still, no of th e
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_i...
should be hit by this proposal.
== Dependencies ==
No dependent packages should notice the change.
== Contingency Plan ==
* Contingency mechanism: Revert the patches and rework
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
* Contingency deadline: before f37 release
* Blocks release? Unless the java-stack will become completely borked then no.
== Documentation ==
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
I don’t agree with this proposal, a big -1 for this
FAS: tartina
Ciao
696
days inactive
715
days old
171 comments
35 participants
participants (35)
-
Alexander Sosedkin -
Andrew Hughes -
Ben Cotton -
Chris Adams -
Daniel P. Berrangé -
Demi Marie Obenour -
Dominik 'Rathann' Mierzejewski -
drago01 -
Fabio Valentini -
Felix Schwarz -
Florian Weimer -
Gerald Henriksen -
Guido Aulisi -
Ian Pilcher -
jiri vanek -
Jiri Vanek
-
Kevin Fenzi -
Kevin Kofler -
Kevin P. Fleming -
Mario Torre -
Michael Catanzaro -
Neal Gompa -
Nico Kadel-Garcia -
Omair Majid -
Paul Howarth -
Peter Boy -
Petr Pisar -
Robert Relyea -
Samuel Sieb -
Simon Farnsworth -
Solomon Peachy -
Stephen Smoogen -
Stephen Snow -
Tomasz Torcz -
Vitaly Zaitsev