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


On 27/05/2022 15:30, Peter Boy wrote:

Really sorry, but such a statement is simply intellectual bullshit. 
Unfortunately, it is not possible to formulate this in a more friendly yet 
unambiguous way. And in this thread in particular, the many allegations, 
unclouded by any expertise but made all the more decisively, are simply 
annoying - and a huge waste of everyone’s time in the long run.


But it's true.

One of my packages had a bundled library with 6 critical vulnerabilities 
(outdated for 5 years). The upstream developers said they didn't care 
because they needed their app to run under Ubuntu 12.04 LTS. Fixed it 
manually by switching to the packaged version.


Another package had bundled OpenSSL, which was 3 years out of date.

--
Sincerely,
  Vitaly Zaitsev (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-27 Thread Peter Boy



> Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel 
> :
> 
> Bundled libraries are always outdated and even vulnerable. 

Really sorry, but such a statement is simply intellectual bullshit. 
Unfortunately, it is not possible to formulate this in a more friendly yet 
unambiguous way. And in this thread in particular, the many allegations, 
unclouded by any expertise but made all the more decisively, are simply 
annoying - and a huge waste of everyone’s time in the long run. 

With technically correct workflow, there is at least a time x where the 
included libs are not outdated and where vulnerability is unknown at worst. How 
someone comes up with "always" is beyond me.

And whether to include a lib in a package is a tradeoff between various pros 
and cons. Depending on the circumstances, the result is different. 

The Change proposal correctly includes several reasons for consideration. And 
no viable argument has yet been put forward as to why the consideration given 
is *necessarily* incorrect. 

Several conceivable alternatives would also be viable. But as long as no one is 
directly affected in a negative way and no one comes forward to do the work 
involved with an alternative,  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
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)

2022-05-27 Thread Peter Boy



> Am 27.05.2022 um 14:00 schrieb Vitaly Zaitsev via devel 
> :
> 
> Bundled libraries are always outdated and even vulnerable. 

Really sorry, but such a statement is simply intellectual bullshit. 
Unfortunately, it is not possible to formulate this in a more friendly yet 
unambiguous way. And in this thread in particular, the many allegations, 
unclouded by any expertise but made all the more decisively, are simply 
annoying - and a huge waste of everyone’s time in the long run. 

With technically correct workflow, there is at least a time x where the 
included libs are not outdated and where vulnerability is unknown at worst. How 
someone comes up with "always" is beyond me.

And whether to include a lib in a package is a tradeoff between various pros 
and cons. Depending on the circumstances, the result is different. 

The Change proposal correctly includes several reasons for consideration. And 
no viable argument has yet been put forward as to why the consideration given 
is *necessarily* incorrect. 

Several conceivable alternatives would also be viable. But as long as no one is 
directly affected in a negative way and no one comes forward to do the work 
involved with an alternative,  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
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 26/05/2022 20:29, Stephen Snow wrote:

Libraries are bundled into jars not the source, etc... this all
snowballs across what 4 version now supported?


OpenJDK is a native ELF binary, not a JAR.

--
Sincerely,
  Vitaly Zaitsev (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 26/05/2022 19:31, drago01 wrote:
But bundled libs and properly tested / certified vs dynamic linking and 
less testing / no certification.


Bundled libraries are always outdated and even vulnerable. We should 
avoid bundling as much as possible.


--
Sincerely,
  Vitaly Zaitsev (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 26/05/2022 17:40, drago01 wrote:
Why would we do that? Is the build process really more important than 
shipping tested software?


Yes.

--
Sincerely,
  Vitaly Zaitsev (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-27 Thread Jiri Vanek




On 5/26/22 14:17, Stephen Snow wrote:

Also, it may be good to take a look at what AdoptOpenJDK is doing with
the Eclipse Foundation based Adoptium Project, specifically the Eclipse
Temurin subproject
https://projects.eclipse.org/proposals/eclipse-temurin-compliance which
is going to handle the compliance requirements.

In this scenerio the Eclipse Foundation is the license holder and the
Adoptium project submits to the Temurin project to get certified.

Maybe Fedora could use something similar with RH, who are signatories
on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project.

Just another thought on it.


That is just correct summary. That is exactly what wea re doing.
We certify with RH signatories.

J.
___
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-26 Thread Ian Pilcher


On 5/26/22 12:31, drago01 wrote:
I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled 
libs and properly tested / certified vs dynamic linking and less testing 
/ no certification.


But if OpenJDK-based binaries can't be distributed without passing the
TCK, then it isn't really FLOSS.

--

Google  Where SkyNet meets Idiocracy

___
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 Thu, 2022-05-26 at 14:07 -0400, Solomon Peachy wrote:
> On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote:
> > I am not talking about FLOSS vs non FLOSS, that's obvious. But
> > bundled libs
> > and properly tested / certified vs dynamic linking and less testing
> > / no
> > certification.
> 
> I've been following this circular thread from the outset (And I do
> make 
> use of Fedora's JDK packages), but one thing I don't recall seeing is
> a 
> specific (or even general) example of the sort of failures/problems
> that 
> have come from linking against system libraries vs just using the 
> bundled ones.
> 
> Relatedly, I think it would also be very valuable to know if these 
> problems are mostly one-off (eg a major release of the jdk or
> dependent 
> library lands in rawhide and breakage ensues), or occur throughout a 
> specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a
> critical 
> security update which leads to a failure to pass TCK, or quarterly 
> java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to
> fedora's 
> bundled library libfoo version)
> 
I don't think that was the gist of it. I believe that it relates to the
numbers of OpenJDK we carry, and the difficulty faced by the packagers
of that to comply with packaging in Fedora's ecosystem when doing it.
Libraries are bundled into jars not the source, etc... this all
snowballs across what 4 version now supported? I don't remeber reading
about unspecified TCK failures, just the workload as a result of our
packaging requirements.

> I mean, it's been strongly implied (if not outright stated) that 
> resolving these unspecified TCK failures, caused by using non-bundled
> libraries, is the real burden, not the act of running the TCK for
> each 
> build -- but is the TCK (or upstream JDK) really that _brittle_?
> 
I built Netbeans for F36 Silverblue and when building it from source,
it still uses maven repo to download binary tools (maven plugin's) to
build with, this would be in violation of the packaging guidelines I
think. So to package it I would need to also package all of those
plugin's along side to support it in the Fedora Project ecosystem, just
for the actual build process.

Regards,
Stephen Snow
>  - Solomon
> ___
> devel mailing list -- devel@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)

So my take on the TCK is that Red Hat signed the OCTLA and Fedora
Community get's to test their OpenJDK against it as a subequence. I
didn't think Fedora the project, had any legal except what Red Hat
provides, maybe I'm mistaken though so someone should clarify if they
know for sure. Not only that, if we (Fedora Project) were the
signatories, we would need auditing internally and externally to comply
with requirements of the OCTLA from what I understand, which I imagine
we do not have, nor want to entertain since it would require
significant dedicated support likely. Basically anytime you use the TCK
you need the paper trail.

I still think the original proposal has some merrit at least of raisng
the point of the workload required to maintain Fedora Lunix's java
development stack. A rethink here would be good overall and really the
technical build issues Jiri Vanik presented need to be overcome and
should be the projects focus, not legal. Perhaps Fedora Project lead
could discuss this with RH legal to get their perspective. I'm sure
they're aware of the arrangement as it has been used by Fedora, and
Fedora is not listed as signatory, and someone had to sign the
agreement to get the TCK in the first place.

>From that POV, to me as OpenJDK is still GPL3 released, and Fedora
Project get's to use Red Hat's TCK to verify certification of
compliance, so win win. Red Hat needs it for their own OpenJDK, which
we no doubt have some involvement with, so again win win.

Regards,
Stephen Snow
On Thu, 2022-05-26 at 11:38 -0400, Stephen Smoogen wrote:
> 
> 
> On Thu, 26 May 2022 at 11:32, Kevin P. Fleming 
> wrote:
> > On 5/26/22 11:06, Stephen Smoogen wrote:
> > > 2. Are there ways that a non-TCK compliant version could be
> > distributed?
> > 
> > I would suggest phrasing that slightly differently: the version
> > being 
> > distributed could very well be fully compliant (would pass the TCK
> > if 
> > tested), but may not have been tested.
> > 
> > 
> 
> 
> Yes, that goes into the my misunderstanding of what TCK is. Some
> systems can only say they are 'compliant' if they are 'certified' and
> anything else is 'fraudulent'. Others allow for 'complaint' and
> 'certified' to be different.
> 
> In either case, I should have clarified with  'certified'.
>  
> > -- 
> > Kevin P. Fleming
> > He/Him/His
> > Principal Program Manager, RHEL
> > Red Hat US/Eastern Time Zone
> > ___
> > devel mailing list -- devel@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

___
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-26 Thread Solomon Peachy

On Thu, May 26, 2022 at 07:31:45PM +0200, drago01 wrote:
> I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled libs
> and properly tested / certified vs dynamic linking and less testing / no
> certification.

I've been following this circular thread from the outset (And I do make 
use of Fedora's JDK packages), but one thing I don't recall seeing is a 
specific (or even general) example of the sort of failures/problems that 
have come from linking against system libraries vs just using the 
bundled ones.

Relatedly, I think it would also be very valuable to know if these 
problems are mostly one-off (eg a major release of the jdk or dependent 
library lands in rawhide and breakage ensues), or occur throughout a 
specific release cycle (eg F35 gets libfoo 1.2.1 -> 1.2.2 for a critical 
security update which leads to a failure to pass TCK, or quarterly 
java-1.8.x -> 1.8.y update cycle leads to a TCK failure due to fedora's 
bundled library libfoo version)

I mean, it's been strongly implied (if not outright stated) that 
resolving these unspecified TCK failures, caused by using non-bundled 
libraries, is the real burden, not the act of running the TCK for each 
build -- but is the TCK (or upstream JDK) really that _brittle_?

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (libra.chat)

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-26 Thread drago01

On Thursday, May 26, 2022, Ian Pilcher  wrote:

> On 5/26/22 10:40, drago01 wrote:
>
>> Why would we do that? Is the build process really more important than
>> shipping tested software?
>>
>
> For Fedora?  Yes.
>
> Fedora includes lots of untested (in the formal, TCK sense) software.
> It does not include non-FLOSS software (except maybe in very specific
> circumstances such as firmware).


I am not talking about FLOSS vs non FLOSS, that's obvious. But bundled libs
and properly tested / certified vs dynamic linking and less testing / no
certification.


>
> --
> 
> Google  Where SkyNet meets Idiocracy
> 
> ___
> devel mailing list -- devel@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.or
> g/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-26 Thread Ian Pilcher


On 5/26/22 10:40, drago01 wrote:
Why would we do that? Is the build process really more important than 
shipping tested software?


For Fedora?  Yes.

Fedora includes lots of untested (in the formal, TCK sense) software.
It does not include non-FLOSS software (except maybe in very specific
circumstances such as firmware).

--

Google  Where SkyNet meets Idiocracy

___
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-26 Thread drago01

On Thursday, May 26, 2022, Kevin P. Fleming  wrote:

> On 5/26/22 11:06, Stephen Smoogen wrote:
>
>> 2. Are there ways that a non-TCK compliant version could be distributed?
>>
>
> I would suggest phrasing that slightly differently: the version being
> distributed could very well be fully compliant (would pass the TCK if
> tested), but may not have been tested.
>
>
Why would we do that? Is the build process really more important than
shipping tested software?


> --
> Kevin P. Fleming
> He/Him/His
> Principal Program Manager, RHEL
> Red Hat US/Eastern Time Zone
> ___
> devel mailing list -- devel@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.or
> g/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-26 Thread Stephen Smoogen

On Thu, 26 May 2022 at 11:32, Kevin P. Fleming  wrote:

> On 5/26/22 11:06, Stephen Smoogen wrote:
> > 2. Are there ways that a non-TCK compliant version could be distributed?
>
> I would suggest phrasing that slightly differently: the version being
> distributed could very well be fully compliant (would pass the TCK if
> tested), but may not have been tested.
>
>
Yes, that goes into the my misunderstanding of what TCK is. Some systems
can only say they are 'compliant' if they are 'certified' and anything else
is 'fraudulent'. Others allow for 'complaint' and 'certified' to be
different.

In either case, I should have clarified with  'certified'.


> --
> Kevin P. Fleming
> He/Him/His
> Principal Program Manager, RHEL
> Red Hat US/Eastern Time Zone
> ___
> devel mailing list -- devel@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)

2022-05-26 Thread Kevin P. Fleming


On 5/26/22 11:06, Stephen Smoogen wrote:

2. Are there ways that a non-TCK compliant version could be distributed?


I would suggest phrasing that slightly differently: the version being 
distributed could very well be fully compliant (would pass the TCK if 
tested), but may not have been tested.


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
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-26 Thread Stephen Smoogen

On Thu, 26 May 2022 at 08:19, Stephen Snow  wrote:

>
>
> On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote:
> > On 26/05/2022 00:02, Demi Marie Obenour wrote:
> > > IANAL, but I believe APIs are not eligible for
> > > trademark protection, so Fedora would only need to change the stuff
> > > that is*not*  part of the API.
> >
> > Yes. Google won a lawsuit against Oracle in the Supreme Court.
> >
> What law suit, and how does it apply to our situation?
>
>
The only lawsuit I know of is
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_Inc. where
while Google 'won' parts, many issues have been remanded back to a lower
court and are still outstanding. [This means that they could still be
interpreted as a win for Oracle on narrower bands.] It is unclear enough
that various groups have had different interpretations. That said there are
several trademark lawsuits on the usage of 'coffee-themed-languages' which
have been posted in the past by Oracle ranging from Starbucks to various
smaller software companies. Trademark and copyright sound like they are the
same thing but they are different parts of the law and can 'override' one
another in different ways.

In any case, I think this needs an official review by the Fedora Council:
0. Are the outside requirements on how 'coffee-themed languages' must be
published making them non-Free/Open in the way Fedora Project expects
things to be?
1. What are the legal concerns that the Fedora Project must do to
distribute OpenJDK?
2. Are there ways that a non-TCK compliant version could be distributed?
3. Clearer guidance to the volunteers on how to deal with these
requirements.

These are deeper issues which I think need to be dealt with before we can
even think about the F37 change proposal.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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)

