subject:"Re\: F39 Change Proposal\: Build JDKs once, repack everywhere \(System\-Wide Change\)"




On 5/31/23 19:58, Chris Adams wrote:

Once upon a time, Jiri Vanek  said:

I have fixed typo in the proposal " Should be built in oldest live EPEL" instead of 
" Should be built in latest live EPEL", which was wrong.


At the moment though, the oldest live EPEL is 7, not 8.


Right. And we are nto building java-latest-openjdk here, becasue it is no 
longerbuildable by its toolcahin.
Once java-altest-openjdk (which is the only epel based) will be notbuildable in 
el8, which will stillbe live I guess, we weill dropit there,and move it to 
epel9.And so on, untill ethernity.

Will enchance proposal for this. TY!



I do not have hard requirement to build java-latest-openjdk on epel8
and repack everywhere, but it gave sense. If the hard demand will be
to build also java-latest-opnejdk in oldest fedora, and repack in
all fedoras, and built it in oldest epel, and repack in all epels,
then it gave somehow sesnse too. Although I would conisdered it a
bit wasted cycle, it is acceptable.


I think building for Fedora in Fedora would moderate the concerns about
old compiler/flags/etc., because the oldest Fedora at any point is about
a year old.  The oldest EPEL (7) is currently approaching 9 years old,
and even the oldest you listed (8) is 4 years old.

It would also help with reproducibility.  EPEL is built against RHEL,
which is not freely available (yes, there are rebuilds, there are free
limited developer licenses, etc., but it's not directly easy for someone
else to exactly reproduce the EPEL build environment).  That's okay for
EPEL builds, but I personally feel it would be more acceptable to build
Fedora packages on Fedora.



--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On 5/31/23 20:02, Daniel P. Berrangé wrote:

On Wed, May 31, 2023 at 07:38:38PM +0200, Jiri Vanek wrote:

Can you clarify this a bit? It sounds like some versions of the JDK in
Fedora will actually be built in EPEL. I feel that all Fedora packages
should actually built for Fedora, not RHEL.

Also, what exactly does "latest live EPEL" mean - how is 8 the latest?

I guess basically, can you further explain/clarify exactly which
versions of what OS which JDKs will be built on, and when those versions
will change.

Jdk is designed, to be severely forward comaptible from os where it was built.
So jdk8, 11 and 17 would be build in oldest live fedora, and repacked
everywhere. The idea is to build them on oldest viable system, as we
can guarantee they will run ok in newer Fedroas..
java-latest-openjdk however, is built also for epel8 and elep9. Thus
logically the oldest system where we can built it to repack it everywhere
is el8. Then it can be reapcked for el8,el9, and all live fedoras.

IIRC, RHEL-8 forked from Fedora in circa F28 timeframe. Directly
comparing RHEL-8 content to Fedora is a bit of a fools errand since
RHEL does rebase certain packages periodically, but a decent chunk
of RHEL-8 is 5 years old at this point. The most notable part is
the compiler toolchain on RHEL-8 is GCC 8.x, which is 5 major
releases behind what F39 rawhide uses, and 4 major release behind
what F37 uses.

RHEL-8 also has a long lifetime left, and thus so does EPEL8. By
building JDK on EPEL8, we're fixing the toolchain for JDK in Fedora
on a version already 5 years out of date, and by the time EPEL8 goes
away, the toolchain will be 10+ years out of date.

By building JDK on the oldest stable Fedora release, we're fixing the
toolchain on a version that's never going to be much more then 1 year
out of date.

Same applies to compiler toolchain flags, though where the flags don't
depend on GCC version that can be partially mitigated in the JDK spec.

Overall, I find the idea of basing Fedora builds on oldest EPEL quite
challenging to accept, due to the age differences. It feels contrary
to Fedora goal of always being on, or at least very near, the cutting
edge.

I do not have hard requirement to build java-latest-openjdk on epel8 and
repack everywhere, but it gave sense. If the hard demand will be to build
also java-latest-opnejdk in oldest fedora, and repack in all fedoras, and
built it in oldest epel, and repack in all epels, then it gave somehow
sesnse too. Although I would conisdered it a bit wasted cycle, it is
acceptable.

IMHO it'd be more palatable for the RHEL (EPEL) build stream to be separate
from the Fedora build stream. While RHEL and Fedora share heritage, they are
ultimately different distros with different goals and needs.

Thanx for an input!

One important clarification whcih I will somehow try to include to proposal.
The epel thing is valid only for java-latest-openjdk, which is STS. It is much more likley, thet future jdk will not be buildable on epel8, and thus we wills top building it there as we did with epel7. Then we wll shift the build root to
the epel9 and so on.

Yet again thanx for input.

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, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On 6/1/23 15:08, Panu Matilainen wrote:

On 6/1/23 15:43, Robert Marcano via devel wrote:

On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.

It sounds like the problem is the software isn't really open source
because it has some field of use restrictions. The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.

Rich.

It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.

Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue. (I'll leave this to lawyers to
answer definitely though.)

Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.

That's nice, and indeed RHEL ships OpenJDK. The question is about
what we do in Fedora.

Rich.

All this change is about the burden of maintaining so many OpenJDK branches as packages in FEdora. Maybe Fedora should stop distributing ancient Java versions as one of our missions is to be cutting edge, maybe we are still encouraging
too many projects to stay running on Java 8.

I am saying this as some that would be affected if Java 8 isn't packaged anymore, I still need to develop and test some things with Java 8 because at work we have some customers still running ancient hardware and have been a pain to make
them move to modern distributions. So I will have to us another universal OpenJDK build (like Temurin)

Maybe Fedora should just package the latest JDK needed for Android development and the latest LTS version. An even the Android (11 I think) could be skipped because Android Studio includes a build of it. If there are packages still
requiring old things, help to update them could be offered by packagers, or dropped from the distribution.

This sounds much, much more Fedora than the proposal at hand.

Customers running ancient hardware is a problem for the RHEL space, not Fedora.

See my reply I ha just sent to Robert.

Thanx!

- Panu -
___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue

--
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, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

To reduce number of jdks remains an option, but few hints:
Me, as end user application provider would rather `dnf install/update java` then maintain 3rd aprty blob. At least the java is known to be working and on Fedora and is built by trusted infrastructure (which I case to agree for every other
vendor). And I need all four javas as are currently shipped in fedora.

