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:
> 
>   
>   
> 
> “TCK” isn't mentioned on docs.fedoraproject.org, either.
> 
> Thanks,
> Florian
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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

signature.asc
Description: PGP signature
___
devel

Re: 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é  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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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: jva...@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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Chris Adams

Once upon a time, Andrew Hughes  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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Kevin Kofler via devel

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Jiri Vanek


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 sh

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Demi Marie Obenour

>  > 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)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Fabio Valentini

On Mon, May 16, 2022 at 4:54 PM Andrew Hughes  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Kevin Kofler via devel

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, wh

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Neal Gompa

On Mon, May 16, 2022 at 6:55 PM Kevin Kofler via devel
 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Samuel Sieb


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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Neal Gompa

On Mon, May 16, 2022 at 8:27 PM Samuel Sieb  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/Features/IcedTea

(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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-16 Thread Neal Gompa

On Mon, May 16, 2022 at 9:54 PM Andrew Hughes  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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Vitaly Zaitsev via devel

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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Stephen Smoogen

On Mon, 16 May 2022 at 23:18, Neal Gompa  wrote:

> On Mon, May 16, 2022 at 9:54 PM Andrew Hughes 
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Stephen Smoogen

On Tue, 17 May 2022 at 08:11, Vitaly Zaitsev via devel <
devel@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Demi Marie Obenour

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)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Neal Gompa

On Tue, May 17, 2022 at 8:33 AM Stephen Smoogen  wrote:
>
>
>
> On Mon, 16 May 2022 at 23:18, Neal Gompa  wrote:
>>
>> On Mon, May 16, 2022 at 9:54 PM Andrew Hughes  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 update

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Demi Marie Obenour

On 5/17/22 08:33, Stephen Smoogen wrote:
> On Mon, 16 May 2022 at 23:18, Neal Gompa  wrote:
> 
>> On Mon, May 16, 2022 at 9:54 PM Andrew Hughes 
>> 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 seei

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Tomasz Torcz

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.”
to...@pipebreaker.pl  — Mitchell Blank on LKML
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Vitaly Zaitsev via devel


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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Daniel P . Berrangé

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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Alexander Sosedkin

On Tue, May 17, 2022 at 5:09 PM Daniel P. Berrangé  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Neal Gompa

On Tue, May 17, 2022 at 11:09 AM Daniel P. Berrangé  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Chris Adams

Once upon a time, Daniel P. Berrangé  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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-17 Thread Daniel P . Berrangé

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
> toolchainDetecting 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_GCC
> 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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Peter Boy



> Am 17.05.2022 um 05:08 schrieb Neal Gompa :
> 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
p...@fedoraproject.org
CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Peter Boy



> Am 17.05.2022 um 15:02 schrieb Neal Gompa :
> 
> On Tue, May 17, 2022 at 8:33 AM Stephen Smoogen  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
p...@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Fabio Valentini

On Wed, May 18, 2022 at 12:28 PM jiri vanek  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Dominik 'Rathann' Mierzejewski

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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,

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Stephen Snow

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 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Chris Adams

Once upon a time, Stephen Snow  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 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Felix Schwarz




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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Petr Pisar

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Stephen Snow

On Wed, 2022-05-18 at 07:27 -0500, Chris Adams wrote:
> Once upon a time, Stephen Snow  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 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Stephen Snow

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@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Mario Torre

On Tue, May 10, 2022 at 11:52 PM Neal Gompa  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  wrote:
>
> On Tue, May 10, 2022 at 11:52 PM Neal Gompa  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Omair Majid

Hi,

Neal Gompa  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Omair Majid

Hi,

"jiri vanek"  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Stephen Smoogen

On Wed, 18 May 2022 at 10:41, Vitaly Zaitsev via devel <
devel@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 (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Peter Boy

> Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel 
> :
> 
> 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
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  wrote:
>
>
>
> > Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel 
> > :
> >
> > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Fabio Valentini

On Wed, May 18, 2022 at 6:04 PM Neal Gompa  wrote:
>
> On Wed, May 18, 2022 at 11:55 AM jiri vanek  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  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Simon Farnsworth via devel

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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Michael Catanzaro

On Wed, May 18 2022 at 12:01:33 PM -0400, Neal Gompa 
 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Demi Marie Obenour

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)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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 (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-18 Thread Kevin Kofler via devel

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

2022-05-19 Thread Demi Marie Obenour

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)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  wrote:





Am 18.05.2022 um 16:36 schrieb Vitaly Zaitsev via devel 
:

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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






--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: 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  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)