Also, it may be good to take a look at what AdoptOpenJDK is doing with
the Eclipse Foundation based Adoptium Project, specifically the Eclipse
Temurin subproject
https://projects.eclipse.org/proposals/eclipse-temurin-compliance which
is going to handle the compliance requirements.

In this scenerio the Eclipse Foundation is the license holder and the
Adoptium project submits to the Temurin project to get certified.

Maybe Fedora could use something similar with RH, who are signatories
on the OCTLA/TCK as well as supporters of the Eclipse Asoptium project.

Just another thought on it.


On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote:
> On 26/05/2022 00:02, Demi Marie Obenour wrote:
> > IANAL, but I believe APIs are not eligible for
> > trademark protection, so Fedora would only need to change the stuff
> > that is*not*  part of the API.
> 
> Yes. Google won a lawsuit against Oracle in the Supreme Court.
> 
What law suit, and how does it apply to our situation?

Regards,
Stephen Snow
> -- 
> Sincerely,
>    Vitaly Zaitsev (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
___
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)

There sure seems to be confusion here around what exactly the TCK or
JCK actually is. First off it is not a license. It is however a
technical compatability certification which guarantees technical
compatability between the different flavours of OpenJDK available out
there, like RedHats
(https://www.redhat.com/en/resources/build-of-openjdk-datasheet)
Who signed the agreement (OTCLA) to get the TCK/JCK obviously
The license aspect is found at
https://openjdk.java.net/legal/OCTLA-JDK9+.pdf and is the agreement you
sign to get access to the certification toolkit.

Yes, everyone who distributes a version of OpenJDK does this, and I
would think outside of hobby or education purposes, if you develop in
Java you want this too.

Regards,
Stephen Snow
On Thu, 2022-05-26 at 12:55 +0200, Vitaly Zaitsev via devel wrote:
> On 26/05/2022 00:02, Demi Marie Obenour wrote:
> > IANAL, but I believe APIs are not eligible for
> > trademark protection, so Fedora would only need to change the stuff
> > that is*not*  part of the API.
> 
> Yes. Google won a lawsuit against Oracle in the Supreme Court.
> 
> -- 
> Sincerely,
>    Vitaly Zaitsev (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
___
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-26 Thread Vitaly Zaitsev via devel


On 26/05/2022 00:02, Demi Marie Obenour wrote:

IANAL, but I believe APIs are not eligible for
trademark protection, so Fedora would only need to change the stuff
that is*not*  part of the API.


Yes. Google won a lawsuit against Oracle in the Supreme Court.

--
Sincerely,
  Vitaly Zaitsev (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-25 Thread Demi Marie Obenour

On 5/25/22 13:49, Jiri Vanek wrote:
> The rename will really not help.

If it is not possible to ship an uncertified version then OpenJDK is
not free software and Fedora should not have it at all, in which
case the whole discussion is moot.  Otherwise, it is possible
to ship a compatible version without the trademarks and without
TCK certification.  IANAL, but I believe APIs are not eligible for
trademark protection, so Fedora would only need to change the stuff
that is *not* part of the API.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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)


The rename will really not help.

On 5/25/22 18:01, Vitaly Zaitsev via devel wrote:

On 25/05/2022 15:03, Jiri Vanek wrote:

We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear.


Let's rename it to icedtea then.



--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
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-25 Thread Vitaly Zaitsev via devel


On 25/05/2022 15:34, Jiri Vanek wrote:
When we were shipping icedtea6 and later icedtea7, it still required 
TCK, so iced tea is not an option.


Easy fix: java-XX-openjdk -> coffee-named-language-XX.

--
Sincerely,
  Vitaly Zaitsev (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-25 Thread Vitaly Zaitsev via devel


On 25/05/2022 15:03, Jiri Vanek wrote:
We can not ship uncerified JDK. Sooner or later a swarm of lawyers would 
appear.


Let's rename it to icedtea then.

--
Sincerely,
  Vitaly Zaitsev (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)

BTW, I noticed that despite java-17-openjdk being the default system
JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when
I upgraded from Fedora 35. That sounds like the change proposal
wasn't

That sounds like super severe bug. I had tried it manytimes, in testing
environemtn with various basic pre-update setups when I was finishing the
change, and was ok.
When I updated my three personal machnes to f36 al was ok. But I''m afraid here
jdk8, jdk11 and jdk17 and jdk18.

fully implemented, either?

Wouldn't the upgrade approach leave the installed JDK as default? Just
asking since I have the default installed on F36 (17) and I also have
the latest(18) which I didn't explicitly install. Just asking

If we consider the unlikely super basic usecase, wehn you had only jdk17 in
f35, then the upgrade to f36 should add jdk 17. So btoh jdk11 and 17 will be
there, and jdk17 will become selected.

If you have lets say 8 and 11, and you *manually* select 8, then after update there will be 8,11 and 17, and 8 will remain selected. Alternatives honor your selction. The system jdk wil not be affeted byt maual selection of jdk -
https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting

J.
___
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-25 Thread Stephen Snow

On Wed, 2022-05-25 at 15:40 +0200, Fabio Valentini wrote:
> On Wed, May 25, 2022 at 3:17 PM Jiri Vanek  wrote:
> > 
> > On 5/24/22 22:02, Fabio Valentini wrote:
> > > Is this based on user requests, or is this only what you *think*
> > > users
> > 
> > I'm not sure what you mean  - from above - what is based on
> > mine/wider thinking
> > Generally waht I wrote here it is based on judgmeent of about 10
> > people around OpenJDK pacages in Fedora.
> > The equations above are based on realistic view and experience. Do
> > you yo find some misscalcualtion above?
> > 
> > I really appreciate you opinions, and would be happyt answer more
> > precisely.
> 
> Thank you for your response, I appreciate that you're engaging with
> feedback here.
> 
> The way I understood your last message, it seemed to me that you were
> claiming that actual Fedora users are requesting that you ship so
> many
> different OpenJDK versions.
> However, in this thread, I see the opposite - almost everybody is
> asking you to consider dropping support for at least some non-default
> OpenJDK versions, and nobody is advocating for keeping all of them.
> So
> my question was whether you have actual user feedback requesting that
> so many different versions are available on Fedora.
> 
> > > of OpenJDK on Fedora need?
> > > Speaking for myself, I have never used anything other than the
> > > default
> > > "system JDK" for running Java applications on Fedora.
> > 
> > Are  you really sure? Many applications runtime requiter non system
> > jdk, so they pull it in and use, and maybe you have not even
> > noticed.
> > Many develoeprs ahve installe dmany JDKS (in my case all from
> > repos, unless I need to compile jimage) and the switch as needed.
> 
> I'm quite sure, though I'm not using as many Java applications as I
> used to.
> The Minecraft "Java Edition" has always worked fine with the "system
> /
> default JDK", so I never needed to install another one.
> And the JetBrains IDEs have bundled their own JDK for a while now, I
> think, so I don't have to deal with those, either (and I wouldn't
> even
> want to mess with my main development environment to make it use
> something other than the JDK it ships with).
> 
> > > 
> > > What would you think about the following scenario:
> > > 
> > > - Fedora X defaults to new OpenJDK LTS N
> > > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the
> > > change
> > > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was
> > > already
> > > the default for one release
> > > - do not backport OpenJDK n to Fedora X-1 and X-2
> > > - keep java-latest-openjdk, as you seen to need this for
> > > bootstrapping
> > > new OpenJDK releases
> > 
> > This is possible solution. It will lower the TCK burden to aprox
> > 3/5 with lost of most widely used JDKs from repositories.
> > I'm open to this proposal. But the removal will hurt and way back
> > will be much harder then swithing static builds back to dynamic.
> > > 
> > > You could even drop java-latest-openjdk from all branches but
> > > rawhide,
> > > since it's only needed for bootstrapping there.
> > 
> > Taht is very valid point. Cost is it will force huge number of
> > uses  to download 3rd party latest STS jdk. it is where all new
> > features live.
> 
> Are there really that many Fedora users who need and install
> java-latest-openjdk? Do you have estimates of how many people do
> this,
> compared to how many users just use the default system JDK?
> 
> > > This should pretty dramatically reduce the size of your test
> > > matrix.
> > > Applying the current numbers:
> > > 
> > > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> > > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case
> > > the
> > > default needs to be switched back), java-latest-openjdk
> > > - Fedora 35: java-11-openjdk, java-latest-openjdk
> > > 
> > 
> > it is a bit less then I wrote, - about 3/5 of current load but do
> > yoreally wish to cut all those jdks from fedora?
> > To me the static repacked build sill somehow seems as smaller evil
> > then drop practically all interesting jdks out of distro.
> 
> Yeah, why not? I'm asking whether it's actually worth your time to
> keep them around. Given that there's probably limited userbase and
> the
> resources that are needed to keep them around, this is a valid
> question, I think. Speaking for myself, I'd rather have the default,
> integrated, system JDK be of the high quality it has been in Fedora,
> rather than having many different, less-integrated versions around.
> 
> > So here I need to rephrase your question - is it based on your's
> > thinking  or on what fedora users really needs?
> > I think the oposite - they need all jdks which are around. Proeprly
> > integrated with system. How they are built .. they do not care.
> > If update to neewer Fedora wil lmake some older JDK disapear, or if
> > need of new one will force me to update Fedora when I don't want or
> > cant. I call it

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

2022-05-25 Thread Stephen Smoogen

On Wed, 25 May 2022 at 09:34, Jiri Vanek  wrote:

>
>
> On 5/25/22 15:19, Stephen Smoogen wrote:
> >
> >
> > On Wed, 25 May 2022 at 09:04, Jiri Vanek  jva...@redhat.com>> wrote:
> >
> >
> >
> > On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> >  > On 24/05/2022 21:00, Jiri Vanek wrote:
> >  >> I repeat what was told several times.We really do no t like this
> change, especially in its full sound of one static build repacked to all
> ive fedoras, but we have nto found a better way.
> >  >
> >  > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't
> need certified binaries.
> > We can not ship uncerified JDK. Sooner or later a swarm of lawyers
> would appear.
> >
> >
> > So could it be shipped instead as a icedtea?
>
> When we were shipping icedtea6 and later icedtea7, it still required TCK,
> so iced tea is not an option.
> I added bot Andrews to cc, as they remains masters of IcedTea even now,
> when it is agesd dead (maybe technically beyond resurrection)
>
> IIRC, icedtea is set of patches on top of openjdk. So it remains Opendk.
> So it reqwuires TCK. Pelase anybody if yo really know, correct me. I'm also
> not lawyer.
>
> Thanx a lot for writting this down
>
>
By icedtea I was assuming a cleanout of trademarks like Firefox and Mozilla
is done in Debian. This was not how the previous icedtea was done but it
may be what needs to be reviewed. It does require a legal review and that
would be something for this team to ask the Board and internal Red Hat to
do.

If the licenses for how the coffee-themed language requires a TCK no matter
what, then I would say that JDK is not open/free in a way that is easily
distributable and that would be another thing Fedora board needs to deal
with. In either case it is not you or your team's fault here... and people
saying so need to back off.



> >
> > The reason I am asking is that I think we need to look seriously at the
> alternatives and see how much work the community is going to need to do.
> > 1. Fedora no longer ships a trademarked 'coffee-themed language'.
> Instead it adds an external repository where your team is able to focus on
> what they can deliver.
> > 2. Fedora no longer ships a trademarked 'coffee-themed language'.
> Instead, a volunteer driven SIG puts in an icedtea back into into Fedora
> instead.
> > 3. Fedora no longer ships a trademarked 'coffee-themed language'.
> Instead people wanting it will need to find an external place which builds
> it.
> > 4. Fedora ships a trademarked 'coffee-themed language' that is static.
> However this doesn't decrease the workload enough and we need to move to
> 1-3 in 2 to 3 years.
>
> If we exclude Red hat from Openjdk and it will remain purely on community,
> and if they will be good enogh to really maintian JDKs fo fedora, I cant
> predict impact of Law, when ..someone .. finds it is driven by anonymous
> without signed
> agreement and without TCK. I realy do not know.
>
> Thanx!!!
>   J.
>
>

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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-25 Thread Neal Gompa

On Wed, May 25, 2022 at 9:38 AM Jiri Vanek  wrote:
>
>
>
> On 5/25/22 15:28, Neal Gompa wrote:
> > On Wed, May 25, 2022 at 9:17 AM Jiri Vanek  wrote:
> >>
> >>
> >>
> >> On 5/24/22 22:02, Fabio Valentini wrote:
> >>> On Tue, May 24, 2022 at 5:03 PM Jiri Vanek  wrote:
>  I replied it already in that thread, but happy to repeat:
>  It will help, but less then it seems so.
>  Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of 
>  jdk8 is in some 4 years, so fedora will suffer a bit. But it will be 
>  nice 12 TCK runs down.
>  but we can not droop 11, as it is system jdk in f35
>  Similarly, we couldn't introduce fresh jdk17 directly to f36 as system 
>  JDK. It needs it time to be tuned before being proposed as system jdk.
>  And we can not drop java-latest-openjdk, becasue it is necessary to boot 
>  next system JDK.
>  Yes, in 8 months, we would be able to drop 11. And live for 1 year only 
>  on latest and 17. Which is putting load for one year to 1/2. But the 
>  cost of not having 11 (and 8) will be felt by fedora users more, then 
>  having static jdk from repos.
>  Unluckily, with new future system jdk, we will need to boostrap it by 
>  latest, keep it as secondary jdk at least for one , better two, fedora 
>  cycles, so again we will be in 3  jdks x 3 systems.
>  Sure, we do not need to backport newest future system jdk to older 
>  fedoras, but usually the users want us to do so. tbh, I do not have 
>  strong preference on it. it is like 51 for backport, and 49 for not. 
>  Even with knwoledge of TCK burden.
> >>>
> >>> Is this based on user requests, or is this only what you *think* users
> >>
> >> I'm not sure what you mean  - from above - what is based on mine/wider 
> >> thinking
> >> Generally waht I wrote here it is based on judgmeent of about 10 people 
> >> around OpenJDK pacages in Fedora.
> >> The equations above are based on realistic view and experience. Do you yo 
> >> find some misscalcualtion above?
> >>
> >> I really appreciate you opinions, and would be happyt answer more 
> >> precisely.
> >>
> >>
> >>> of OpenJDK on Fedora need?
> >>> Speaking for myself, I have never used anything other than the default
> >>> "system JDK" for running Java applications on Fedora.
> >>
> >> Are  you really sure? Many applications runtime requiter non system jdk, 
> >> so they pull it in and use, and maybe you have not even noticed.
> >> Many develoeprs ahve installe dmany JDKS (in my case all from repos, 
> >> unless I need to compile jimage) and the switch as needed.
> >>
> >>>
> >>> What would you think about the following scenario:
> >>>
> >>> - Fedora X defaults to new OpenJDK LTS N
> >>> - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
> >>> - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
> >>> the default for one release
> >>> - do not backport OpenJDK n to Fedora X-1 and X-2
> >>> - keep java-latest-openjdk, as you seen to need this for bootstrapping
> >>> new OpenJDK releases
> >>
> >> This is possible solution. It will lower the TCK burden to aprox 3/5 with 
> >> lost of most widely used JDKs from repositories.
> >> I'm open to this proposal. But the removal will hurt and way back will be 
> >> much harder then swithing static builds back to dynamic.
> >>>
> >>> You could even drop java-latest-openjdk from all branches but rawhide,
> >>> since it's only needed for bootstrapping there.
> >>
> >> Taht is very valid point. Cost is it will force huge number of uses  to 
> >> download 3rd party latest STS jdk. it is where all new features live.
> >>> This should pretty dramatically reduce the size of your test matrix.
> >>> Applying the current numbers:
> >>>
> >>> - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> >>> - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
> >>> default needs to be switched back), java-latest-openjdk
> >>> - Fedora 35: java-11-openjdk, java-latest-openjdk
> >>>
> >>
> >> it is a bit less then I wrote, - about 3/5 of current load but do yoreally 
> >> wish to cut all those jdks from fedora?
> >> To me the static repacked build sill somehow seems as smaller evil then 
> >> drop practically all interesting jdks out of distro.
> >>
> >> So here I need to rephrase your question - is it based on your's thinking  
> >> or on what fedora users really needs?
> >> I think the oposite - they need all jdks which are around. Proeprly 
> >> integrated with system. How they are built .. they do not care.
> >> If update to neewer Fedora wil lmake some older JDK disapear, or if need 
> >> of new one will force me to update Fedora when I don't want or cant. I 
> >> call it much worse user expereince
> >>
> >
> > What about only making the older JDKs use bundled static libraries,
> > and the latest LTS and STS versions continue to use dynamic? That
> > would significantly cut down TCK versions and allow

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