Me, as fedora dummy user do not care. I need system jdk working.
Me, as fedora advanced user do not want to solve fedora-specific issues.
Me as jdk maintainer cares, just count:
jdk 8,11,17, latest and 21 - 5jdks. For 3-4 live fedoras. Each with 4
platforms. Lets skip the platforms, but they still count to both HW and human
cycles.
That is 12-20 jdk binary builds per platform which have to be certified
If we build once and repack, that would be just 4-5 binaries which needs to be
certified.
If we would keep just system jdk then it will not help at all:
- we have to keep java-latest-openjdk because its bleeding edge technology
which fedora shoudl provide
- next LTS, and thus next system jdk is always forked from java-latest-openjdk
=> you have *two* jdks on 3-4 systems every time (thus 6-8 certifications)
- the system JDK is not constant but shifts. In worst scenario there will be 3 system JDKs in 3 live fedoras, but msot likely there will be indeed 1-2 system JDKS. But that is still twho from above + 1-2 from this line, and thus we are
back on maintaining 3-4JDKS on 3-4 fedoras:(

All is much more then buils once and repack everywhere:(

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On 6/1/23 13:33, Kevin Kofler via devel wrote:

Jiri Vanek wrote:

At elast providing ofjava/openjdk is definitley out of scope.

I do not think a Provides would be a trademark violation. It is a part of
the standard procedure for renaming a package. But you would have to ask Red
Hat Legal for a definite answer. I am not a lawyer.

That said, there might not even be a trademark issue at all, at least for
"OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing
to:
https://openjdk.org/legal/openjdk-trademark-notice.html

As you wrote about the liberty of choice between temurins and fdeoara ona
- can you be a bit more specific? Afaik if the builds are similar, we have
mcuh less possibility of some fedora-specific bug.

But it also means that I no longer have the option to use a Java that does
not bundle several libraries, possibly including security vulnerabilities,

Nope. That is actually somehting what should get better. Java is good security
issues handling.

bloating its size, and likely reducing system integration (there have been
concerns about, e.g., worse fontconfig integration in the discussion of your

And have it proven to be true? I doubt.

previous Change proposal). There is now just the "choice" between a Fedora
package with everything bundled and third-party packages with also
everything bundled.

I once wrote,m that wworked 10years to enable dynamic linking, and yes,
all is upstream, but there are limitations which can not be overtaken -
major is ahead of tie comilation. If you can do it right, you cnanot have
dyanmic linking.

Wait, Java does real AOT compilation now? Or are we talking about that
strange "feature" you already brought up in the old discussion, where you
basically just prepend a JRE to a JAR and ship that as a "compiled"
executable? That "feature", to be honest, I had never heard of before you
folks brought it up.

It started with jlink, and then javaaot had shown the way, and now this lives
in graal and madrel/quarkus projects. And even spring boot is working on theirs
AOTcompiler.
I'm only observer for Mandrel project, but it seems to be working, although
still quite a lot of work is ahead.

As far as I can tell, nobody in the Java world uses it. It breaks the "write
once, run anywhere" promise and brings us no real advantage over having the
JRE and the JAR separate.

I agree with you, adn I dont like the aot of java. However business seems to be
going there, otherwise several big companyes would not invest so heavily to
graal, mandrel, quarkus and springboot.
The benefits and reasoning are disputable. As I'm on your side on this I can
not defend them.
Still, meas casual javadevloper, am delivering all - jars, wars, apks, jlinked iamges and also aot compiled binaries as needed,a s each is usefull for different customer cases. Untill static build was introduced to fedora, I had to use 33rd
party java for jlinked and aot compiled images.

It is definitely not useful for me because our customers all run Windows,
not Fedora or any other GNU/Linux. So really it makes no difference for me
whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking)
or on all GNU/Linux (static linking), they will not run on our customers'
computers anyway, making that "feature" entirely useless either way.

We have a few ways to deploy our JARs to our customers, but none of them
involves turning them into native executables through (either real or fake
as described above) AOT compilation.

The goal should still be to have fedora rpms properly integrated in
fedora, and usable, as any other java onthe world, without hacks.

Sorry, but I believe that the old packaging was exactly that, "properly
integrated" and "without hacks", whereas I have to politely disagree about
the new packaging having those properties.

The integration wll remain intact. But I gusess we disagree on definition on
integration.
The "only" take away are static linkings of java-crucial libraries (and my opinion as JDK developer is still that it is better), and now older build chain will be added. Except the new flags and gcc - which were sometimes hard to adapt, and
we excluded most of them - I do no see much lost.

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Panu Matilainen


On 6/1/23 15:43, Robert Marcano via devel wrote:

On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.


Rich.



It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.


Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)


Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.


That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.



All this change is about the burden of maintaining so many OpenJDK 
branches as packages in FEdora. Maybe Fedora should stop distributing 
ancient Java versions as one of our missions is to be cutting edge, 
maybe we are still encouraging too many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged 
anymore, I still need to develop and test some things with Java 8 
because at work we have some customers still running ancient hardware 
and have been a pain to make them move to modern distributions. So I 
will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android 
development and the latest LTS version. An even the Android (11 I think) 
could be skipped because Android Studio includes a build of it. If there 
are packages still requiring old things, help to update them could be 
offered by packagers, or dropped from the distribution.


+1

This sounds much, much more Fedora than the proposal at hand.

Customers running ancient hardware is a problem for the RHEL space, not 
Fedora.


- Panu -
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Robert Marcano via devel


On 6/1/23 8:33 AM, Richard W.M. Jones wrote:

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:

On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it

>from Fedora.


Rich.



It is the same discussion about Firefox that is already settled I
think. The JVM code is open source, even free software. The
trademark isn't. Mozilla doesn't allow anyone to call the browser
Firefox without some rules.


Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)


Red Hat want to run the tests because Java corporate users want
that, so Red Hat does it and at the same time helps to have a more
robust Java ecosystem.


That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.



All this change is about the burden of maintaining so many OpenJDK 
branches as packages in FEdora. Maybe Fedora should stop distributing 
ancient Java versions as one of our missions is to be cutting edge, 
maybe we are still encouraging too many projects to stay running on Java 8.


I am saying this as some that would be affected if Java 8 isn't packaged 
anymore, I still need to develop and test some things with Java 8 
because at work we have some customers still running ancient hardware 
and have been a pain to make them move to modern distributions. So I 
will have to us another universal OpenJDK build (like Temurin)


Maybe Fedora should just package the latest JDK needed for Android 
development and the latest LTS version. An even the Android (11 I think) 
could be skipped because Android Studio includes a build of it. If there 
are packages still requiring old things, help to update them could be 
offered by packagers, or dropped from the distribution.

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Richard W.M. Jones

On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote:
> On 6/1/23 3:51 AM, Richard W.M. Jones wrote:
> >On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:
> >>This was heavily discussed when we moved to portable build in rpms -
> >>https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> >>Long story short yes, if yo wish to distribute jdk *binary* it have
> >>to pass java compliance suite.
> >
> >It sounds like the problem is the software isn't really open source
> >because it has some field of use restrictions.  The best plan would be
> >to change this upstream, and if that isn't possible then to remove it
> >from Fedora.
> >
> >Rich.
> >
> 
> It is the same discussion about Firefox that is already settled I
> think. The JVM code is open source, even free software. The
> trademark isn't. Mozilla doesn't allow anyone to call the browser
> Firefox without some rules.

Both projects involve heavy-handed enforcement of trademarks, but
don't seem to be the same issue.  (I'll leave this to lawyers to
answer definitely though.)

> Red Hat want to run the tests because Java corporate users want
> that, so Red Hat does it and at the same time helps to have a more
> robust Java ecosystem.

That's nice, and indeed RHEL ships OpenJDK.  The question is about
what we do in Fedora.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Robert Marcano via devel


On 6/1/23 3:51 AM, Richard W.M. Jones wrote:

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:

This was heavily discussed when we moved to portable build in rpms -
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute jdk *binary* it have
to pass java compliance suite.


It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it
from Fedora.

Rich.



It is the same discussion about Firefox that is already settled I think. 
The JVM code is open source, even free software. The trademark isn't. 
Mozilla doesn't allow anyone to call the browser Firefox without some rules.


Red Hat want to run the tests because Java corporate users want that, so 
Red Hat does it and at the same time helps to have a more robust Java 
ecosystem.

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Kevin Kofler via devel

Jiri Vanek wrote:
> At elast providing ofjava/openjdk is definitley out of scope.

I do not think a Provides would be a trademark violation. It is a part of 
the standard procedure for renaming a package. But you would have to ask Red 
Hat Legal for a definite answer. I am not a lawyer.

That said, there might not even be a trademark issue at all, at least for 
"OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing 
to:
https://openjdk.org/legal/openjdk-trademark-notice.html