2022-05-25 Thread Fabio Valentini

On Wed, May 25, 2022 at 3:17 PM Jiri Vanek  wrote:
>
> On 5/24/22 22:02, Fabio Valentini wrote:
> > Is this based on user requests, or is this only what you *think* users
>
> I'm not sure what you mean  - from above - what is based on mine/wider 
> thinking
> Generally waht I wrote here it is based on judgmeent of about 10 people 
> around OpenJDK pacages in Fedora.
> The equations above are based on realistic view and experience. Do you yo 
> find some misscalcualtion above?
>
> I really appreciate you opinions, and would be happyt answer more precisely.

Thank you for your response, I appreciate that you're engaging with
feedback here.

The way I understood your last message, it seemed to me that you were
claiming that actual Fedora users are requesting that you ship so many
different OpenJDK versions.
However, in this thread, I see the opposite - almost everybody is
asking you to consider dropping support for at least some non-default
OpenJDK versions, and nobody is advocating for keeping all of them. So
my question was whether you have actual user feedback requesting that
so many different versions are available on Fedora.

> > of OpenJDK on Fedora need?
> > Speaking for myself, I have never used anything other than the default
> > "system JDK" for running Java applications on Fedora.
>
> Are  you really sure? Many applications runtime requiter non system jdk, so 
> they pull it in and use, and maybe you have not even noticed.
> Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I 
> need to compile jimage) and the switch as needed.

I'm quite sure, though I'm not using as many Java applications as I used to.
The Minecraft "Java Edition" has always worked fine with the "system /
default JDK", so I never needed to install another one.
And the JetBrains IDEs have bundled their own JDK for a while now, I
think, so I don't have to deal with those, either (and I wouldn't even
want to mess with my main development environment to make it use
something other than the JDK it ships with).

> >
> > What would you think about the following scenario:
> >
> > - Fedora X defaults to new OpenJDK LTS N
> > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
> > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
> > the default for one release
> > - do not backport OpenJDK n to Fedora X-1 and X-2
> > - keep java-latest-openjdk, as you seen to need this for bootstrapping
> > new OpenJDK releases
>
> This is possible solution. It will lower the TCK burden to aprox 3/5 with 
> lost of most widely used JDKs from repositories.
> I'm open to this proposal. But the removal will hurt and way back will be 
> much harder then swithing static builds back to dynamic.
> >
> > You could even drop java-latest-openjdk from all branches but rawhide,
> > since it's only needed for bootstrapping there.
>
> Taht is very valid point. Cost is it will force huge number of uses  to 
> download 3rd party latest STS jdk. it is where all new features live.

Are there really that many Fedora users who need and install
java-latest-openjdk? Do you have estimates of how many people do this,
compared to how many users just use the default system JDK?

> > This should pretty dramatically reduce the size of your test matrix.
> > Applying the current numbers:
> >
> > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
> > default needs to be switched back), java-latest-openjdk
> > - Fedora 35: java-11-openjdk, java-latest-openjdk
> >
>
> it is a bit less then I wrote, - about 3/5 of current load but do yoreally 
> wish to cut all those jdks from fedora?
> To me the static repacked build sill somehow seems as smaller evil then drop 
> practically all interesting jdks out of distro.

Yeah, why not? I'm asking whether it's actually worth your time to
keep them around. Given that there's probably limited userbase and the
resources that are needed to keep them around, this is a valid
question, I think. Speaking for myself, I'd rather have the default,
integrated, system JDK be of the high quality it has been in Fedora,
rather than having many different, less-integrated versions around.

> So here I need to rephrase your question - is it based on your's thinking  or 
> on what fedora users really needs?
> I think the oposite - they need all jdks which are around. Proeprly 
> integrated with system. How they are built .. they do not care.
> If update to neewer Fedora wil lmake some older JDK disapear, or if need of 
> new one will force me to update Fedora when I don't want or cant. I call it 
> much worse user expereince

Well, isn't that the point?

BTW, I noticed that despite java-17-openjdk being the default system
JDK on Fedora 36, it wasn't installed instead of java-11-openjdk when
I upgraded from Fedora 35. That sounds like the change proposal wasn't
fully implemented, either?

Fabio

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




On 5/25/22 15:28, Neal Gompa wrote:

On Wed, May 25, 2022 at 9:17 AM Jiri Vanek  wrote:




On 5/24/22 22:02, Fabio Valentini wrote:

On Tue, May 24, 2022 at 5:03 PM Jiri Vanek  wrote:

I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is 
in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs 
down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It 
needs it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
system JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
latest and 17. Which is putting load for one year to 1/2. But the cost of not 
having 11 (and 8) will be felt by fedora users more, then having static jdk 
from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, 
keep it as secondary jdk at least for one , better two, fedora cycles, so again 
we will be in 3  jdks x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but 
usually the users want us to do so. tbh, I do not have strong preference on it. 
it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.


Is this based on user requests, or is this only what you *think* users


I'm not sure what you mean  - from above - what is based on mine/wider thinking
Generally waht I wrote here it is based on judgmeent of about 10 people around 
OpenJDK pacages in Fedora.
The equations above are based on realistic view and experience. Do you yo find 
some misscalcualtion above?

I really appreciate you opinions, and would be happyt answer more precisely.



of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.


Are  you really sure? Many applications runtime requiter non system jdk, so 
they pull it in and use, and maybe you have not even noticed.
Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I 
need to compile jimage) and the switch as needed.



What would you think about the following scenario:

- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases


This is possible solution. It will lower the TCK burden to aprox 3/5 with lost 
of most widely used JDKs from repositories.
I'm open to this proposal. But the removal will hurt and way back will be much 
harder then swithing static builds back to dynamic.


You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.


Taht is very valid point. Cost is it will force huge number of uses  to 
download 3rd party latest STS jdk. it is where all new features live.

This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:

- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk



it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish 
to cut all those jdks from fedora?
To me the static repacked build sill somehow seems as smaller evil then drop 
practically all interesting jdks out of distro.

So here I need to rephrase your question - is it based on your's thinking  or 
on what fedora users really needs?
I think the oposite - they need all jdks which are around. Proeprly integrated 
with system. How they are built .. they do not care.
If update to neewer Fedora wil lmake some older JDK disapear, or if need of new 
one will force me to update Fedora when I don't want or cant. I call it much 
worse user expereince



What about only making the older JDKs use bundled static libraries,
and the latest LTS and STS versions continue to use dynamic? That
would significantly cut down TCK versions and allow you to focus
dynamic support where it matters (latest Java runtime code).


Quite a fresh thinking!

What about all jdks except system one being static (and repacked), but the 
system one dynamic. That can go below 1/2 of QA runs, without any cut of jdks 
in fedora.
There exists Quite a high risk, that the system jdk will trasnfer form static 
to dynamic in some point (or oposite), and that will lead to unknown new issues 
prety late in lifecycle.






--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09

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

2022-05-25 Thread Stephen Snow

On Wed, 2022-05-25 at 15:03 +0200, Jiri Vanek wrote:
> 
> 
> On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> > On 24/05/2022 21:00, Jiri Vanek wrote:
> > > I repeat what was told several times.We really do no t like this
> > > change, especially in its full sound of one static build repacked
> > > to all ive fedoras, but we have nto found a better way.
> > 
> > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't
> > need certified binaries. 
> We can not ship uncerified JDK. Sooner or later a swarm of lawyers
> would appear.
> 
100%, though I am not one, I understand as much from the TCK itslef.

> > All they need is a working and well packaged OpenJDK.
> > 
> 
>  From point of view of JDK, the jdk will remain working. From point
> of JDK  and generric java world the jdk will be even better.
>  From view of distributions standarts it will become weird misshape.
> Serving it purpose in build root well, serving as system or
> distribution jdk well. But yeah... all was said on this toppic
> already:(
> 
As a user of the JDK as Fedora Linux currently ships it, I can say I am
very grateful for the efforts being made to accomodate it.
> > 2. Reduce the number of OpenJDK branches in the repositories. I
> > think the latest LTS version will be enough.
> 
I have also suggested this, but in historical context JDK 6 hung around
about 10 years longer than expected I think due in large part to the
inertia built by it's prolific use in enterprise systems. This will
undoubtably hold true for JDK 8 as well, since it is currently the
preferred choice by most. Technically speaking WRT JDK releases, some
fall by the wayside (jdk 9 and jdk 10 are two recent). 
> I wish it is so simple. Please see my reply to Kevin when I
> enumerated, that we can not keep "jsut latest" lts.
> > 
> 
Regards,
Stephen Snow
just some dude who can program ... whatever
> -- 
> Jiri Vanek Mgr.
> Principal QA Software Engineer
> Red Hat Inc.
> +420 775 39 01 09
> ___
> devel mailing list -- devel@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)

On 5/25/22 15:19, Stephen Smoogen wrote:

On Wed, 25 May 2022 at 09:04, Jiri Vanek mailto:jva...@redhat.com>> wrote:

On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> On 24/05/2022 21:00, Jiri Vanek wrote:
>> I repeat what was told several times.We really do no t like this
change, especially in its full sound of one static build repacked to all ive fedoras,
but we have nto found a better way.
>
> 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need
certified binaries.
We can not ship uncerified JDK. Sooner or later a swarm of lawyers would
appear.

So could it be shipped instead as a icedtea?

When we were shipping icedtea6 and later icedtea7, it still required TCK, so
iced tea is not an option.
I added bot Andrews to cc, as they remains masters of IcedTea even now, when it
is agesd dead (maybe technically beyond resurrection)

IIRC, icedtea is set of patches on top of openjdk. So it remains Opendk. So it
reqwuires TCK. Pelase anybody if yo really know, correct me. I'm also not
lawyer.

Thanx a lot for writting this down

The reason I am asking is that I think we need to look seriously at the
alternatives and see how much work the community is going to need to do.
1. Fedora no longer ships a trademarked 'coffee-themed language'. Instead it
adds an external repository where your team is able to focus on what they can
deliver.
2. Fedora no longer ships a trademarked 'coffee-themed language'. Instead, a
volunteer driven SIG puts in an icedtea back into into Fedora instead.
3. Fedora no longer ships a trademarked 'coffee-themed language'. Instead
people wanting it will need to find an external place which builds it.
4. Fedora ships a trademarked 'coffee-themed language' that is static. However
this doesn't decrease the workload enough and we need to move to 1-3 in 2 to 3
years.

If we exclude Red hat from Openjdk and it will remain purely on community, and if they will be good enogh to really maintian JDKs fo fedora, I cant predict impact of Law, when ..someone .. finds it is driven by anonymous without signed
agreement and without TCK. I realy do not know.

Thanx!!!
J.
___
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-25 Thread Neal Gompa