> As you wrote about the liberty of choice between temurins and fdeoara ona
> - can you be a bit more specific? Afaik if the builds are similar, we have
> mcuh less possibility of some fedora-specific bug.

But it also means that I no longer have the option to use a Java that does 
not bundle several libraries, possibly including security vulnerabilities, 
bloating its size, and likely reducing system integration (there have been 
concerns about, e.g., worse fontconfig integration in the discussion of your 
previous Change proposal). There is now just the "choice" between a Fedora 
package with everything bundled and third-party packages with also 
everything bundled.

> I once wrote,m that wworked 10years to enable dynamic linking, and yes,
> all is upstream, but there are limitations which can not be overtaken -
> major is ahead of tie comilation. If you can do it right, you cnanot have
> dyanmic linking.

Wait, Java does real AOT compilation now? Or are we talking about that 
strange "feature" you already brought up in the old discussion, where you 
basically just prepend a JRE to a JAR and ship that as a "compiled" 
executable? That "feature", to be honest, I had never heard of before you 
folks brought it up.

As far as I can tell, nobody in the Java world uses it. It breaks the "write 
once, run anywhere" promise and brings us no real advantage over having the 
JRE and the JAR separate.

It is definitely not useful for me because our customers all run Windows, 
not Fedora or any other GNU/Linux. So really it makes no difference for me 
whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking) 
or on all GNU/Linux (static linking), they will not run on our customers' 
computers anyway, making that "feature" entirely useless either way.

We have a few ways to deploy our JARs to our customers, but none of them 
involves turning them into native executables through (either real or fake 
as described above) AOT compilation.

> The goal should still be to have fedora rpms properly integrated in
> fedora, and usable, as any other java onthe world, without hacks.

Sorry, but I believe that the old packaging was exactly that, "properly 
integrated" and "without hacks", whereas I have to politely disagree about 
the new packaging having those properties.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


Hi Kevin!

I read all your posts.
You are mroevoer correct with everything, exept simple renaming of packages,. 
I'mnot sure it may work as strightforward. At elast providing ofjava/openjdk is 
definitley out of scope.
As you wrote about the liberty of choice between temurins and fdeoara ona - can 
you be a bit more specific? Afaik if the builds are similar, we have mcuh less 
possibility of some fedora-specific bug.
I once wrote,m that wworked 10years to enable dynamic linking, and yes, all is 
upstream, but there are limitations which can not be overtaken - major is ahead 
of tie comilation. If you can do it right, you cnanot have dyanmic linking.

The goal should still be to have fedora rpms properly integrated in fedora, and usable, as any other java onthe world, without hacks. I'm pretty confident that that is what wilbe dleivered at the end - that user will not find any 
regression, and willa ctually find soe things improved.



Thanx!!
  J.

On 6/1/23 05:41, Kevin Kofler via devel wrote:

Neal Gompa wrote:

Because the alternative is no Java runtime at all, and that's even
less acceptable.


I do not see why the way the packaging used to work all these years could
not be kept unchanged.

The only issues that were pointed out were related to the Java TCK (that it
takes too long to run on every build, and that sometimes system libraries
cause failures in some obscure test that are hard to debug), to which the
obvious answer is to just stop running it and call the package something
other than the current java-*-openjdk. (My understanding as a non-lawyer is
that it should be enough to change the package Name and the Summary and
%description. The java-*-openjdk name could still be Obsoleted/Provided, and
the binaries do not have to be renamed either.)

 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)




On 5/31/23 20:38, Mattia Verga via devel wrote:

Il 30/05/23 20:37, Aoife Moloney ha scritto:

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 the last step in
https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
effort. Jdks in fedora are already static, and we repack portable
tarball into rpms. Currently, the portbale tarball is built for each
Fedora and Epel version. Goal here is to build each jdk
(8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
repack in all live fedoras.


If I understand this correctly, this just means that java package built
on Fedora x-2 will be tagged also in Fedora x-1, Fedora x and Rawhide.
Am I correct?



No. I'm to scared to seal integration by building rpms once, and jsut retag. So 
we choosen middle way - to build once portable packages, which is build of 
openjdk, resulting to simply tar.xz.
That rpm with only tarball in it have no integration. You can unpack that 
anywhere and run its java.

This rpm with tarbll is build reqired by rpms, which just reapck its content to 
subpakcages as we were used until now. The portable rpm with tarball is what is 
going to be tagged to all fedoras. The integration rpms will reamin per-fedora.


If so, maybe the proposal needs a better wording rather than "repack in
all live fedoras", as that sounds like RPMs are "repacked" in some way,
but the truth is that the same RPM is made available in several Fedora
repositories.


so no :)

TY!


Mattia

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Richard W.M. Jones

On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote:
> This was heavily discussed when we moved to portable build in rpms -
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
> Long story short yes, if yo wish to distribute jdk *binary* it have
> to pass java compliance suite.

It sounds like the problem is the software isn't really open source
because it has some field of use restrictions.  The best plan would be
to change this upstream, and if that isn't possible then to remove it
from Fedora.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-06-01 Thread Neal Gompa

On Thu, Jun 1, 2023 at 6:18 AM Omair Majid  wrote:
>
> Hey,
>
> Neal Gompa  writes:
>
> > Keep in mind that this isn't exactly the first time we've done this
> > either: the .NET runtime is similarly screwy for its bootstrap
> > process, and that's split across a couple of source packages.
> >
> > At this point, we hold our noses and hope for the best. At least
> > there's a chance to reduce the pain with .NET over time as the Red Hat
> > .NET folks work to improve upstream. There's basically zero chance for
> > improvement with OpenJDK because of the nature of the upstream and how
> > old and crufty they are.
>
> I know it's tangential to the main discussion, but since .NET was called
> out by name, I would like to get your thoughts on this. What would you
> say are the biggest concerns with the .NET setup?
>
> Here's how I understand the current state. There's a single source
> package for each major version of .NET (dotnet6.0, dotnet7.0.). That
> source is compiled into the complete .NET SDK+Runtime for each version.
> There are no source or binary dependencies between versions. Each
> version is built/updated independently. Only the first build for each
> major version requires a full bootstrap (using prebuilt binaries), but
> that's a one time. Subsequent builds of each .NET major version use the
> previous build of that major version of .NET.
>
> With that context, what primary concerns do you think we should be
> focusing on?
>

That's actually a lot better than it was when I helped with dotnet
package review and bootstrap with 3.1.

The main worry I have is how we're going to be able to build dotnet
for a new architecture when nothing exists. RISC-V is the next big
architecture, but the build for that will be difficult.

It would also be good to have packaging guidelines for .NET
applications, since there's a number of server and desktop Linux apps
written in .NET languages that people would want to bring to Fedora.



--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Florian Weimer

* Jiri Vanek:

> This was heavily discussed when we moved to portable build in rpms - 
> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic

> Long story short yes, if yo wish to distribute jdk *binary* it have to
> pass java compliance suite. Thus, If I build different binary for all
> fedoras, aI have to ceritfy them all.

And I think it was pointed out that the standard terms do not require
any such testing:

  

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Omair Majid

Hey,

Neal Gompa  writes:

> Keep in mind that this isn't exactly the first time we've done this
> either: the .NET runtime is similarly screwy for its bootstrap
> process, and that's split across a couple of source packages.
>
> At this point, we hold our noses and hope for the best. At least
> there's a chance to reduce the pain with .NET over time as the Red Hat
> .NET folks work to improve upstream. There's basically zero chance for
> improvement with OpenJDK because of the nature of the upstream and how
> old and crufty they are.

I know it's tangential to the main discussion, but since .NET was called
out by name, I would like to get your thoughts on this. What would you
say are the biggest concerns with the .NET setup?

Here's how I understand the current state. There's a single source
package for each major version of .NET (dotnet6.0, dotnet7.0.). That
source is compiled into the complete .NET SDK+Runtime for each version.
There are no source or binary dependencies between versions. Each
version is built/updated independently. Only the first build for each
major version requires a full bootstrap (using prebuilt binaries), but
that's a one time. Subsequent builds of each .NET major version use the
previous build of that major version of .NET.

With that context, what primary concerns do you think we should be
focusing on?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Neal Gompa wrote:
> Because the alternative is no Java runtime at all, and that's even
> less acceptable.

I do not see why the way the packaging used to work all these years could 
not be kept unchanged.

The only issues that were pointed out were related to the Java TCK (that it 
takes too long to run on every build, and that sometimes system libraries 
cause failures in some obscure test that are hard to debug), to which the 
obvious answer is to just stop running it and call the package something 
other than the current java-*-openjdk. (My understanding as a non-lawyer is 
that it should be enough to change the package Name and the Summary and 
%description. The java-*-openjdk name could still be Obsoleted/Provided, and 
the binaries do not have to be renamed either.)

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Neal Gompa

On Thu, Jun 1, 2023 at 3:45 AM Kevin Kofler via devel
 wrote:
>
> Aoife Moloney wrote:
> > As described in
> > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> > during last year, packaging of JDKs had changed dramatically. As
> > described in same wiki page, and individual sub changes and devel
> > threads, with primary reason this - to lower maintenance and still
> > keep fedora java friendly.
>
> And these changes have made the Fedora Java packages basically useless,
> because there is really no advantage anymore to be had over just using,
> e.g., Adoptium builds. Your changes have removed the choice from users to
> choose between a Java built the upstream way (Adoptium and others) and a
> Java built according to the Fedora Packaging Guidelines as all Fedora
> packages are supposed to be (but yours no longer are).
>
> > * In first system wide change, we had changed JDKs to build properly
> > as standalone, portable jdk - the wey JDK is supposed to be built. I
> > repeat, we spent ten years by patching JDK to become properly dynamic
> > against system libs, and all patches went usptream, but it become
> > fight which can not be win
>
> This is already against the best practices recommended by the Fedora
> Packaging Guidelines, and arguably even against a mandatory rule (because
> you say all the patches allowing unbundling went upstream):
>
> https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/
>
> "All packages whose upstreams allow them to be built against system
> libraries must be built against system libraries."
>
> > * as a second step we introduced portable rpms, which do not have any
> > system integration, only builds JDK and pack final tarball in RPM for
> > free use.
> > * In third step - without any noise, just verified with fesco -
> > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> > integrated rpms. Instead of this, normal RPMS BUildRequire portable
> > rpms and just unpack it, and repack it.
>
> In short, you build an RPM containing a tarball instead of unpacked files,
> and then have the final RPM BR that intermediate RPM, untar the tarball, and
> repackage it. A really ugly hack that goes against any packaging best
> practices and maybe even subtly violates the letter of the Fedora Packaging
> Guidelines (it is definitely against the spirit).
>
> I do not understand why FESCo approved this hackery. It brings no advantages
> whatsoever to the user, it just makes the builds take longer overall for no
> good reason.
>

We approved it because realistically we'd rather have *some*
advantages of it being built by Fedora rather than none at all.
Because the alternative is no Java runtime at all, and that's even
less acceptable.

We're going to have to figure out how to ensure Fedora Java benefits
from new compilers and new build environment customizations, but at
least we're going to have OpenJDK in Fedora at all.

Keep in mind that this isn't exactly the first time we've done this
either: the .NET runtime is similarly screwy for its bootstrap
process, and that's split across a couple of source packages.

At this point, we hold our noses and hope for the best. At least
there's a chance to reduce the pain with .NET over time as the Red Hat
.NET folks work to improve upstream. There's basically zero chance for
improvement with OpenJDK because of the nature of the upstream and how
old and crufty they are.



--
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Peter Boy wrote:
> If you're serious about developing Java applications, you're not going to
> use an uncertified JDK to do it.

Huh? I develop Java applications for a living, and I could not care less 
about whether the build of OpenJDK I am running is JCK-certified and/or 
named "OpenJDK", as long as I do not notice any incompatibility in my actual 
work.

What I *do* care about is that the build is built and packaged the Fedora 
way, which is less and less the case for the OpenJDK packages.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Jiri Vanek wrote:
> Long story short yes, if yo wish to distribute  jdk *binary* it have to
> pass java compliance suite.

Only if you ship it as "Java" and/or "OpenJDK". If you ship it as, e.g., 
icedtea-11, nobody can force you to run the JCK.

(And the binary names "java" and "javac" are interfaces, so there is really 
no way they can prevent us from shipping executables, or at least symlinks, 
named that way.)

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Gerd Hoffmann wrote:
> The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
> see how that violates the 'build from source' requirement.

The plan is now to build the prebuilt RPMs on RHEL+EPEL instead of the 
current Fedora release, which means they would not be built from source on 
Fedora anymore, but on a commercial operating system (RHEL). That is 
unacceptable for a distribution that intends to be self-hosting.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

Aoife Moloney wrote:
> As described in
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ;
> during last year, packaging of JDKs had changed dramatically. As
> described in same wiki page, and individual sub changes and devel
> threads, with primary reason this - to lower maintenance and still
> keep fedora java friendly.

And these changes have made the Fedora Java packages basically useless, 
because there is really no advantage anymore to be had over just using, 
e.g., Adoptium builds. Your changes have removed the choice from users to 
choose between a Java built the upstream way (Adoptium and others) and a 
Java built according to the Fedora Packaging Guidelines as all Fedora 
packages are supposed to be (but yours no longer are).

> * In first system wide change, we had changed JDKs to build properly
> as standalone, portable jdk - the wey JDK is supposed to be built. I
> repeat, we spent ten years by patching JDK to become properly dynamic
> against system libs, and all patches went usptream, but it become
> fight which can not be win

This is already against the best practices recommended by the Fedora 
Packaging Guidelines, and arguably even against a mandatory rule (because 
you say all the patches allowing unbundling went upstream):

https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/

"All packages whose upstreams allow them to be built against system 
libraries must be built against system libraries."

> * as a second step we introduced portable rpms, which do not have any
> system integration, only builds JDK and pack final tarball in RPM for
> free use.
> * In third step - without any noise, just verified with fesco -
> https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully
> integrated rpms. Instead of this, normal RPMS BUildRequire portable
> rpms and just unpack it, and repack it.

In short, you build an RPM containing a tarball instead of unpacked files, 
and then have the final RPM BR that intermediate RPM, untar the tarball, and 
repackage it. A really ugly hack that goes against any packaging best 
practices and maybe even subtly violates the letter of the Fedora Packaging 
Guidelines (it is definitely against the spirit).

I do not understand why FESCo approved this hackery. It brings no advantages 
whatsoever to the user, it just makes the builds take longer overall for no 
good reason.

> Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> contains latest STS jdk - currently 20, soon briefly 21 and a bit
> alter 22... Should be built in latest live EPEL - epel8 now. We have
> verified, that such repacked JDKs work fine.

And that part is completely against Fedora Packaging Guidelines. Fedora does 
not allow repackaging binary blobs built on another distribution (and RHEL 
*is* another distribution). Such binary blobs can be used only for 
bootstrapping, which implies that they MUST be replaced with something built 
on the targeted Fedora release before reaching end users.

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Robert Marcano via devel