On Wed, May 25, 2022 at 9:17 AM Jiri Vanek  wrote:
>
>
>
> On 5/24/22 22:02, Fabio Valentini wrote:
> > On Tue, May 24, 2022 at 5:03 PM Jiri Vanek  wrote:
> >> I replied it already in that thread, but happy to repeat:
> >> It will help, but less then it seems so.
> >> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of 
> >> jdk8 is in some 4 years, so fedora will suffer a bit. But it will be nice 
> >> 12 TCK runs down.
> >> but we can not droop 11, as it is system jdk in f35
> >> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system 
> >> JDK. It needs it time to be tuned before being proposed as system jdk.
> >> And we can not drop java-latest-openjdk, becasue it is necessary to boot 
> >> next system JDK.
> >> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
> >> latest and 17. Which is putting load for one year to 1/2. But the cost of 
> >> not having 11 (and 8) will be felt by fedora users more, then having 
> >> static jdk from repos.
> >> Unluckily, with new future system jdk, we will need to boostrap it by 
> >> latest, keep it as secondary jdk at least for one , better two, fedora 
> >> cycles, so again we will be in 3  jdks x 3 systems.
> >> Sure, we do not need to backport newest future system jdk to older 
> >> fedoras, but usually the users want us to do so. tbh, I do not have strong 
> >> preference on it. it is like 51 for backport, and 49 for not. Even with 
> >> knwoledge of TCK burden.
> >
> > Is this based on user requests, or is this only what you *think* users
>
> I'm not sure what you mean  - from above - what is based on mine/wider 
> thinking
> Generally waht I wrote here it is based on judgmeent of about 10 people 
> around OpenJDK pacages in Fedora.
> The equations above are based on realistic view and experience. Do you yo 
> find some misscalcualtion above?
>
> I really appreciate you opinions, and would be happyt answer more precisely.
>
>
> > of OpenJDK on Fedora need?
> > Speaking for myself, I have never used anything other than the default
> > "system JDK" for running Java applications on Fedora.
>
> Are  you really sure? Many applications runtime requiter non system jdk, so 
> they pull it in and use, and maybe you have not even noticed.
> Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I 
> need to compile jimage) and the switch as needed.
>
> >
> > What would you think about the following scenario:
> >
> > - Fedora X defaults to new OpenJDK LTS N
> > - Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
> > - Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
> > the default for one release
> > - do not backport OpenJDK n to Fedora X-1 and X-2
> > - keep java-latest-openjdk, as you seen to need this for bootstrapping
> > new OpenJDK releases
>
> This is possible solution. It will lower the TCK burden to aprox 3/5 with 
> lost of most widely used JDKs from repositories.
> I'm open to this proposal. But the removal will hurt and way back will be 
> much harder then swithing static builds back to dynamic.
> >
> > You could even drop java-latest-openjdk from all branches but rawhide,
> > since it's only needed for bootstrapping there.
>
> Taht is very valid point. Cost is it will force huge number of uses  to 
> download 3rd party latest STS jdk. it is where all new features live.
> > This should pretty dramatically reduce the size of your test matrix.
> > Applying the current numbers:
> >
> > - Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
> > - Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
> > default needs to be switched back), java-latest-openjdk
> > - Fedora 35: java-11-openjdk, java-latest-openjdk
> >
>
> it is a bit less then I wrote, - about 3/5 of current load but do yoreally 
> wish to cut all those jdks from fedora?
> To me the static repacked build sill somehow seems as smaller evil then drop 
> practically all interesting jdks out of distro.
>
> So here I need to rephrase your question - is it based on your's thinking  or 
> on what fedora users really needs?
> I think the oposite - they need all jdks which are around. Proeprly 
> integrated with system. How they are built .. they do not care.
> If update to neewer Fedora wil lmake some older JDK disapear, or if need of 
> new one will force me to update Fedora when I don't want or cant. I call it 
> much worse user expereince
>

What about only making the older JDKs use bundled static libraries,
and the latest LTS and STS versions continue to use dynamic? That
would significantly cut down TCK versions and allow you to focus
dynamic support where it matters (latest Java runtime code).



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

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




On 5/24/22 22:14, Kevin Fenzi wrote:

On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:


We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
so we have to.  But that is much easier, as the usptream is static within
intree libraries. And we have to run also for 17 and 18/19 as we need this
reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
we test the (source x build) just once.  And we can test the binary on some
known system where we always pass.


Well, I meant test the _dynamic_ build that Fedora does now...


Yy , I got that. What made you think I did not?



But in downstream, new issues usually appear due to the dynamic linking and
nature of system where only it can be installed. Also for dowstram, each
sources are built N times, so N times tested in thsoe N systems - usually
each with its psecific failures.



Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?


As I described in another reply, it is both human and hw. Hw to run all those 
swarm of builds on all platforms, and humans to verify the issue and to fix it.
TCK are very complex, and you need at least three machines in distributed 
system to run them. At least two of those slaves are not trivial (krb master 
and system where tck are running).
Generally saying, I have autoamtion to prepare that all, but second part is 
reproducibility. If the "non mine" setup run will fail for some reason, can I 
rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.


Would it help to have some cloud resources to do this in?
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds.


it is quite hard to imagine better testing resources then I have in Red hat.
Since some amount of HW/remote 3rd party clusters - which we reached - you 
really do not want to continue take care of it.  Also HW and infra failures 
will suddenly multiply to the level that tehre are still some.
And at the end, who wil watch results? And will debugging remain smooth?
So generall sayong - yes more hw would help. But with more HW one needs more 
pople to contorl that and fix, and to check results. So no, really since soem 
amount of workload, jsut more HW is not solution.

Of course that imply possible heavy reorganization JDK team in RH which cares 
about Fedora  rpms in theirs free time, maybe have to do.



I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.



I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is 
in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs 
down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It 
needs it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
system JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
latest and 17. Which is putting load for one year to 1/2. But the cost of not 
having 11 (and 8) will be felt by fedora users more, then having static jdk 
from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, 
keep it as secondary jdk at least for one , better two, fedora cycles, so again 
we will be in 3  jdks x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but 
usually the users want us to do so. tbh, I do not have strong preference on it. 
it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.

If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
With this shortage, we would have
2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That 
sound like a reasonable drop, but only for very short period of time, duriong 
which we will nee to have capcity reserved for ppreparation of next
system jdk: 3 jdks on 3 fedoras with 3 primary architectures=>  27 avarage, 
With much more stress about possible integration issues and with - imo(!) - 
considerable negative imapct to fedora.


ok, sorry I missed a previous reply on this. ;)

So, what would you then think about just:

1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and


Nope. I really ahve huge HW capacity. yes, we reached its capacity. Addng more 
capacity woudl help, but with that will arrive need of more poeple.


2. switching fedora to the static system libraries so you didn't need to
keep the dynamic ones in sync.


Taht is first step. Maybe we will really find that we can not do it in distro, 
and cut of JDK packed will

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

2022-05-25 Thread Stephen Smoogen

On Wed, 25 May 2022 at 09:04, Jiri Vanek  wrote:

>
>
> On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:
> > On 24/05/2022 21:00, Jiri Vanek wrote:
> >> I repeat what was told several times.We really do no t like this
> change, especially in its full sound of one static build repacked to all
> ive fedoras, but we have nto found a better way.
> >
> > 1. Stop doing TCK certification. Most Fedora OpenJDK users don't need
> certified binaries.
> We can not ship uncerified JDK. Sooner or later a swarm of lawyers would
> appear.
>
>
So could it be shipped instead as a icedtea?

The reason I am asking is that I think we need to look seriously at the
alternatives and see how much work the community is going to need to do.
1. Fedora no longer ships a trademarked 'coffee-themed language'. Instead
it adds an external repository where your team is able to focus on what
they can deliver.
2. Fedora no longer ships a trademarked 'coffee-themed language'. Instead,
a volunteer driven SIG puts in an icedtea back into into Fedora instead.
3. Fedora no longer ships a trademarked 'coffee-themed language'. Instead
people wanting it will need to find an external place which builds it.
4. Fedora ships a trademarked 'coffee-themed language' that is static.
However this doesn't decrease the workload enough and we need to move to
1-3 in 2 to 3 years.



> > All they need is a working and well packaged OpenJDK.
> >
>
>  From point of view of JDK, the jdk will remain working. From point of
> JDK  and generric java world the jdk will be even better.
>  From view of distributions standarts it will become weird misshape.
> Serving it purpose in build root well, serving as system or distribution
> jdk well. But yeah... all was said on this toppic already:(
>
> > 2. Reduce the number of OpenJDK branches in the repositories. I think
> the latest LTS version will be enough.
>
> I wish it is so simple. Please see my reply to Kevin when I enumerated,
> that we can not keep "jsut latest" lts.
> >
>
> --
> Jiri Vanek Mgr.
> Principal QA Software Engineer
> Red Hat Inc.
> +420 775 39 01 09
> ___
> devel mailing list -- devel@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 5/24/22 22:02, Fabio Valentini wrote:

On Tue, May 24, 2022 at 5:03 PM Jiri Vanek  wrote:

I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is 
in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs 
down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It 
needs it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
system JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
latest and 17. Which is putting load for one year to 1/2. But the cost of not 
having 11 (and 8) will be felt by fedora users more, then having static jdk 
from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest, 
keep it as secondary jdk at least for one , better two, fedora cycles, so again 
we will be in 3  jdks x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but 
usually the users want us to do so. tbh, I do not have strong preference on it. 
it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.


Is this based on user requests, or is this only what you *think* users


I'm not sure what you mean  - from above - what is based on mine/wider thinking
Generally waht I wrote here it is based on judgmeent of about 10 people around 
OpenJDK pacages in Fedora.
The equations above are based on realistic view and experience. Do you yo find 
some misscalcualtion above?

I really appreciate you opinions, and would be happyt answer more precisely.



of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.


Are  you really sure? Many applications runtime requiter non system jdk, so 
they pull it in and use, and maybe you have not even noticed.
Many develoeprs ahve installe dmany JDKS (in my case all from repos, unless I 
need to compile jimage) and the switch as needed.



What would you think about the following scenario:

- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases


This is possible solution. It will lower the TCK burden to aprox 3/5 with lost 
of most widely used JDKs from repositories.
I'm open to this proposal. But the removal will hurt and way back will be much 
harder then swithing static builds back to dynamic.


You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.


Taht is very valid point. Cost is it will force huge number of uses  to 
download 3rd party latest STS jdk. it is where all new features live.

This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:

- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk



it is a bit less then I wrote, - about 3/5 of current load but do yoreally wish 
to cut all those jdks from fedora?
To me the static repacked build sill somehow seems as smaller evil then drop 
practically all interesting jdks out of distro.

So here I need to rephrase your question - is it based on your's thinking  or 
on what fedora users really needs?
I think the oposite - they need all jdks which are around. Proeprly integrated 
with system. How they are built .. they do not care.
If update to neewer Fedora wil lmake some older JDK disapear, or if need of new 
one will force me to update Fedora when I don't want or cant. I call it much 
worse user expereince


With much more stress about possible integration issues and with - imo(!) - 
considerable negative imapct to fedora.


Would this reduced set of supported OpenJDK versions, but keeping the
"latest" version, address this "considerable negative impact"?


Of course it will. But afaik the imapct is really mch worse then it seems.





Thanx a lot!

 J.

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

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




On 5/24/22 21:41, Vitaly Zaitsev via devel wrote:

On 24/05/2022 21:00, Jiri Vanek wrote:

I repeat what was told several times.We really do no t like this change, 
especially in its full sound of one static build repacked to all ive fedoras, 
but we have nto found a better way.


1. Stop doing TCK certification. Most Fedora OpenJDK users don't need certified binaries. 

We can not ship uncerified JDK. Sooner or later a swarm of lawyers would appear.


All they need is a working and well packaged OpenJDK.



From point of view of JDK, the jdk will remain working. From point of JDK  and 
generric java world the jdk will be even better.
From view of distributions standarts it will become weird misshape. Serving it 
purpose in build root well, serving as system or distribution jdk well. But 
yeah... all was said on this toppic already:(


2. Reduce the number of OpenJDK branches in the repositories. I think the 
latest LTS version will be enough.


I wish it is so simple. Please see my reply to Kevin when I enumerated, that we can not 
keep "jsut latest" lts.




--
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)

2022-05-24 Thread Kevin Fenzi

On Tue, May 24, 2022 at 04:57:54PM +0200, Jiri Vanek wrote:
> 
> We are testing also upstream. note that RH is maintainer of ojdk 11 and 8,
> so we have to.  But that is much easier, as the usptream is static within
> intree libraries. And we have to run also for 17 and 18/19 as we need this
> reference run, to be sure that downstream is guilty, not vanilla jdk. Thus
> we test the (source x build) just once.  And we can test the binary on some
> known system where we always pass.

Well, I meant test the _dynamic_ build that Fedora does now...

> But in downstream, new issues usually appear due to the dynamic linking and
> nature of system where only it can be installed. Also for dowstram, each
> sources are built N times, so N times tested in thsoe N systems - usually
> each with its psecific failures.
> 
> > 
> > Could we integrate the TCK testing in our CI to save you overhead of
> > managing submitting, etc? Or where is the most time spent in this
> > workflow?
> 
> As I described in another reply, it is both human and hw. Hw to run all those 
> swarm of builds on all platforms, and humans to verify the issue and to fix 
> it.
> TCK are very complex, and you need at least three machines in distributed 
> system to run them. At least two of those slaves are not trivial (krb master 
> and system where tck are running).
> Generally saying, I have autoamtion to prepare that all, but second part is 
> reproducibility. If the "non mine" setup run will fail for some reason, can I 
> rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.

Would it help to have some cloud resources to do this in? 
We could definitely get you access to some ec2 instances to setup a test
cluster for testing fedora builds. 

> > I know others have suggested fewer openjdk streams to reduce workload,
> > but I didn't see any reply on that from change owners.
> > 
> 
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 
> is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK 
> runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. 
> It needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
> system JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
> latest and 17. Which is putting load for one year to 1/2. But the cost of not 
> having 11 (and 8) will be felt by fedora users more, then having static jdk 
> from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, 
> keep it as secondary jdk at least for one , better two, fedora cycles, so 
> again we will be in 3  jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, 
> but usually the users want us to do so. tbh, I do not have strong preference 
> on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK 
> burden.
> 
> If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
> With this shortage, we would have
> 2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That 
> sound like a reasonable drop, but only for very short period of time, duriong 
> which we will nee to have capcity reserved for ppreparation of next
> system jdk: 3 jdks on 3 fedoras with 3 primary architectures=>  27 avarage, 
> With much more stress about possible integration issues and with - imo(!) - 
> considerable negative imapct to fedora.

ok, sorry I missed a previous reply on this. ;) 

So, what would you then think about just:

1. having some cloud resources to setup a tck test env that you could
manage better than some ci somewhere and use to test fedora builds.
and
2. switching fedora to the static system libraries so you didn't need to
keep the dynamic ones in sync.

but then trying to see if that reduces your workload to a sustainable
level and avoid the 'build once, certify' thing that is going to end up
being a lot of trouble. 

kevin


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-24 Thread Fabio Valentini

On Tue, May 24, 2022 at 5:03 PM Jiri Vanek  wrote:
> I replied it already in that thread, but happy to repeat:
> It will help, but less then it seems so.
> Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 
> is in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK 
> runs down.
> but we can not droop 11, as it is system jdk in f35
> Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. 
> It needs it time to be tuned before being proposed as system jdk.
> And we can not drop java-latest-openjdk, becasue it is necessary to boot next 
> system JDK.
> Yes, in 8 months, we would be able to drop 11. And live for 1 year only on 
> latest and 17. Which is putting load for one year to 1/2. But the cost of not 
> having 11 (and 8) will be felt by fedora users more, then having static jdk 
> from repos.
> Unluckily, with new future system jdk, we will need to boostrap it by latest, 
> keep it as secondary jdk at least for one , better two, fedora cycles, so 
> again we will be in 3  jdks x 3 systems.
> Sure, we do not need to backport newest future system jdk to older fedoras, 
> but usually the users want us to do so. tbh, I do not have strong preference 
> on it. it is like 51 for backport, and 49 for not. Even with knwoledge of TCK 
> burden.

Is this based on user requests, or is this only what you *think* users
of OpenJDK on Fedora need?
Speaking for myself, I have never used anything other than the default
"system JDK" for running Java applications on Fedora.

What would you think about the following scenario:

- Fedora X defaults to new OpenJDK LTS N
- Fedora X keeps OpenJDK LTS N-1 so it's possible to revert the change
- Fedora X+1 drops OpenJDK N-1, since the newer OpenJDK N was already
the default for one release
- do not backport OpenJDK n to Fedora X-1 and X-2
- keep java-latest-openjdk, as you seen to need this for bootstrapping
new OpenJDK releases

You could even drop java-latest-openjdk from all branches but rawhide,
since it's only needed for bootstrapping there.
This should pretty dramatically reduce the size of your test matrix.
Applying the current numbers:

- Fedora Rawhide: java-17-openjdk (default), java-latest-openjdk
- Fedora 36: java-17-openjdk (default), java-11-openjdk (in case the
default needs to be switched back), java-latest-openjdk
- Fedora 35: java-11-openjdk, java-latest-openjdk

> With much more stress about possible integration issues and with - imo(!) - 
> considerable negative imapct to fedora.

Would this reduced set of supported OpenJDK versions, but keeping the
"latest" version, address this "considerable negative impact"?

Fabio
___
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-24 Thread Vitaly Zaitsev via devel


On 24/05/2022 21:00, Jiri Vanek wrote:
I repeat what was told several times.We really do no t like this change, 
especially in its full sound of one static build repacked to all ive 
fedoras, but we have nto found a better way.


1. Stop doing TCK certification. Most Fedora OpenJDK users don't need 
certified binaries. All they need is a working and well packaged OpenJDK.


2. Reduce the number of OpenJDK branches in the repositories. I think 
the latest LTS version will be enough.


--
Sincerely,
  Vitaly Zaitsev (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 5/24/22 18:37, Vitaly Zaitsev via devel wrote:

On 24/05/2022 16:31, Jiri Vanek wrote:

The goal is to go as shim and cisco - to build in koji, certify, and repack.


shim and openh264 have a good reason for this - legal issues. OpenJDK doesn't. 
Sorry, but I can't treat the laziness of the maintainers as a good reason.


Even if you woulf call 10 years of 5 engineers to keep dynamic builds (and 
generlay jdk in Fedora) alivem, tt had become human-impossible  to continue in 
current way of things.
It will lead to lost of JDK or heavy rework of how JDK s handled now

I repeat what was told several times.We really do no t like this change, 
especially in its full sound of one static build repacked to all ive fedoras, 
but we have nto found a better way.

Really sorry,
  J.




--
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)

2022-05-24 Thread Demi Marie Obenour