On 5/31/23 2:02 PM, Chris Adams wrote:

Once upon a time, Vitaly Zaitsev  said:

All program binaries and program libraries included in Fedora
packages must be built from the source code that is included in
the source package.


So... aside from making an exception in the guidelines, it'd also be
trivial to put the entire "real" source RPM into the "packaged" source
RPM, which would satisfy the letter of the rule.


Only if it builds on the Fedora release, an RPM that is build on EL8 
then repackaged as a Fedora RPM may not build on Fedora (New compiler 
for example) so it should still gets notifications about not building 
from source.




Honestly, that is probably the way it should be done anyway, as
otherwise the public mirrors would not have the source code, unless the
JDKs are packaged like shim (with shim-unsigned-x64 and
shim-unsigned-aarch64 SRPMs along side the shim SRPM with the signed
binaries).


___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Peter Boy

> Am 31.05.2023 um 20:27 schrieb Demi Marie Obenour :
> 
> On 5/31/23 13:08, Peter Boy wrote:
>> .. ..
>> Did you ever develop in Java? It doesn’t sound like you are even minimally 
>> familiar with Java. A little expertise would really be beneficial for devel 
>> mailing list. 
> 
> Can you explain please?

If you're serious about developing Java applications, you're not going to use 
an uncertified JDK to do it. Every customer uses a certified runtime and you 
must ensure to be compliant with it. And leaving OpenJDK is an even worse idea 
after all the efforts to keep OpenJDK as full OSS and emancipate it from Oracle 
governance. It's the best we have and what has been arduously fought for. So, 
OpenJDK is an asset for Fedora (and all the other distributions), thanks to the 
Fedora/Red Hat (or Red Hat / Fedora?) Java team. 

I don't quite yet overlook the practical implications of the proposal and am a 
little bit  uncomfortable. If Fedora X uses newer versions of gcc and various 
libraries than Fedora X-2 (or even Epel = Fedora X-(4+), I imagine that could 
get problematic.  

But if I understand the change proposal correctly, everything is already tested 
and working so far. And if there's ever a problem, hopefully we'll discover it 
in time in Rawhide and the Java team find a solution.   

--
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 and board member
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Mattia Verga via devel

Il 30/05/23 20:37, Aoife Moloney ha scritto:
> 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 the last step in
> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs
> effort. Jdks in fedora are already static, and we repack portable
> tarball into rpms. Currently, the portbale tarball is built for each
> Fedora and Epel version. Goal here is to build each jdk
> (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
> repack in all live fedoras.
>
If I understand this correctly, this just means that java package built 
on Fedora x-2 will be tagged also in Fedora x-1, Fedora x and Rawhide. 
Am I correct?

If so, maybe the proposal needs a better wording rather than "repack in 
all live fedoras", as that sounds like RPMs are "repacked" in some way, 
but the truth is that the same RPM is made available in several Fedora 
repositories.

Mattia

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Demi Marie Obenour

On 5/31/23 13:08, Peter Boy wrote:
> 
> 
>> Am 31.05.2023 um 18:52 schrieb Vitaly Zaitsev via devel 
>> :
>>
>> On 31/05/2023 17:02, David Schwörer wrote:
>>> Could you explain what certification means?
>>> It sounds like you run some very expensive tests, and building is actually 
>>> fast.
>>
>> You can't distribute any package named Java or OpenJDK unless it passes the 
>> Oracle test suite.
>>
>> I think Fedora should drop openjdk package and introduce a new one - 
>> coffee-named-language. Then we can get rid of any Oracle tests.
> 
> Did you ever develop in Java? It doesn't sound like you are even minimally 
> familiar with Java. A little expertise would really be beneficial for devel 
> mailing list. 

Can you explain please?
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On Wed, May 31, 2023 at 07:38:38PM +0200, Jiri Vanek wrote:
> > Can you clarify this a bit?  It sounds like some versions of the JDK in
> > Fedora will actually be built in EPEL.  I feel that all Fedora packages
> > should actually built for Fedora, not RHEL.
> >
> > Also, what exactly does "latest live EPEL" mean - how is 8 the latest?
> >
> > I guess basically, can you further explain/clarify exactly which
> > versions of what OS which JDKs will be built on, and when those versions
> > will change.
> 
> 
> Jdk is designed, to be severely forward comaptible from os where it was built.
> So jdk8, 11 and 17 would be build in oldest live fedora, and repacked
> everywhere. The idea is to build them on oldest viable system, as we
> can guarantee they will run ok in newer Fedroas..
> java-latest-openjdk however, is built also for epel8 and elep9. Thus
> logically the oldest system where we can built it to repack it everywhere
> is el8. Then it can be reapcked for el8,el9, and all live fedoras.

IIRC, RHEL-8 forked from Fedora in circa F28 timeframe. Directly
comparing RHEL-8 content to Fedora is a bit of a fools errand since
RHEL does rebase certain packages periodically, but a decent chunk
of RHEL-8 is 5 years old at this point. The most notable part is
the compiler toolchain on RHEL-8 is GCC 8.x, which is 5 major
releases behind what F39 rawhide uses, and 4 major release behind
what F37 uses.

RHEL-8 also has a long lifetime left, and thus so does EPEL8. By
building JDK on EPEL8, we're fixing the toolchain for JDK in Fedora
on a version already 5 years out of date, and by the time EPEL8 goes
away, the toolchain will be 10+ years out of date. 

By building JDK on the oldest stable Fedora release, we're fixing the
toolchain on a version that's never going to be much more then 1 year
out of date.

Same applies to compiler toolchain flags, though where the flags don't
depend on GCC version that can be partially mitigated in the JDK spec.

Overall, I find the idea of basing Fedora builds on oldest EPEL quite
challenging to accept, due to the age differences. It feels contrary
to Fedora goal of always being on, or at least very near, the cutting
edge. 

> I do not have hard requirement to build java-latest-openjdk on epel8 and
> repack everywhere, but it gave sense. If the hard demand will be to build
> also java-latest-opnejdk in oldest fedora, and repack in all fedoras, and
> built it in oldest epel, and repack in all epels, then it gave somehow
> sesnse too. Although I would conisdered it a bit wasted cycle, it is
> acceptable.

IMHO it'd be more palatable for the RHEL (EPEL) build stream to be separate
from the Fedora build stream. While RHEL and Fedora share heritage, they are
ultimately different distros with different goals and needs.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Chris Adams

Once upon a time, Vitaly Zaitsev  said:
> >All program binaries and program libraries included in Fedora
> >packages must be built from the source code that is included in
> >the source package.

So... aside from making an exception in the guidelines, it'd also be
trivial to put the entire "real" source RPM into the "packaged" source
RPM, which would satisfy the letter of the rule.

Honestly, that is probably the way it should be done anyway, as
otherwise the public mirrors would not have the source code, unless the
JDKs are packaged like shim (with shim-unsigned-x64 and
shim-unsigned-aarch64 SRPMs along side the shim SRPM with the signed
binaries).

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Chris Adams

Once upon a time, Jiri Vanek  said:
> I have fixed typo in the proposal " Should be built in oldest live EPEL" 
> instead of " Should be built in latest live EPEL", which was wrong.

At the moment though, the oldest live EPEL is 7, not 8.

> I do not have hard requirement to build java-latest-openjdk on epel8
> and repack everywhere, but it gave sense. If the hard demand will be
> to build also java-latest-opnejdk in oldest fedora, and repack in
> all fedoras, and built it in oldest epel, and repack in all epels,
> then it gave somehow sesnse too. Although I would conisdered it a
> bit wasted cycle, it is acceptable.

I think building for Fedora in Fedora would moderate the concerns about
old compiler/flags/etc., because the oldest Fedora at any point is about
a year old.  The oldest EPEL (7) is currently approaching 9 years old,
and even the oldest you listed (8) is 4 years old.

It would also help with reproducibility.  EPEL is built against RHEL,
which is not freely available (yes, there are rebuilds, there are free
limited developer licenses, etc., but it's not directly easy for someone
else to exactly reproduce the EPEL build environment).  That's okay for
EPEL builds, but I personally feel it would be more acceptable to build
Fedora packages on Fedora.

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


> That sounds like an effectively nonfree software. Users cannot build and
> distribute the binaries because the required tools are nonfree.

Not exactly. You can build it and use it freely. Unless you distribute it to 
others and call it java...

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


> This:
>
> ...
>  All program binaries and program libraries included in Fedora
> packages must be built from the source code that is included in the source 
package.
>
> Source:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...


https://pagure.io/fesco/issue/2907

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Stephen Gallagher

On Wed, May 31, 2023 at 12:50 PM Vitaly Zaitsev via devel
 wrote:
>
> On 31/05/2023 15:44, Gerd Hoffmann wrote:
> > We do similar things in other cases, see for example shim-unsigned.rpm +
> > shim.rpm
>
> Shim is a special case:
> 1. Shim need to be signed by Microsoft on their own infrastructure and
> this signature will be built directly into PE file.
> 2. Shim runs on UEFI, so it can use exception for firmware.
>
> > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
> > see how that violates the 'build from source' requirement.
>
> If the package uses prebuilt blobs (their origin is irrelevant), it
> violates current Fedora packaging guidelines.

To be clear, "current Fedora packaging guidelines" are not set in
stone. The existence of this Change implies that it would result in
the alteration of those guidelines. You keep using the existing
guidelines as a supporting argument that this should not be allowed.
If we can't change rules because the current rules exist... How do we
proceed at all?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On Wed, May 31, 2023 at 07:32:09PM +0200, Vitaly Zaitsev via devel wrote:
> On 31/05/2023 19:24, Daniel P. Berrangé wrote:
> > Can you point to the specific guideline that this violates ?  I know we've
> > always expected that apps are built from pristine upstream source, but I'm
> > not finding the specific guideline that describes this right now.
> 
> This:
> 
> > All program binaries and program libraries included in Fedora packages
> > must be built from the source code that is included in the source
> > package.
> 
> Source:
> 
> https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

So the important think there is the justification for why this policy
exists:

[quote]
This is a requirement for the following reasons:

Security: Pre-packaged program binaries and program libraries not built 
from the source code could contain parts that are malicious, dangerous, or just 
broken. Also, these are functionally impossible to patch.

Compiler Flags: Pre-packaged program binaries and program libraries not 
built from the source code were probably not compiled with standard Fedora 
compiler flags for security and optimization.
[/quote]

The proposal still satisfies the "Security" reasons. The also still
satisfies the "Compiler Flags" reason, albeit by using flags from an
earlier Fedora release. In any case, packages can already opt-out of
Fedora compiler flags at any time they wish.

Overall I'd say the JDK proposal still meets the spirit of the stated
guidelines and would be reasonable for FPC to approve as an exception.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


> Can you clarify this a bit?  It sounds like some versions of the JDK in
> Fedora will actually be built in EPEL.  I feel that all Fedora packages
> should actually built for Fedora, not RHEL.
>
> Also, what exactly does "latest live EPEL" mean - how is 8 the latest?
>
> I guess basically, can you further explain/clarify exactly which
> versions of what OS which JDKs will be built on, and when those versions
> will change.


Jdk is designed, to be severely forward comaptible from os where it was built.
So jdk8, 11 and 17 would be build in oldest live fedora, and repacked 
everywhere. The idea is to build them on oldest viable system, as we can 
guarantee they will run ok in newer Fedroas..
java-latest-openjdk however, is built also for epel8 and elep9. Thus logically 
the oldest system where we can built it to repack it everywhere is el8. Then it 
can be reapcked for el8,el9, and all live fedoras.

I have fixed typo in the proposal " Should be built in oldest live EPEL" instead of 
" Should be built in latest live EPEL", which was wrong.

I do not have hard requirement to build java-latest-openjdk on epel8 and repack everywhere, but it gave sense. If the hard demand will be to build also java-latest-opnejdk in oldest fedora, and repack in all fedoras, and built it in oldest 
epel, and repack in all epels, then it gave somehow sesnse too. Although I would conisdered it a bit wasted cycle, it is acceptable.



Thanx!

 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On Tue, May 30, 2023 at 04:31:01PM -0700, Kevin Fenzi wrote:
> So, the only way I can see to do this would be to have releng manually
> tag the builds from oldest release into newer ones each time they are
> built. I do not like this for a number of reasons:
> 
> * It's more manual work. 
> * It bypasses a bunch of our process. There wouldn't be any bodhi
> update, so no CI checks, no chance for karma, no updates-testing step
> (unless there's more work to retag a bunch of times).

The build in the oldstable branch can still use bodhi, go through
CI checks, get karma, etc. Once that's all satisfactorily passed,
it could then be tagged for the newer release(s). The fact that
we're shipping the exact same binary for both streams, static
linked, means must of that testing work for oldstable will remain
valid for newer branches too. Yes, it would loose some amount of
integration testing of the distro release differences, but the
use of static linking of its deps would partially mitigate this
downside.

Informally, people could grab the F37 update from bodhi and install
it on F38/rawhide to do that testing, it just wouldn't explicitly
tracked by bodhi as it wouldn't know what stream each person had
tested against. People who care about Java though have a vested
interest in doing such testing though. So mostly I think we loose
enforcement of the testing, but the actual level of testing is not
likely to be terribly different or have a negative impactful.

The level of testing of JDK is still going to be massively better
than most other packages in Fedora, by virtue of going through the
formal JDK certification test suite which is pretty comprehensive.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


On 31/05/2023 19:24, Daniel P. Berrangé wrote:

Can you point to the specific guideline that this violates ?  I know we've
always expected that apps are built from pristine upstream source, but I'm
not finding the specific guideline that describes this right now.


This:

All program binaries and program libraries included in Fedora packages must be built from the source code that is included in the source package. 


Source:

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Chris Adams

Once upon a time, Aoife Moloney  said:
> Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in
> oldest live Fedora, and repack everywhere. java-latest-openjdk, which
> contains latest STS jdk - currently 20, soon briefly 21 and a bit
> alter 22... Should be built in latest live EPEL - epel8 now. We have
> verified, that such repacked JDKs work fine.

Can you clarify this a bit?  It sounds like some versions of the JDK in
Fedora will actually be built in EPEL.  I feel that all Fedora packages
should actually built for Fedora, not RHEL.

Also, what exactly does "latest live EPEL" mean - how is 8 the latest?

I guess basically, can you further explain/clarify exactly which
versions of what OS which JDKs will be built on, and when those versions
will change.

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On Wed, May 31, 2023 at 06:48:37PM +0200, Vitaly Zaitsev via devel wrote:
> On 31/05/2023 15:44, Gerd Hoffmann wrote:
> > We do similar things in other cases, see for example shim-unsigned.rpm +
> > shim.rpm
> 
> Shim is a special case:
> 1. Shim need to be signed by Microsoft on their own infrastructure and this
> signature will be built directly into PE file.
> 2. Shim runs on UEFI, so it can use exception for firmware.
> 
> > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
> > see how that violates the 'build from source' requirement.
> 
> If the package uses prebuilt blobs (their origin is irrelevant), it violates
> current Fedora packaging guidelines.

Can you point to the specific guideline that this violates ?  I know we've
always expected that apps are built from pristine upstream source, but I'm
not finding the specific guideline that describes this right now.

There *is* absolutely a difference between using a pre-built blob provided
by a 3rd party, vs using a pre-built blob obtained from a previous Fedora
RPM build.

The purpose of Fedora building from pristine source is to ensure that the
binary we distribute actually matches the source we distribute, which is
important for licensing compliance and also should we ever need to rebuild
later to patch the RPM we want confidence we can do so. Using a pre-built
blob from a 3rd party can't satisfy our goals in this respect. Using a
pre-built blob from a previous Fedora build absolutey *can* satisfy our
needs. In fact we do this all the time - when we build cloud images or
containers we are using pre-built blobs from a previous Fedora build
process.

What is proposed for the JDK is definitely a new scenario for Fedora,
but we will still be able to satisfy our needs to trace a binary back
to its pristine source. That critical traceability aspect is preserved.
Thus I do NOT see this proposal as fundamentally unsound from a packaging
POV, merely different and unusual.

Finally the Fedora packaging guidelines are guidelines, not rules:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_general_exception_policy

 "As these guidelines can never cover all possible contingencies, there
  will always be packages which need exception."

In the worst case the exception would require approval of FPC, and that
is what this change proposal ultimately seeks to attain, which is good.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Kevin Fenzi

On Wed, May 31, 2023 at 08:25:23AM +0200, Miro Hrončok wrote:
> On 31. 05. 23 1:31, Kevin Fenzi wrote:
> > So, the only way I can see to do this would be to have releng manually
> > tag the builds from oldest release into newer ones each time they are
> > built. I do not like this for a number of reasons:
> > 
> > * It's more manual work.
> > * It bypasses a bunch of our process. There wouldn't be any bodhi
> > update, so no CI checks, no chance for karma, no updates-testing step
> > (unless there's more work to retag a bunch of times).
> > 
> > I'm open to other ideas, but as it is I'm not liking this change.
> 
> If we never actually ship the "build once" builds, and only ship the "repack
> everywhere" ones, this could be achieved by the maintaines:
> 
>  1. request side tags for all releases
>  2. build the actual Java in the side tag for the oldest thing
>  3. tag the result ot (2) to all side tags from (1)
>  4. waitrepo them
>  5. build the repacked java packages in all the side tags from (1)
>  6. untag the result of (2) from all the side tags from (1)
>  7. ship bodhi updates from side tags OR retag the builds to candidate tags
> (and delete the side tags)

Yep. Thats a much better flow/plan. :)
 
> The build from (2) will be eventually garbage collected. To prevent that, it
> might be re-tagged regularly. This is where releng might be able to help by
> creating a long lived tag to tag this into for preserving.

Yes, we could make a 'fN-openjdk' tag and mark it protected... that part
would be easy enough. 

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Peter Boy



> Am 31.05.2023 um 18:52 schrieb Vitaly Zaitsev via devel 
> :
> 
> On 31/05/2023 17:02, David Schwörer wrote:
>> Could you explain what certification means?
>> It sounds like you run some very expensive tests, and building is actually 
>> fast.
> 
> You can't distribute any package named Java or OpenJDK unless it passes the 
> Oracle test suite.
> 
> I think Fedora should drop openjdk package and introduce a new one - 
> coffee-named-language. Then we can get rid of any Oracle tests.

Did you ever develop in Java? It doesn't sound like you are even minimally 
familiar with Java. A little expertise would really be beneficial for devel 
mailing list. 




 


--
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 and board member
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


On 31/05/2023 17:02, David Schwörer wrote:

Could you explain what certification means?
It sounds like you run some very expensive tests, and building is actually fast.


You can't distribute any package named Java or OpenJDK unless it passes 
the Oracle test suite.


I think Fedora should drop openjdk package and introduce a new one - 
coffee-named-language. Then we can get rid of any Oracle tests.


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


On 31/05/2023 15:44, Gerd Hoffmann wrote:

We do similar things in other cases, see for example shim-unsigned.rpm +
shim.rpm


Shim is a special case:
1. Shim need to be signed by Microsoft on their own infrastructure and 
this signature will be built directly into PE file.

2. Shim runs on UEFI, so it can use exception for firmware.


The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
see how that violates the 'build from source' requirement.


If the package uses prebuilt blobs (their origin is irrelevant), it 
violates current Fedora packaging guidelines.


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Petr Pisar

V Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek napsal(a):
> Long story short yes, if yo wish to distribute jdk *binary* it have to pass
> java compliance suite.
[...]
> In addition, this  kit complicne tests are proprietary, close source and
> licensed.

That sounds like an effectively nonfree software. Users cannot build and
distribute the binaries because the required tools are nonfree.

I guess lawyers spent a plenty of their time on crafting a license like this.
Thus I do not want you to comment on this matter. Though I appreciate that you
articualated the reason openly and clearly.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)




On 5/31/23 17:02, David Schwörer wrote:

== Benefit to Fedora ==

java maintainers will finally some free time... No kidding -
maintenance and *certification* of  so much supported JDKs on so much
Fedora versions is  brutal.  By building once, and repack, we will
regain cycles to continue support Fedora with all LTS and one STS
javas.


Could you explain what certification means?
It sounds like you run some very expensive tests, and building is actually fast.

Would it not be much nicer to just skip the tests in that case and only run in 
the oldest version?
That seems like it would give you most of the benefits, and still allow to get 
e.g. newest flags as well as allowing users to easily rebuild from source.


This was heavily discussed when we moved to portable build in rpms - 
https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic
Long story short yes, if yo wish to distribute  jdk *binary* it have to pass 
java compliance suite. Thus, If I build different binary for all fedoras, aI 
have to ceritfy them all.
If I built it only once, and repack, then I need to run it only once, on any 
system. So buildsysemmetters,not runtimeone.
The compatibility kit takes 24h+ per platform and jdk version. And includes several 
manual steps. You can workaroudn them ssomehow, but you must be sure they will pass if 
run "properly".
In addition, this  kit complicne tests are proprietary, close source and 
licensed.
Next to that we in RH runs much more tests, and we are no going tostop running 
them on newer fedoras, but to not run only 1/3 of jck mandatory, would be heavy 
relieve.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On 5/31/23 16:25, Robert Marcano via devel wrote:

On 5/31/23 9:44 AM, Gerd Hoffmann wrote:

On Wed, May 31, 2023 at 03:32:09PM +0200, Vitaly Zaitsev via devel wrote:

On 31/05/2023 14:53, Jiri Vanek wrote:

It is built from sources of course!
What make you think it is not?
For double ensurenes, see the fesco ticket in proposal.

IMO, repackaging prebuilt RPM packages is not building from sources.

The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
see how that violates the 'build from source' requirement.

We do similar things in other cases, see for example shim-unsigned.rpm +
shim.rpm

Will user be able to download SRPMS like

dnf download --source java...

and get a real source RPM that can be rebuilt or the SRPM will have a prebuilt tarball and the user will need to hunt down the real SRPM, and do things like using a VM or container to built that, for later rebuild the "binray" SRPM from the
Fedora repos?

Thats good question. User should be able to do that. I consider srpm rebuild
and investigations of what is built as crucial.
Right now, where we build portables for each fedora and repack them for rpms,
it is possible wihtout issues (feedback welcomed).

With build once and repack everywhere, the solution will be hidden in all that
tagging.
Tbh, I would consider permanent block of this feature, as show stopper for tis
proposal.
Will add it to the how to test section,

take care,
Gerd

___
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, report it:
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread David Schwörer

> == Benefit to Fedora ==
> 
> java maintainers will finally some free time... No kidding -
> maintenance and *certification* of  so much supported JDKs on so much
> Fedora versions is  brutal.  By building once, and repack, we will
> regain cycles to continue support Fedora with all LTS and one STS
> javas.

Could you explain what certification means?
It sounds like you run some very expensive tests, and building is actually fast.

Would it not be much nicer to just skip the tests in that case and only run in 
the oldest version?
That seems like it would give you most of the benefits, and still allow to get 
e.g. newest flags as well as allowing users to easily rebuild from source.
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Robert Marcano via devel


On 5/31/23 9:44 AM, Gerd Hoffmann wrote:

On Wed, May 31, 2023 at 03:32:09PM +0200, Vitaly Zaitsev via devel wrote:

On 31/05/2023 14:53, Jiri Vanek wrote:

It is built from sources of course!
What make you think it is not?
For double ensurenes, see the fesco ticket in proposal.


IMO, repackaging prebuilt RPM packages is not building from sources.


The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
see how that violates the 'build from source' requirement.

We do similar things in other cases, see for example shim-unsigned.rpm +
shim.rpm


Will user be able to download SRPMS like

  dnf download --source java...

and get a real source RPM that can be rebuilt or the SRPM will have a 
prebuilt tarball and the user will need to hunt down the real SRPM, and 
do things like using a VM or container to built that, for later rebuild 
the "binray" SRPM from the Fedora repos?




take care,
   Gerd

___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Gerd Hoffmann

On Wed, May 31, 2023 at 03:32:09PM +0200, Vitaly Zaitsev via devel wrote:
> On 31/05/2023 14:53, Jiri Vanek wrote:
> > It is built from sources of course!
> > What make you think it is not?
> > For double ensurenes, see the fesco ticket in proposal.
> 
> IMO, repackaging prebuilt RPM packages is not building from sources.

The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't
see how that violates the 'build from source' requirement.

We do similar things in other cases, see for example shim-unsigned.rpm +
shim.rpm

take care,
  Gerd
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


On 31/05/2023 14:53, Jiri Vanek wrote:

It is built from sources of course!
What make you think it is not?
For double ensurenes, see the fesco ticket in proposal.


IMO, repackaging prebuilt RPM packages is not building from sources.

--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)




On 5/31/23 13:43, Fabio Valentini wrote:

On Wed, May 31, 2023 at 1:31 AM Kevin Fenzi  wrote:


So, the only way I can see to do this would be to have releng manually
tag the builds from oldest release into newer ones each time they are
built. I do not like this for a number of reasons:

* It's more manual work.
* It bypasses a bunch of our process. There wouldn't be any bodhi
update, so no CI checks, no chance for karma, no updates-testing step
(unless there's more work to retag a bunch of times).


There's also more problems:
This approach would basically opt OpenJDK out of all System-Wide
changes, like GCC updates, compiler flag changes, etc. (at least until
"Fedora oldstable" catches up to those changes 12 months later).


This is dual-edge blade
 - First of all, I would like to keep building portable tarballs aslo in 
rawhide, just and only because I would like to know impacts of new gcc and new 
flags
 -- the new gcc is actually very interesting issue. Thanx to it, we found many 
issues in jdk, which would otherwise left undetected for mcuh longer. 
Unluckily, some of them were fasle negatives, which made us super torubled.\
 -- The koji build flags are on contrary something, what is troubeling us a 
lot, and to be abel tobuild jdk, we have to exclude most of them.

So to skip those, have really very strong both pros and cons. Still Iw ould 
vote to keep building portables also in rawhide, even if the regular rpms in 
reawhide will keep repaking portbales from oldest live fedora.


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue


--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Neal Gompa

On Wed, May 31, 2023 at 1:44 PM Fabio Valentini  wrote:
>
> On Wed, May 31, 2023 at 1:31 AM Kevin Fenzi  wrote:
> >
> > So, the only way I can see to do this would be to have releng manually
> > tag the builds from oldest release into newer ones each time they are
> > built. I do not like this for a number of reasons:
> >
> > * It's more manual work.
> > * It bypasses a bunch of our process. There wouldn't be any bodhi
> > update, so no CI checks, no chance for karma, no updates-testing step
> > (unless there's more work to retag a bunch of times).
>
> There's also more problems:
> This approach would basically opt OpenJDK out of all System-Wide
> changes, like GCC updates, compiler flag changes, etc. (at least until
> "Fedora oldstable" catches up to those changes 12 months later).
>

This is actually the biggest problem with it. Having packages
implicitly automatically opted out of virtually every single System
Wide Change seriously sucks.




--
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

On 5/31/23 08:25, Miro Hrončok wrote:

On 31. 05. 23 1:31, Kevin Fenzi wrote:

So, the only way I can see to do this would be to have releng manually
tag the builds from oldest release into newer ones each time they are
built. I do not like this for a number of reasons:

* It's more manual work.

If it should be more manual work then to run 24hours long java certification
per fedora build, then it is indeed no go.
Still, if it would mean more work for other people then maintainers of openjdk, then it is Again -1. I would like to avodi any non-java-maint interventions as it is unfair to them, and slowing the repack dramatically (so uch tha tit may be
faster to keeprunning all the certifications)

* It bypasses a bunch of our process. There wouldn't be any bodhi
update, so no CI checks, no chance for karma, no updates-testing step
(unless there's more work to retag a bunch of times).

I'm open to other ideas, but as it is I'm not liking this change.

If we never actually ship the "build once" builds, and only ship the "repack
everywhere" ones, this could be achieved by the maintaines:

1. request side tags for all releases
2. build the actual Java in the side tag for the oldest thing
3. tag the result ot (2) to all side tags from (1)
4. waitrepo them
5. build the repacked java packages in all the side tags from (1)
6. untag the result of (2) from all the side tags from (1)
7. ship bodhi updates from side tags OR retag the builds to candidate tags
(and delete the side tags)

The build from (2) will be eventually garbage collected. To prevent that, it
might be re-tagged regularly. This is where releng might be able to help by
creating a long lived tag to tag this into for preserving.

Thanx a lot for writing this down. It is still a bti hard hard to grab that.

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)


It is built from sources of course!
What make you think it is not?
For double ensurenes, see the fesco ticket in proposal.

Thanx!

J.


On 5/31/23 11:59, Vitaly Zaitsev via devel wrote:

On 30/05/2023 20:37, Aoife Moloney wrote:

  Jdks in fedora are already static, and we repack portable
tarball into rpms. Currently, the portbale tarball is built for each
Fedora and Epel version. Goal here is to build each jdk
(8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and
repack in all live fedoras.


All Fedora packages must be built from sources (except linux-firmware package 
of course).



--
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)

2023-05-31 Thread Fabio Valentini

On Wed, May 31, 2023 at 1:31 AM Kevin Fenzi  wrote:
>
> So, the only way I can see to do this would be to have releng manually
> tag the builds from oldest release into newer ones each time they are
> built. I do not like this for a number of reasons:
>
> * It's more manual work.
> * It bypasses a bunch of our process. There wouldn't be any bodhi
> update, so no CI checks, no chance for karma, no updates-testing step
> (unless there's more work to retag a bunch of times).

There's also more problems:
This approach would basically opt OpenJDK out of all System-Wide
changes, like GCC updates, compiler flag changes, etc. (at least until
"Fedora oldstable" catches up to those changes 12 months later).

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide Change)