On 5/24/22 10:57, Jiri Vanek wrote:
> 
> 
> On 5/23/22 20:40, Kevin Fenzi wrote:
>> So, just replying here since this is a nice monster of a thread. ;(
>>
>> First, just to clear up some previous coments, shim does build against
>> the oldest stable Fedora in koji and then is manually tagged into newer
>> ones. This is not at all a good process. It only gets a bodhi update for
>> the one release (and sometimes not even that), so it never gets good
>> testing. It requires manual intervention from releng each time there's
>> an update. I think the only reason this has kept going is that shim is
>> very small and simple and updates rarely. If we need to do this for tons
>> of openjdk updates, we really should revisit the process, although I am
>> not sure how to make it more open to testing and less a burden on
>> releng. ;(
> 
> Thanx for bringing up additional details!
>>
>> Next, My understanding of the current process for openjdks (openjdki?):
>>
>> for each openjdk:
>>
>> Build dyanmically linking against system libraries in all fedoras.
>> Submit to TCK and wait for them all to process.
>> Fix any TCK failures and repeat
>> Once there's no failures, push the builds to updates
>>
>> Is that right? And keeping the dynamic builds passing is taking more
>> cycles than you have to give for the number of jdks?
> 
> super correct.
> 
>>
>> What about the possibility of adding CI _upstream_ to test against the
>> dynamic version? Then TCK failures would be caught upstream and not
>> downstream where it's a lot of work for you to fix?
> 
> We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so 
> we have to.  But that is much easier, as the usptream is static within intree 
> libraries. And we have to run also for 17 and 18/19 as we need this reference 
> run, 
> to be sure that downstream is guilty, not vanilla jdk. Thus we test the 
> (source x build) just once.  And we can test the binary on some known system 
> where we always pass.
> But in downstream, new issues usually appear due to the dynamic linking and 
> nature of system where only it can be installed. Also for dowstram, each 
> sources are built N times, so N times tested in thsoe N systems - usually 
> each with its 
> psecific failures.

Kevin’s suggestion is for upstream to test dynamic builds, not just
static ones, in its CI.  That means that if the dynamic build breaks,
it would be upstream’s problem.

In other words: Instead of shipping a static JDK in Fedora, make the
dynamic JDK a first-class citizen upstream.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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-24 Thread Chris Adams

Once upon a time, Vitaly Zaitsev  said:
> Sorry, but I can't treat the laziness of the
> maintainers as a good reason.

Can you PLEASE stop with the personal attacks?
-- 
Chris Adams 
___
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-24 Thread Vitaly Zaitsev via devel


On 24/05/2022 16:31, Jiri Vanek wrote:

The goal is to go as shim and cisco - to build in koji, certify, and repack.


shim and openh264 have a good reason for this - legal issues. OpenJDK 
doesn't. Sorry, but I can't treat the laziness of the maintainers as a 
good reason.


--
Sincerely,
  Vitaly Zaitsev (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 5/21/22 13:38, Neal Gompa wrote:

On Sat, May 21, 2022 at 7:28 AM Jiri Vanek  wrote:




On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:

On 20/05/2022 14:28, Jiri Vanek wrote:

wait, what? What do you mean? And waht give you this impression?


https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:

  > Make the normal rpms to not built jdk, but to repack the portable rpms with 
all integration


thanx.




Or are you already in the follwoing year, when the attempt will be doen to 
build each JDK  in koji just  once, and ship it to al llive fedoras?


Repackaging of anything even it was built in Koji is strictly prohibited. All 
packages must be built from sources. No exceptions.


shim?


Shim is technically built on Fedora infrastructure as shim-unsigned.
Microsoft signs that binary and the shim package has those binaries as
sources in that package.

OpenJDK is not that strict, and frankly I don't think we'd want to do
more than just that package that way. It's a massive pain and it's
pretty evident that this arrangement causes us serious problems too,
since it locks the Fedora community out of fixing issues at that
level.



Hm. For "silent observer" (in case of shmi and codecs) the burden seemed not so 
high, But as Kevinlater described, it was a bit underestimated.






--
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/23/22 20:40, Kevin Fenzi wrote:

So, just replying here since this is a nice monster of a thread. ;(

First, just to clear up some previous coments, shim does build against
the oldest stable Fedora in koji and then is manually tagged into newer
ones. This is not at all a good process. It only gets a bodhi update for
the one release (and sometimes not even that), so it never gets good
testing. It requires manual intervention from releng each time there's
an update. I think the only reason this has kept going is that shim is
very small and simple and updates rarely. If we need to do this for tons
of openjdk updates, we really should revisit the process, although I am
not sure how to make it more open to testing and less a burden on
releng. ;(

Thanx for bringing up additional details!

Next, My understanding of the current process for openjdks (openjdki?):

for each openjdk:

Build dyanmically linking against system libraries in all fedoras.
Submit to TCK and wait for them all to process.
Fix any TCK failures and repeat
Once there's no failures, push the builds to updates

Is that right? And keeping the dynamic builds passing is taking more
cycles than you have to give for the number of jdks?

super correct.

What about the possibility of adding CI _upstream_ to test against the
dynamic version? Then TCK failures would be caught upstream and not
downstream where it's a lot of work for you to fix?

We are testing also upstream. note that RH is maintainer of ojdk 11 and 8, so we have to. But that is much easier, as the usptream is static within intree libraries. And we have to run also for 17 and 18/19 as we need this reference run,
to be sure that downstream is guilty, not vanilla jdk. Thus we test the (source x build) just once. And we can test the binary on some known system where we always pass.
But in downstream, new issues usually appear due to the dynamic linking and nature of system where only it can be installed. Also for dowstram, each sources are built N times, so N times tested in thsoe N systems - usually each with its
psecific failures.

Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?

As I described in another reply, it is both human and hw. Hw to run all those
swarm of builds on all platforms, and humans to verify the issue and to fix it.
TCK are very complex, and you need at least three machines in distributed
system to run them. At least two of those slaves are not trivial (krb master
and system where tck are running).
Generally saying, I have autoamtion to prepare that all, but second part is
reproducibility. If the "non mine" setup run will fail for some reason, can I
rerun it? Can I debug it? I'm finding this very hard in 3rd party hw clusters.

I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.

I replied it already in that thread, but happy to repeat:
It will help, but less then it seems so.
Now we can drop 8. Soem legacy applciations will be unhappy, as EOL of jdk8 is
in some 4 years, so fedora will suffer a bit. But it will be nice 12 TCK runs
down.
but we can not droop 11, as it is system jdk in f35
Similarly, we couldn't introduce fresh jdk17 directly to f36 as system JDK. It
needs it time to be tuned before being proposed as system jdk.
And we can not drop java-latest-openjdk, becasue it is necessary to boot next
system JDK.
Yes, in 8 months, we would be able to drop 11. And live for 1 year only on
latest and 17. Which is putting load for one year to 1/2. But the cost of not
having 11 (and 8) will be felt by fedora users more, then having static jdk
from repos.
Unluckily, with new future system jdk, we will need to boostrap it by latest,
keep it as secondary jdk at least for one , better two, fedora cycles, so again
we will be in 3 jdks x 3 systems.
Sure, we do not need to backport newest future system jdk to older fedoras, but
usually the users want us to do so. tbh, I do not have strong preference on it.
it is like 51 for backport, and 49 for not. Even with knwoledge of TCK burden.

If currently we have 4 jdks on 3 fedoras with 3 primary architectures=> 36 TCK
With this shortage, we would have
2 jdks on 2 fedoras with 3 primary architectures=> 12 tck in minimum. That
sound like a reasonable drop, but only for very short period of time, duriong
which we will nee to have capcity reserved for ppreparation of next
system jdk: 3 jdks on 3 fedoras with 3 primary architectures=> 27 avarage,
With much more stress about possible integration issues and with - imo(!) -
considerable negative imapct to fedora.

TYVM!
___
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

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




On 5/21/22 13:51, Vitaly Zaitsev via devel wrote:

On 21/05/2022 13:22, Jiri Vanek wrote:

shim?


Built on Koji from sources as shim-unsigned, then uploaded to Microsoft for 
signing.

This is a special legal case, just like openh264 and Cisco.

Both of them built from sources on Fedora infra.



I repeat, aprox 21st time - I will never ever use blob. I will always build 
from sources in koji.
The goal is to go as shim and cisco - to build in koji, certify, and repack.

J.

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
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-23 Thread Guido Aulisi

Hi,

> Il giorno 10 mag 2022, alle ore 15:29, Ben Cotton  ha 
> scritto:
> 
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> This is initial step to move JDKs to be more like other JDKs, to build
> proper transferable images, and to lower certification burden of each
> binary. Long storyshort, first step in:
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> 
> This first step will move, one by one, individual JDKs in F37 to be
> built `--with-stdc++lib=static` and against in-tree (bundeld)
> libraries:  `--with-zlib="bundled"  --with-freetype="bundled"
> --with-libjpeg="bundled"  --with-giflib="bundled"
> --withlibpng="bundled"  --with-lcms="bundled"
> --with-harfbuzz="bundled" `
> 

-1 here, we should avoid bundled libraries


> We already made a heavy testing of the behavior, and user should not
> face negative experience. I'm not sure if this is
> 
> == Owner ==
> * Name: [[User:jvanek| Jiri Vanek]]
> * Email: jva...@redhat.com
> 
> 
> == Detailed Description ==
> Please see https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> for whole picture
> 
> Please see 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_JDKs_in_RPMs_to_become_portable
> for this particular step. I would rather keep the details  in the main
> page then here.
> 
> == Feedback ==
> According to short investigations, there are already precedents, where
> certification is a reason to build once, certificate, and repack.
> 
> According to developers, the non-portbale JDK is  causing upredicted
> behavior different from other JDK vendors
> 
> According to JDK packagers and testers, there is to much JDKs now, and
> the 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Move_Fedora_JDKs_to_become_single-built.2C_portable.2C_ordinary_JDKs.2C_while_keeping_comfortable.2C_usual_system_integration
> is the only way out
> 
> == Benefit to Fedora ==
> Please see 
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Motivation
> for whole picture.
> 
> This particular proposal's main benefit will be that Fedora's JDKs as
> packed in RPMs will again start to resemble upstream JDKs and other
> vendors build, and some platform specific issues disappear, while JDKs
> remain same in view of system integration and user experience
> 
> == Scope ==
> * Proposal owners: push improved version of
> https://src.fedoraproject.org/rpms/java-latest-openjdk/pull-request/98#request_diff
> to all JDKs - one by one from latest, over 17 to 11 and 8. Once
> settled down in F37 the backport to F36 is expected.
> 
> * Other developers: really, nothing. If there will be unexpected
> impact to other developers, the
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs may
> need rework
> 
> * Release engineering: N/A [https://pagure.io/releng/issues #Releng
> issue number]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
> 
> 
> == Upgrade/compatibility impact ==
> The compatibility and upgrade path should remain completely smooth.
> 
> 
> == How To Test ==
> Install system JDK (java-17-openjdk) and ru your favorite application
> or development. No regression should be noted.
> 
> 
> == User Experience ==
> 
> Because of in-tree  libraries, minimal image or font rendering
> differences canbe spotted after very detailed investigations -
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Side_effects
> - still, no of th e
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs#Known_issues
> should be hit by this proposal.
> 
> 
> == Dependencies ==
> No dependent packages should notice the change.
> 
> 
> == Contingency Plan ==
> * Contingency mechanism: Revert the patches and rework
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> * Contingency deadline: before f37 release
> * Blocks release? Unless the java-stack will become completely borked then no.
> 
> 
> == Documentation ==
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> 
> 
> 
> -- 
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___

I don’t agree with this proposal, a big -1 for this

FAS: tartina

Ciao
___
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:

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

2022-05-23 Thread Kevin Fenzi

So, just replying here since this is a nice monster of a thread. ;( 

First, just to clear up some previous coments, shim does build against
the oldest stable Fedora in koji and then is manually tagged into newer
ones. This is not at all a good process. It only gets a bodhi update for
the one release (and sometimes not even that), so it never gets good
testing. It requires manual intervention from releng each time there's
an update. I think the only reason this has kept going is that shim is
very small and simple and updates rarely. If we need to do this for tons
of openjdk updates, we really should revisit the process, although I am
not sure how to make it more open to testing and less a burden on
releng. ;( 

Next, My understanding of the current process for openjdks (openjdki?):

for each openjdk:

Build dyanmically linking against system libraries in all fedoras. 
Submit to TCK and wait for them all to process.
Fix any TCK failures and repeat
Once there's no failures, push the builds to updates

Is that right? And keeping the dynamic builds passing is taking more
cycles than you have to give for the number of jdks?

What about the possibility of adding CI _upstream_ to test against the
dynamic version? Then TCK failures would be caught upstream and not
downstream where it's a lot of work for you to fix?

Could we integrate the TCK testing in our CI to save you overhead of
managing submitting, etc? Or where is the most time spent in this
workflow?

I know others have suggested fewer openjdk streams to reduce workload,
but I didn't see any reply on that from change owners.

Thanks, 

kevin


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-21 Thread Vitaly Zaitsev via devel


On 21/05/2022 13:22, Jiri Vanek wrote:

shim?


Built on Koji from sources as shim-unsigned, then uploaded to Microsoft 
for signing.


This is a special legal case, just like openh264 and Cisco.

Both of them built from sources on Fedora infra.

--
Sincerely,
  Vitaly Zaitsev (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-21 Thread Neal Gompa

On Sat, May 21, 2022 at 7:28 AM Jiri Vanek  wrote:
>
>
>
> On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:
> > On 20/05/2022 14:28, Jiri Vanek wrote:
> >> wait, what? What do you mean? And waht give you this impression?
> >
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
> >
> >  > Make the normal rpms to not built jdk, but to repack the portable rpms 
> > with all integration
>
> thanx.
>
> >
> >> Or are you already in the follwoing year, when the attempt will be doen to 
> >> build each JDK  in koji just  once, and ship it to al llive fedoras?
> >
> > Repackaging of anything even it was built in Koji is strictly prohibited. 
> > All packages must be built from sources. No exceptions.
>
> shim?

Shim is technically built on Fedora infrastructure as shim-unsigned.
Microsoft signs that binary and the shim package has those binaries as
sources in that package.

OpenJDK is not that strict, and frankly I don't think we'd want to do
more than just that package that way. It's a massive pain and it's
pretty evident that this arrangement causes us serious problems too,
since it locks the Fedora community out of fixing issues at that
level.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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-21 Thread Jiri Vanek




On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:

On 20/05/2022 14:28, Jiri Vanek wrote:

wait, what? What do you mean? And waht give you this impression?


https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:

 > Make the normal rpms to not built jdk, but to repack the portable rpms with 
all integration


thanx.



Or are you already in the follwoing year, when the attempt will be doen to build each JDK  in koji just  once, and ship it to al llive fedoras? 


Repackaging of anything even it was built in Koji is strictly prohibited. All 
packages must be built from sources. No exceptions.


shim?




--
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)

2022-05-21 Thread Jiri Vanek




On 5/20/22 14:57, Vitaly Zaitsev via devel wrote:

On 20/05/2022 14:28, Jiri Vanek wrote:

wait, what? What do you mean? And waht give you this impression?


https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:

 > Make the normal rpms to not built jdk, but to repack the portable rpms with 
all integration


thanx.



Or are you already in the follwoing year, when the attempt will be doen to build each JDK  in koji just  once, and ship it to al llive fedoras? 


Repackaging of anything even it was built in Koji is strictly prohibited. All 
packages must be built from sources. No exceptions.


shim?





--
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)

2022-05-21 Thread Jiri Vanek


It is not so bad. and I definitely do not feel offended or even close to.

Many languages have very interesting words which go far beyond true/false 
untrue/not false/ correct/incorrect right/left/lie
Thus saying many languages can not match to other langunages meaning of simple 
true/false  right/left/lie 1:1
And even if they can, there remain cases which only native speaker can 
recognize.

Thus saying, I was wrong write down driver, where I meant firmware. I was wrong 
and am happy for correction.

It was sure form begining that this proposal will rise emotions - some one 
wrote it perfectly: clash of cultures. And will take bilions of liens to 
explain.
And where it indeed rised a lot of emotions, lets leave the language details, 
and lets turn back to topic.


Still thanx a lot alle, ven for this part language corner part. it was 
educative.


J.


On 5/20/22 14:46, Dominik 'Rathann' Mierzejewski wrote:

On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote:

On 18/05/2022 17:04, Stephen Smoogen wrote:

It generally means and is interpreted as 'not true with the intention of
deceiving'. 'incorrect' is considered 'not true'.


The Oxford English Dictionary gives the following answer:

lie (noun) - an intentionally false statement
used with reference to a situation involving deception or founded on a
mistaken impression


Exactly. So, you implied malicious intent where there was none.

Regards,
Dominik


--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
___
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-20 Thread Stephen Smoogen

On Fri, 20 May 2022 at 08:43, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 20/05/2022 14:03, Jiri Vanek wrote:
> > As writtten several times - this si not true.  It will eb always source
> > codebuilt in koji.
>
>  From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:
>
>
I looked through the wiki history and it has said the following since the
first page in April 8th:
```
It is also not a goal, to pack third party blob. Jdk will still continue to
build in koji as it should.
```

Is there some other section which counters this?


> Make the normal rpms to not built jdk, but to repack the portable rpms
> with all integration
>
>





> --
> Sincerely,
>Vitaly Zaitsev (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 20/05/2022 14:33, Jiri Vanek wrote:

Who shold hire them. You? Me? Fedoraproject?


Red Hat.

--
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 20/05/2022 14:28, Jiri Vanek wrote:

wait, what? What do you mean? And waht give you this impression?


https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:

> Make the normal rpms to not built jdk, but to repack the portable 
rpms with all integration


Or are you already in the follwoing year, when the attempt will be doen to build each JDK  in koji just  once, and ship it to al llive fedoras? 


Repackaging of anything even it was built in Koji is strictly 
prohibited. All packages must be built from sources. No exceptions.


--
Sincerely,
  Vitaly Zaitsev (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 20/05/2022 14:46, Dominik 'Rathann' Mierzejewski wrote:

Exactly. So, you implied malicious intent where there was none.


we don't know for sure.

--
Sincerely,
  Vitaly Zaitsev (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-20 Thread Dominik 'Rathann' Mierzejewski

On Wednesday, 18 May 2022 at 17:18, Vitaly Zaitsev via devel wrote:
> On 18/05/2022 17:04, Stephen Smoogen wrote:
> > It generally means and is interpreted as 'not true with the intention of
> > deceiving'. 'incorrect' is considered 'not true'.
> 
> The Oxford English Dictionary gives the following answer:
> 
> lie (noun) - an intentionally false statement
> used with reference to a situation involving deception or founded on a
> mistaken impression

Exactly. So, you implied malicious intent where there was none.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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 18:34, Vitaly Zaitsev via devel wrote:

On 18/05/2022 17:51, jiri vanek wrote:

You can not put uncertified JDK to fedora.


Why not?


And we can no longer properly support certified dynamic builds


Hire new maintainers who can.


Who shold hire them. You? Me? Fedoraproject?




--
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 18:36, Neal Gompa wrote:

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.



Thanx for writing it up. As wakefield is targetting jdk 20 at soonest, I wil 
both keep it in mind for wakefile project, and for Fedora jdk, this may be an 
interesting testing how the bundling actually works.
My rough assumtpion would be, that it will remain runtime-laoding part, as JDK 
have to decide, if it is on X or Wayland, and load acordingly.





--
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 18:32, Vitaly Zaitsev via devel wrote:

On 18/05/2022 18:01, Neal Gompa wrote:

At this point, I'd rather have an OpenJDK in Fedora than not. If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.


They also want to bundle pre-built binaries into dependent packages.


wait, what? What do you mean? And waht give you this impression?

Or are you already in the follwoing year, when the attempt will be doen to 
build each JDK  in koji just  once, and ship it to al llive fedoras?




--
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 19:14, Michael Catanzaro wrote:

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.

For leaf application this is siple. But for uttermost root of one huge
depndency chain, it would be bad.

If that
means switching to bundled libraries, then fine. But all bundled
libraries need to be documented in the spec file and that information
needs to be kept up to date.

Provides: bundled(foo) is very important. With this, every time a CVE is found in a dependent library, Product Security is going to report a bug against Java, and it will be expected to be fixed in Java. It's a lot of extra responsibility.
Without the Provides, tracking such issues is impractical. Every bundled library needs a Provides, not only the ones that would be affected by this change.

I agree. and it will be there/

Michael

___
devel mailing list -- devel@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 20/05/2022 14:03, Jiri Vanek wrote:
As writtten several times - this si not true.  It will eb always source 
codebuilt in koji.


From https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs:


Make the normal rpms to not built jdk, but to repack the portable rpms with all 
integration


--
Sincerely,
  Vitaly Zaitsev (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 5/18/22 18:22, Fabio Valentini wrote:

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?


thanx for this understanidng:(



Maybe we can think about whether it's absolutely necessary to keep
maintaining three different LTS versions of OpenJDK? Dropping at least
java-1.8.0-openjdk would already reduce maintenance burden for OpenJDK
packages by over 25% (given that 1.8.0 seems to cause you most of the
problems recenty).


This would of course help, but I would rahter keep 4 different jdks packed 
once, then 1 jdk packed 4 times.
Still we will need to maintain usually 1, but very opften two system jdks, and 
we will need to continue maintain java-latest-openjdk as we need it to bootsrap 
 next main jdk.
Also we need java-lates-opnjdk live in release, not jsut in buidlroot, so we 
can tune integration of future jdk fluently.


If statically linking against bundled versions of *some* dependencies
would really help that much, it might also be worth considering, as a
last resort, to keep OpenJDK packages in Fedora at all.

However, I personally am strongly against the "follow-up" proposal,
MoveFedoraJDKsToBecomePortableJDKs. Most importantly, the "Known
issues" section on this wiki page sounds to me like it should be
completely out of the question to actually go forward with the
proposal.


We are going to fix known issue. Unless the known issues are solved, we can not 
continue.
All except debuginfo are somehow solvable.
Can you please enumerate what parts of known issues toruel syou most? that 
would be super valuable information.
I rate them all moreover in same level, as anoying, but really fixable (not 
jsut workaround-able) for common benefit.



Some time ago, jiri vanek  wrote:
We realy do no like this change, but we do not see another way.


I wonder how this happened? Has this issue been brewing for a while?



We have the issues which led to this proposal since jdk 11 appeared in fedora. 
The issue was unluckily not getting away, and was jsut getting worse, until 
this proposal occured.


Or will Red Hat be downsizing the OpenJDK team in the near future? ;)


nope, but the multiplying of JDK employees is unluckily nor following 
multiplying of JDKs...




Fabio
___
devel mailing list -- devel@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 18:01, 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.


I deeply appreciate your understanding.


Can we do this without going down the route of building only once at
one distribution tag and tagging the binary into everything else?


If we do only this dirst part, then the TCK burden would not be lifted.
Still it make maintaneace much more easy.





--
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)




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)




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)



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)




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)




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/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)

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)

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)


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 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)

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)


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 Neal Gompa

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 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)

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 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)


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)

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)

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 Neal Gompa

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)

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)

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)

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)

2022-05-18 Thread Neal Gompa

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)

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)