Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 11:48 AM, Severin Gehwolf wrote: On Thu, 2015-02-26 at 15:46 +0100, Mikolaj Izdebski wrote: On 02/26/2015 02:46 PM, Jiri Vanek wrote: On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote: On 02/26/2015 09:23 AM, Jiri Vanek wrote: On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote: On 02/26/2015 08:42 AM, Jiri Vanek wrote: Also, my proposal of introducing "java" metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the issues via some metapackage. At the end I gave up, because the touch of user was always necessary. I described it in much detail in other posts in this thread (for example message-ID 54eca102.1070...@redhat.com) Yah. Sorry. I walked across it later then replied this. However - I'm not convinced that metapackage will work as expected. If Still the metapackge's correct dependence have to be someones responsibility. Will you be able to take this burden? Sure, I can create and maintain metapackage. (In this case it would probably be subpackage of javapackages-tools.) nothing else it will need some changes in current infrastructure which I wonted to avoid. It works exactly how I described it. Old JDK won't be removed during Is it really wonted? If so, we can skip the "option one" and continue with with option two. If you really think that old JDK should be removed during update and insist on that then there is still a way to achieve that with versioned obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk* < e:v-(r+1), where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was considered as "main JDK". I've just tested it and it works, see below. Lets start with JDK 7 installed. sh-4.3# rpm -qa | grep java java-1.7.0-1.fc23.x86_64 java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 Update installs JDK 8 and erases JDK 7. sh-4.3# dnf -y update Using metadata from Thu Feb 26 15:37:47 2015 Dependencies resolved. Nothing to do. sh-4.3# rm -rf /var/cache/dnf/ sh-4.3# rm -rf rpm sh-4.3# dnf -y update rpm 966 kB/s | 1.3 kB 00:00 Using metadata from Thu Feb 26 15:38:06 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.8.0-openjdk x86_64 666:1.8.0-1.fc23 rpm 5.6 k Upgrading: java x86_64 666:1.8.0-1.fc23 rpm 5.7 k replacing java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23 Transaction Summary Install 1 Package Upgrade 1 Package Total size: 11 k Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/4 Upgrading : java-666:1.8.0-1.fc23.x86_642/4 Cleanup : java-666:1.7.0-1.fc23.x86_643/4 Obsoleting : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 4/4 Verifying : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/4 Verifying : java-666:1.8.0-1.fc23.x86_642/4 Verifying : java-666:1.7.0-1.fc23.x86_643/4 Verifying : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 4/4 Installed: java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23 Upgraded: java.x86_64 666:1.8.0-1.fc23 Complete! After update only JDK 8 is installed: sh-4.3# rpm -qa | grep java java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 java-1.8.0-1.fc23.x86_64 But user can still install JDK 7: sh-4.3# dnf install -y java-1.7.0-openjdk Using metadata from Thu Feb 26 15:38:06 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.7.0-openjdk x86_64 666:1.7.0-2.fc23 rpm 5.7 k Transaction Summary Install 1 Package Total size: 5.7 k Installed size: 0 Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6 1/1 Verifying : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6 1/1 Installed: java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23 Complete! JDK 7 and 8 can coexist without any problem: sh-4.3# rpm -qa | grep java java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 jav
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote: - Original Message - From: "Jiri Vanek" To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 11:43:53 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and "Legacy JDKs in Fedora guidelines" pages ___ Small restart. Looking to the discussion, although many people claimed "against any rules" at the end it seems to me that everybody agree on "some rules" - even if it would be existence of metapa
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 11:58 AM, Aleksandar Kurtakov wrote: - Original Message - From: "Jiri Vanek" To: "Development discussions related to Fedora" Sent: Friday, February 27, 2015 12:54:04 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote: - Original Message - From: "Jiri Vanek" To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 11:43:53 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may spl
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 12:04 PM, Andrew Haley wrote: On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote: If we want to be sure that this legacy jdk will not interfere with the system JDK let it not provide anything via alternatives. That way people that want it can use it by playing with PATH/JAVA_HOME (just like they do with other JVMs). That's right. In that case, to add another rule - " 8) all alternatives bindings must be removed" - must be added. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 12:57 PM, Aleksandar Kurtakov wrote: Shouldn't this one replace 3). As if there are no alternatives, priorities are meaningless. Sound good. J. Alexander Kurtakov Red Hat Eclipse team - Original Message - From: "Jiri Vanek" To: devel@lists.fedoraproject.org Sent: Friday, February 27, 2015 1:42:53 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/27/2015 12:04 PM, Andrew Haley wrote: On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote: If we want to be sure that this legacy jdk will not interfere with the system JDK let it not provide anything via alternatives. That way people that want it can use it by playing with PATH/JAVA_HOME (just like they do with other JVMs). That's right. In that case, to add another rule - " 8) all alternatives bindings must be removed" - must be added. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/27/2015 12:04 PM, Andrew Haley wrote: On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote: If we want to be sure that this legacy jdk will not interfere with the system JDK let it not provide anything via alternatives. That way people that want it can use it by playing with PATH/JAVA_HOME (just like they do with other JVMs). That's right. One more thing - I'm not sure what everything may break by doing so (dangling symlinks or similar issues in the package). J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 02:54 PM, Miloslav Trmač wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora == Detailed Description == This is no real work proposal. Stepping back, I’m not sure this has been said explicitly: this is really a packaging guideline proposal, not really a Change, so it should probably go through the FPC. (https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Guideline_Change_Procedure ) (This is not intended to kill or affect the implementation details discussion at all. I’m just trying to minimize the bureaucracy (hah!) by not setting a precedent for doing it this way, so that all future packaging guideline proposals go directly to the FPC and skip this redirection step.) Mirek This proposal had been withdraw until real legacy JDK maintainer is found. https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: review swap
On 06/16/2015 05:16 PM, gil wrote: hi I'm working for upgrade springframework-batch (spring-batch) [1]. There are still some packages under review: https://bugzilla.redhat.com/show_bug.cgi?id=1228203 https://bugzilla.redhat.com/show_bug.cgi?id=1228503 https://bugzilla.redhat.com/show_bug.cgi?id=1228146 https://bugzilla.redhat.com/show_bug.cgi?id=1228169 https://bugzilla.redhat.com/show_bug.cgi?id=1228172 https://bugzilla.redhat.com/show_bug.cgi?id=1231951 https://bugzilla.redhat.com/show_bug.cgi?id=1231953 If you can handle that, give me some reviews to do for you in exchange for these. Thanks in advance. gil [1] https://bugzilla.redhat.com/show_bug.cgi?id=1215061 I will take lettuce as begining. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning jasperreports
On 06/22/2015 02:56 PM, gil wrote: HI I have intention to orphaning/retire jasperreports [1] , because it fails build [2] with new batik (1.8) and newer release use non free itext 5.x library. [1] https://admin.fedoraproject.org/pkgdb/package/jasperreports/ [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=10098415 cant it be kept alive with older working batik-compact ? J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
500 packages FTBFS in rawhide with java-11-openjdk as system JDK
stringtemplate stringtemplate4 mkoncekapache-commons-compress mlichvar libidn mmahut octave mmorsi bytelist invokebinder jcodings jffi jnr-constants jnr-ffi jnr-netdb jnr-posix jnr-x86asm joni jvyamlb nailgun snakeyaml mmuzilalibdb4 moceap apache-log4j-extras gnulib jaxodraw kawa netbeans-resolver mpaladin java-dirq mrceresa vtk mrunge lcm syslog-ng mschormmysql-connector-java msimacek felix-framework jline lucene maven-scm xstream msrb jruby msuchy abrt-java-connector mycae flexdock skinlf nathansparfait si-units uom-lib uom-se uom-systems neugenspowermock ngompa jsemver nmarques lcm odubaj mysql-connector-java oliver eclipse omajid ecj mockito orion ant-antunit guessencoding java-sleep javatar jilter octave vtk orphan apache-commons-dbutils apache-commons-email apache-commons-jci apache-commons-jcs apache-commons-vfs avalon-framework bval cassandra-java-driver castor eclipse-mylyn eclipse-webtools felix-framework felix-osgi-obr-resolver geronimo-jcache geronimo-jcdi-1.0-api glassfish-annotation-api glassfish-dtd-parser glassfish-hk2 gluegen2 guava20 invokebinder java-vash javolution jboss-jsf-2.2-api jchart2d jetty-parent jlatexmath jline3 josm jruby js-zlib maven-release maven-stage-plugin metrics-reporter-config mx4j mycila-pom nyquist openjpa parfait plexus-bsh-factory rescu scilab si-units sslext stream-lib struts svnkit uom-lib uom-se uom-systems velocity-tools patchesjs-zlib pbrobinson csound pcpa jacop peter erlang-corba pfrankli tzdata pingou maven-resources-plugin maven-shade-plugin pkajabajava-comment-preprocessor pkubat libdb pmachata tzdata pmackinn javolution jython pmikovajava-runtime-decompiler pmuldoon frysk praiskup java-comment-preprocessor ongres-scram rakesh octave raphgromockito py4j python-jep umlgraph rathannvecmath rcritten lasso rgrunber bouncycastle cbi-plugins docker-client-java eclipse eclipse-mylyn jnr-enxio jnr-unixsocket lucene richardfearn findbugs rkennkemockito powermock rlandmann fop xmlgraphics-commons sbergmann libloader librepository sbonazzo ebay-cors-filter sdgathman apache-commons-io apache-commons-lang3 apache-commons-logging dom4j httpcomponents-client httpcomponents-core javamail openas2 sdzcsound sergiomb batik opencv pdfbox simo lasso spike apache-commons-beanutils apache-commons-cli apache-commons-compress apache-commons-configuration apache-commons-daemon apache-commons-dbcp apache-commons-fileupload apache-commons-io apache-commons-jxpath apache-commons-lang apache-commons-logging apache-commons-math apache-commons-modeler apache-commons-net apache-commons-pool apache-commons-validator geronimo-annotation geronimo-ejb geronimo-interceptor geronimo-jaxrpc geronimo-osgi-support geronimo-saaj joda-time jtidy rmic-maven-plugin spot antlr-maven-plugin freewrl stevetraylen freewrl java-dirq json_simple xemacs-packages-extra tc01 legendsbrowser msv reflections terjeros ditaa jericho-html vakwetujboss-servlet-2.5-api resteasy tomcatjss vcrhonek sblim-cim-client sblim-cim-client2 verdurin imagej vjancikopencv vtrefnyfreecol waltersantlr3 stringtemplate willb fmpp lancer sbinary scalacheck yyang maven-plugin-testing maven-plugin-tools maven-wagon maven2 modello plexus-active-collections plexus-component-api plexus-containers zbyszekclosure-compiler diffoscope gnulib hdfview jblas jhdf5 js-zlib neurord nom-tam-fits Thanx! J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] 500 packages FTBFS in rawhide with java-11-openjdk as system JDK
On 6/9/20 4:42 PM, Aleksandar Kurtakov wrote: > Hey Jiri, > Please guide me how to find the actual build failure log. I tried finding the > ant one but didn't > succeed yet > https://copr.fedorainfracloud.org/coprs/jvanek/java11/package/ant/ Hi! I think I'm not guilty. it looks like fedora infra is dead just in this moment. I hoep Ihave not killed it by this email:( I was now working on few pakcxages of mine, and: rsyntaxtextarea master ⬆ $ git push Error during lookup request: status: 503 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. And Also https://koji.fedoraproject.org/koji/ returns: Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache Server at koji.fedoraproject.org Port 443 And looking to https://src.fedoraproject.org/rpms/rsyntaxtextarea/tree/master : Sorry! This service is currently unavailable. The service that you are trying to access is currently unavailable. Please try refreshing this page in a couple of minutes. If you still see this message, then please follow the steps below: Check on the status page if there are any known outages for our services. Check the fedora-infrastructure pagure instance for an outage notification. Ask around in #fedora-admin on irc.freenode.net. If it is accessible, check the Outage SOP for more information. Very bad timing:( I hope it will get fixed asap. I'm really sorry for troubles! J. > > On Tue, Jun 9, 2020 at 5:05 PM Jiri Vanek <mailto:jva...@redhat.com>> wrote: > > > > Please see > > https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions > Please fix your packages according to > https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild > Inidivdual packagers are being emailed with details > > Maintainers by package: > HdrHistogram acaringi almac hhorak jkang jvanek > Java-WebSocket jonny > abrt-java-connector ekulik jfilak mhabrnal mizdebsk msuchy > ant akurtakov dmoluguw jcapik kdaniel mizdebsk > ant-antunit dmoluguw mizdebsk orion > antlr-maven-plugin lef spot > antlr3 dchen jjames lef mizdebsk mjakubicek walters > antlr32 mbooth > antlrworks melmorabity > apache-commons-beanutils churchyard fnasser mizdebsk spike > apache-commons-chain jjelen > apache-commons-cli mizdebsk spike > apache-commons-codec mbooth mizdebsk > apache-commons-collections churchyard jcapik mizdebsk > apache-commons-compress jjelen mizdebsk mkoncek spike > apache-commons-configuration fnasser jjelen mizdebsk spike > apache-commons-daemon dmoluguw mizdebsk spike > apache-commons-dbcp mizdebsk spike > apache-commons-dbutils mizdebsk orphan > apache-commons-digester mbooth mizdebsk > apache-commons-email mizdebsk orphan > apache-commons-exec melmorabity > apache-commons-fileupload jerboaa jjelen mizdebsk spike > apache-commons-io mizdebsk sdgathman spike > apache-commons-jci jjelen orphan > apache-commons-jcs cquad jjelen orphan > apache-commons-jxpath churchyard fnasser mizdebsk spike > apache-commons-lang dmoluguw mizdebsk spike > apache-commons-lang3 mizdebsk sdgathman > apache-commons-logging kdaniel mizdebsk sdgathman spike > apache-commons-math melmorabity spike > apache-commons-modeler mizdebsk spike > apache-commons-net blackfile mizdebsk spike > apache-commons-pool mizdebsk spike > apache-commons-validator mizdebsk spike > apache-commons-vfs mizdebsk orphan > apache-ivy jjelen mizdebsk > apache-log4j-extras coolsvap gil moceap > apache-rat jjelen mizdebsk > apache-sshd gil mbooth > apiviz dmoluguw lef > aqute-bnd churchyard jcapik mizdebsk > args4j churchyard jcapik mizdebsk > assertj-core decathorpe > atinject churchyard kdaniel mizdebsk > auto mbooth > avalon-framework jerboaa jjelen mizdebsk orphan > azureus djuran > batik jvanek mbooth mizdebsk sergiomb > bcel jjelen mizdebsk > beust-jcommander churchyard jcapik jvanek mizdebsk > bouncycastle ellert gil jjohnstn mbooth rgrunber > brazil mbooth > bsf choeger decathorpe mizdebsk > bsh churchyard mizdebsk > buildnumber-maven-plugin jjelen >
Re: 500 packages FTBFS in rawhide with java-11-openjdk as system JDK
On 6/9/20 5:07 PM, Fabio Valentini wrote: > On Tue, Jun 9, 2020 at 4:52 PM Fabio Valentini wrote: >> >> On Tue, Jun 9, 2020 at 4:05 PM Jiri Vanek wrote: >>> Please see >>> https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions >>> Please fix your packages according to >>> https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild >>> Inidivdual packagers are being emailed with details >> >> I've asked mizdebsk whether he thinks we can switch to using >> xmvn-javadoc, which solves the majority of those build failures (over >> half, by my count). >> I also sent this proposal to the devel and java-devel mailing lists, >> and there was no opposition to the change. >> >> For other failures, I've begun to track "EasyFix" solutions (mostly, >> overriding -source 1.8 and -target 1.8, as suggested in the Change >> proposal), and I've started to either push this change directly (for >> packages I am associated with), or filing Pull Requests for them: >> https://pagure.io/java-maint-sig/issue/1 >> >> However, I am only one man, with only so much time, so without help, >> this "applying EasyFixes" will still take a while. >> >> With both changes (switching from maven-javadoc-plugin to >> xmvn-javadoc, and applying the -source / -target 1.8 EasyFixes), the >> number of build failures should be lower than 100, not over 500. >> That's still a big number of broken packages, but it's *much* more >> manageable. I had missed any coordinated effort to mass fix to the packages via -source / -target 1.8 and --xmvn-javadoc. If this is happening, I will happily stop spamming, and will try to keep myself in loop. > > Can you also please stop pushing changes to packages without > coordinating with either the Java SIG or the Stewardship SIG (in one > case, even by abusing provenpackager rights to push directly to a > PR-only package)? I should be pushing only where I'm co/maintainer. > > Both beust-jcommander (*with tests*) and google-gson build fine with > xmvn-javadoc, yes, but both your commits wouldn't be necessary if > we're going ahead with switching to xmvn-javadoc by default, as I > suggested *2 weeks ago*: I know. And I'm using --xmvn-javadoc where possble now. And had listedit also on the know fixes page. > > https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-44930 > https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/UD7Q5DYAWI7YO4VW7UZPDWR644V7S462/ > > Fabio > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: 500 packages FTBFS in rawhide with java-11-openjdk as system JDK
On 6/10/20 8:14 AM, Ondrej Dubaj wrote: > Hi, > > after discussion with upstream mysql-connector-java is not able to be build > with jdk-11, as the code > contains deprecated API. that is sad. What is longterm goal of mysql-connector-java? You have to move it to live with java-1.8.0-openjdk-devel in built time, and java in runtime. There are already several packages which do so, and that hsould work for a while I had added : https://fedoraproject.org/wiki/Changes/Java11#Intermediate_step_build_with_java-1.8.0-openjdk-devel_and_run_with_java_.28that_means_any_sytem_java.2C_eg_java-11-openjdk.29 Thanx for investigations! J. > > Reference here: > > https://bugs.mysql.com/bug.php?id=99750 > > Best regards, > Ondrej > > On Tue, Jun 9, 2020 at 6:42 PM Jiri Vanek <mailto:jva...@redhat.com>> wrote: > > On 6/9/20 5:07 PM, Fabio Valentini wrote: > > On Tue, Jun 9, 2020 at 4:52 PM Fabio Valentini <mailto:decatho...@gmail.com>> wrote: > >> > >> On Tue, Jun 9, 2020 at 4:05 PM Jiri Vanek <mailto:jva...@redhat.com>> wrote: > >>> Please see > >>> > > https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions > >>> Please fix your packages according to > >>> https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild > >>> Inidivdual packagers are being emailed with details > >> > >> I've asked mizdebsk whether he thinks we can switch to using > >> xmvn-javadoc, which solves the majority of those build failures (over > >> half, by my count). > >> I also sent this proposal to the devel and java-devel mailing lists, > >> and there was no opposition to the change. > >> > >> For other failures, I've begun to track "EasyFix" solutions (mostly, > >> overriding -source 1.8 and -target 1.8, as suggested in the Change > >> proposal), and I've started to either push this change directly (for > >> packages I am associated with), or filing Pull Requests for them: > >> https://pagure.io/java-maint-sig/issue/1 > >> > >> However, I am only one man, with only so much time, so without help, > >> this "applying EasyFixes" will still take a while. > >> > >> With both changes (switching from maven-javadoc-plugin to > >> xmvn-javadoc, and applying the -source / -target 1.8 EasyFixes), the > >> number of build failures should be lower than 100, not over 500. > >> That's still a big number of broken packages, but it's *much* more > manageable. > > I had missed any coordinated effort to mass fix to the packages via > -source / -target 1.8 and > --xmvn-javadoc. If this is happening, I will happily stop spamming, and > will try to keep myself > in loop. > > > > Can you also please stop pushing changes to packages without > > coordinating with either the Java SIG or the Stewardship SIG (in one > > case, even by abusing provenpackager rights to push directly to a > > PR-only package)? > > I should be pushing only where I'm co/maintainer. > > > > Both beust-jcommander (*with tests*) and google-gson build fine with > > xmvn-javadoc, yes, but both your commits wouldn't be necessary if > > we're going ahead with switching to xmvn-javadoc by default, as I > > suggested *2 weeks ago*: > > I know. And I'm using --xmvn-javadoc where possble now. And had listedit > also on the know fixes > page. > > > > > https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-44930 > > > > https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/UD7Q5DYAWI7YO4VW7UZPDWR644V7S462/ > > > > Fabio > > > > > -- > Jiri Vanek > Senior QE engineer, OpenJDK QE lead, Mgr. > Red Hat Czech > jva...@redhat.com <mailto:jva...@redhat.com> M: +420775390109 > ___ > devel mailing list -- devel@lists.fedoraproject.org > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > <mailto: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 >
Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide
On 6/15/20 9:13 AM, Florian Weimer wrote: > * Ondrej Dubaj: > >> The problem is unknown runtime behaviour of libdb-java (build with >> jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an >> active user of libdb java ? > > I am not. > > Upon second thought, it doesn't seem to make sense to preserve > libdb-java (although I expect that it's only necessary to fix the > autoconf check). Maybe. However upstream of is dead. And usptream confirmed that they are unable to verify that it works in JDK11. Imho droppoing such possibly instbale package is probably good way. If it will be missed, then it can be returned, and the one wishing its return will be used as tester. Is there some replacemnt for this subpackage? At least theoretical? > > Thanks, > Florian > ___ > java-devel mailing list -- java-de...@lists.fedoraproject.org > To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Fedora 33 Self-Contained Change proposal: Default animated background for Fedora Workstation
On 6/16/20 9:18 AM, Kamil Paral wrote: > On Mon, Jun 15, 2020 at 10:12 PM Ben Cotton <mailto:bcot...@redhat.com>> wrote: > > https://fedoraproject.org/wiki/Changes/DefaultAnimatedBackground > > == Summary == > Fedora Workstation 33 uses animate background as default. > > > Can somebody enlighten me what an animated background exactly means? Is it > like a video/gif running > on your background endlessly in a loop? Or does this mean simply a wallpaper > slideshow, where the > wallpaper changes every X minutes/hours (or possibly based on the daytime, so > a different one for > the morning/noon/evening/night)? If the latter is correct, am I the only one > who sees the term > "animated background" as super-confusing here? > I would like to support this qeuestion. Where I like animated backgroundsa and am looking forward to have them done right in fedora, what kind of animation is in the scope here? - android like for swithing workspace - gif/video like one onisngle worksapce - different bakground on different workspace - chnaging backround fromtime to time - anything else? What if the spin support onl some subset of what main implementation will bring? Thanx a lot for effort! > > > ___ > 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 > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Fedora 33 System-Wide Change proposal: Fedora-Retired-Packages
On 6/15/20 10:43 PM, Solomon Peachy wrote:
> On Mon, Jun 15, 2020 at 03:47:33PM -0400, Ben Cotton wrote:
>> What I propose is: As part of the retirement process we add the to
>> fedora-retired-packages:
>> Obsoletes: foo < %{latestversion+1}
>> And during upgrade from F37->F38 the package will be removed.
>
> Gah, no. Just.. no.
>
> This will silently break otherwise-working software on production
> systems, and provide no straightforward way to get back to a working
> state.
Not only production. An good example are games. They are dead for ages, and you
still like to play them.
As mentioned elsewhere, some dnf --find-unmaintaned-stuff can help here.
>
>> If the user wants to preserve the package (e.g., because it moved to
>> Copr), he simply uninstalls and protects the installation of
>> fedora-retired-packages. But that will be an informed decision.
>
> So.. the package is dropped because it's not being maintained, yet..
> it's being maintained in copr? How often does this really happen?
>
>> The benefits are:
>> * we do not leave unmaintained packages on a user's machine.
>
> What about software installed from 3rd-party repositories? What about
> packages that were downloaded and installed directly from ISVs?
>
>> * We make sure that archaic packages do not break upgrade between two
>> versions of Fedora.
>
> This is a laudable goal, but... surely a better approach is to improve
> the diagnostics when faced with upgrade failures? That way the user
> will be able to make an informed choice at the time the problem would
> have occurred, rather than having the software (which they might be
> reliant upon) silently disappearing.
>
> I say this as someone who has run into this problem quite often over the
> years, including on the machine I'm using to write this email.
> Sometimes the correct solution is to remove the old package, but other
> times that package is in active use.
>
>
> - Solomon
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jva...@redhat.comM: +420775390109
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")
Current stats from my testing samples: 408 failing 263 passing That is huge improvement. Thank you all. I'm now running last rebuild n copr, and in week or two an mass rebuild will be taken in koji. There was an discussion what the border will be, when to force this change, or when to step away. 50% of passed? 80%? But afaik no metric is valid here, because - sorry to say it - there is no longer any javastack... Since f29, about 1000 java packages died or were orphaned. I was removing packages where upstream is dead and are orphaned (so no chance to make them reliable working with jdk11), and I found that wildfly, jenkins, jboss, half of maven plugins, elastic search, apach-emina, infinispan, cassandra, hibernate All are dead. What is javastack for now (no blame or evil in that)? So maybe the system jdk11 can be used as just last death-blow to java stack, rethink it, and stat rebuilding on pretty fresh field J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")
On 6/29/20 1:59 PM, Aleksandar Kurtakov wrote: > > > On Mon, Jun 29, 2020 at 2:39 PM Jiri Vanek <mailto:jva...@redhat.com>> wrote: > > Current stats from my testing samples: > 408 failing > 263 passing > > > Are these numbers reversed ^^^ ? Looking at > https://copr.fedorainfracloud.org/coprs/g/java-maint-sig/java-11-default/monitor/ > I see a bit more > than 200 ftbfs. I'm afraid not. But if you are right, then maybe I'm doing something wrong, and it is all a bit more positive then I think. Thanx! > > > That is huge improvement. Thank you all. > I'm now running last rebuild n copr, and in week or two an mass rebuild > will be taken in koji. > > There was an discussion what the border will be, when to force this > change, or when to step away. > 50% of passed? 80%? But afaik no metric is valid here, because - sorry to > say it - there is no > longer any javastack... > Since f29, about 1000 java packages died or were orphaned. I was removing > packages where upstream is > dead and are orphaned (so no chance to make them reliable working with > jdk11), and I found that > wildfly, jenkins, jboss, half of maven plugins, elastic search, > apach-emina, infinispan, cassandra, > hibernate All are dead. What is javastack for now (no blame or evil > in that)? > > So maybe the system jdk11 can be used as just last death-blow to java > stack, rethink it, and stat > rebuilding on pretty fresh field > > > J. > > > > -- > Jiri Vanek > Senior QE engineer, OpenJDK QE lead, Mgr. > Red Hat Czech > jva...@redhat.com <mailto:jva...@redhat.com> M: +420775390109 > ___ > java-devel mailing list -- java-de...@lists.fedoraproject.org > <mailto:java-de...@lists.fedoraproject.org> > To unsubscribe send an email to java-devel-le...@lists.fedoraproject.org > <mailto:java-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/java-de...@lists.fedoraproject.org > > > > -- > Alexander Kurtakov > Red Hat Eclipse Team > > ___ > java-devel mailing list -- java-de...@lists.fedoraproject.org > To unsubscribe send an email to java-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/java-de...@lists.fedoraproject.org > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")
On 7/1/20 3:21 PM, Fabio Valentini wrote: > On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov > wrote: >> >> Fabio, does it mean that the Java SIG agrees with progressing with the >> Change to Java 11 as a default? > > Speaking for myself, yes. > > I can't speak for all other SIG members (we haven't formally voted on > this or something like that), but from conversations we've had I > gather that all active package maintainers are looking forward to > finally getting Java 11 by default. Yes, despite many soon FTBFS and thus soon orphaned pkgs, It looks taht active people wish to proceed with change, rather then doing the possibly clumsy step back. I'm progressing toward the mass rebuild in side tag. I'm aware about three packages needing commits to change - java-11-openjdk, java-1.8.0-openjdk and javapackages-tools. Fabio, saying "you have not got xmvn change", Is tere something I need to check for? 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 > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] Re: java stack is dead, long live the javastack (was "500 packages FTBFS in rawhide with java-11-openjdk as system JDK")
On 7/1/20 4:09 PM, Fabio Valentini wrote: > On Wed, Jul 1, 2020 at 4:00 PM Jiri Vanek wrote: >> >> On 7/1/20 3:21 PM, Fabio Valentini wrote: >>> On Wed, Jul 1, 2020 at 3:09 PM Aleksandar Kurtakov >>> wrote: >>>> >>>> Fabio, does it mean that the Java SIG agrees with progressing with the >>>> Change to Java 11 as a default? >>> >>> Speaking for myself, yes. >>> >>> I can't speak for all other SIG members (we haven't formally voted on >>> this or something like that), but from conversations we've had I >>> gather that all active package maintainers are looking forward to >>> finally getting Java 11 by default. >> >> Yes, despite many soon FTBFS and thus soon orphaned pkgs, It looks taht >> active people wish to >> proceed with change, rather then doing the possibly clumsy step back. >> >> I'm progressing toward the mass rebuild in side tag. >> >> I'm aware about three packages needing commits to change - java-11-openjdk, >> java-1.8.0-openjdk and >> javapackages-tools. >> >> Fabio, saying "you have not got xmvn change", Is tere something I need to >> check for? > > I was wondering whether you had included javapackages-tools in the > COPR with the second commit from the PR: > https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#commit_list The PR do not bump the release, so hard to say, but form: https://copr.fedorainfracloud.org/coprs/jvanek/java11/package/javapackages-tools/ I guess yes, becasue there wasautobuild 21days ago. Same age as commit landed to javapackages-tools ava11 branch, and autorebuild is enabled. Thanx for heads up! 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 > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Mass rebuild for f33-java11 side tag completed
Hello! toatal packages: 610 passed: 427 failed: 176 From the failures, there is 29 which passed in the copr before, and now are thus failing from two reasons - unrelated change, or non-intel64-arch failure. I will put this to FTBF bugs for those 29 pacakges, In Monday, or as other duties allows I will fill FTBFS bugs for failures with straces and reproduce steps. In default CC will be, me, Severin, decathrope and java-de...@lists.fedoraproject.org. Note that during non-sidetag rebuild during fedora 33 branching in start of August, we can expect some indirect dependencies to fail. Thoughts? J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.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
Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed
> > A cursory glance shows that some failed with network problems. E.g. > plexus-velocity failed with this: > > DEBUG util.py:621: Errors during downloading metadata for repository 'build': > DEBUG util.py:621: - Curl error (18): Transferred a partial file for > http://kojipkgs-cache01.s390.fedoraproject.org/repos/f33-java11/1710873/s390x/repodata/d901882654dc717c8fc91a6b2f018eeaa538eb6e003b0927bc9ae85895a83786-filelists.xml.gz > [transfer closed with 23617146 bytes remaining to read] > > (Sigh, flakey s390x machines, we meet again.) > > When I retriggered the build it succeeded: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1540681 > > Might be worth a retry of other failures before filing FTBFS bugs. Thanx! Will elaborate on this! > > ___ > 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 > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed
>> >> Any update? Any thoughts on when you want to merge the f33-java11 side tag >> back into rawhide? done >> > > BTW There are some packages, e.g. built by ant with no sauce/target level > specified at all, that are > built with Java 11-level bytecode. > > This is bad because if there is a dependent package that requires Java 8 for > some reason it won't > work because the bytecode of one your dependencies is too new and cannot be > interpreted by Java 8. > In these cases > > I am fixing such occurrences in the ```f33-java11``` build target as I > encounter them -- just > something to be aware of in case you see any UnsupportedClassVersionErrors. Mat, I had come to same conclusion, which had lead me into this: https://src.fedoraproject.org/rpms/javapackages-tools/pull-request/3#comment-50266 . Please contriute, or sugest next steps here. I would liek to have it java-packaging gudelines change, and self-contained f33 change, but it may be to late. I see yo already track the Fabio's to-high bytecode issue, but my proposal is to prevent it in future. However, it do not seem to be facing to much sympathies. J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Mass rebuild for f33-java11 side tag completed
Hi! Side tag was merged, java-11-openjdk now should be system JDK. Don't hesitate to reach me if you encounter some misbehaving! J. On 7/11/20 10:24 AM, Jiri Vanek wrote: > Hello! > > toatal packages: 610 > passed: 427 > failed: 176 > > From the failures, there is 29 which passed in the copr before, and now are > thus failing from two > reasons - unrelated change, or non-intel64-arch failure. I will put this to > FTBF bugs for those 29 > pacakges, > > > In Monday, or as other duties allows I will fill FTBFS bugs for failures > with straces and reproduce > steps. > In default CC will be, me, Severin, decathrope and > java-de...@lists.fedoraproject.org. > > Note that during non-sidetag rebuild during fedora 33 branching in start of > August, we can expect > some indirect dependencies to fail. > > Thoughts? > > > J. > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.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
Orphaning visualvm
Hi! I'm no longer interested in maintaining of visualvm - https://admin.fedoraproject.org/pkgdb/package/visualvm/ - Simply I didn't used it for last three years If somebody still is using it, I will happily retire ownership to him/her. Looking forward to meet the successor, J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 01:34 PM, Severin Gehwolf wrote: On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote: [...] option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy Fedora already supports multiple JDKs installable in parallel. This was inherited from JPackage project. This breaks long-established rule of naming JDK packages as "java-x.y.z-vendor" used across different distributions (JPackage, Fedora, RHEL, SUSE, ...) [...] The idea behind this "-legacy" suffix was to ensure a reasonable upgrade path for people *only* using default java-x.y.z-openjdk package. Consider the following scenario (all hypothetical, not saying that any Fedora releases and JDK releases align in this way): F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default. The upgrade from F22 => F23 will install java-1.9.0-openjdk and remove java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure that no old JDKs stick around on the majority of Fedora systems. If the name was kept there does not seem to be a good way to: 1.) Ensure dist upgrades update JDK packages 2.) Ensure dist upgrades remove old JDK package (which may no longer get security updates). Do you see a way to achieve this without a name change of the package? Unluckily, I'm not. But I guess, this question is going to Mikolaj. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
Package maintainers are responsible for their packages. If maintainer of "main JDK" is also maintaining "legacy JDK" then (s)he should be responsible for both of them. I don't see why any special rule should be defined. You missed very important point. The maintainer will never be same. We (people around OpenJDK packages) are not going to do so. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 01:50 PM, Dominik 'Rathann' Mierzejewski wrote: On Tuesday, 24 February 2015 at 13:34, Severin Gehwolf wrote: On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote: [...] option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy Fedora already supports multiple JDKs installable in parallel. This was inherited from JPackage project. This breaks long-established rule of naming JDK packages as "java-x.y.z-vendor" used across different distributions (JPackage, Fedora, RHEL, SUSE, ...) [...] The idea behind this "-legacy" suffix was to ensure a reasonable upgrade path for people *only* using default java-x.y.z-openjdk package. Consider the following scenario (all hypothetical, not saying that any Fedora releases and JDK releases align in this way): F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default. The upgrade from F22 => F23 will install java-1.9.0-openjdk and remove java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure that no old JDKs stick around on the majority of Fedora systems. If the name was kept there does not seem to be a good way to: 1.) Ensure dist upgrades update JDK packages 2.) Ensure dist upgrades remove old JDK package (which may no longer get security updates). Do you see a way to achieve this without a name change of the package? Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk are different packages? yes they are, but the secon *is* update of first. If there are any packages requiring java-1.8.0-openjdk they can keep using it as long as it has a maintainer. java-1.9.0-openjdk will be a completely new package. Yes they can. But until now it was really bad idea. IcedTea-Web was also wrong example - it is requiring *main* jdk. Nothing else. And as it is not strightforward to compile ITW agains different jdks, then the strict rule have sense. I agree with Mikołaj that there's no need for what you're proposing. There is. Not using those rules will completly break fedaora+java as we know it now. I would much rather live without any legacy jdk, and if so then without any rules. But not setting them will bring chaos for majority of users. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: I am against official guidelines or policy for legacy JDK packages. I don't think that any such policy is needed and it would only encourage adoption of old packages for which there might be no security updates. Well thats the point - people are calling for them. And wont to maintain them with this risk. Those rules are here to protect the rest - who dont need legacy jdk for daily useage. Of course package maintainers can agree on specific rules that apply to their packages, but it doesn't mean that such rules should be part of packaging guidelines. More details inline. My counter-proposal is at the end. On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. Currently anyone is allowed to maintain legacy JDKs in Fedora according to general rules, so this change proposal does not "enable" maintenance of legacy JDKs. It is not true. We were killing old packages withut handling the owenership or maintainerships to others. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' Package maintainers are responsible for their packages. If maintainer of "main JDK" is also maintaining "legacy JDK" then (s)he should be responsible for both of them. I don't see why any special rule should be defined. As I higlighted - we - main jdk team - are never ever going to do so. option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy Fedora already supports multiple JDKs installable in parallel. This was inherited from JPackage project. This breaks long-established rule of naming JDK packages as "java-x.y.z-vendor" used across different distributions (JPackage, Fedora, RHEL, SUSE, ...) 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) Again, I don't think we should define such rule. Package owner decides who can be comaintainer. I don't think we should prevent someone from maintaining package in Fedora just because he doesn't want "main JDK" maintainers to comaintain his package or enforce anyone to be comaintainer without his/her will. Interested parties can always volunteer to become comaintainers or watch for changes, report bugs and propose fixes or enhancements. I do not insists on this rule. But it is the only way how to be sure the those rules are kept or to act quickly if something breaks. It is actually good will of openjdk team that we are willing to do so. I will happily give up on it. 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) Currently all compat packages must complete full review before being introduced. Why JDK should be treated specially? I think that with complex system of virtual provides, alternatives and strict directory layout it's necessary to fully review "legacy JDK" package to make sure it doesn't conflict with primary JDK and that it is integrated with Fedora as expected. Well the jdk - as is now - will never pass regular review - it is handling config files and libraries and shared jars really differently - and have good purposes for it. 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. I don't like this rule either. In some cases it may be useful or necessary to require specific JDK or JRE package. For example icedtea-web requires java-1.8.0-openjdk, which is correct and should not be changed. All packages are requiring java or java-headless or java-devel. The exeptions are rare. ITW actually do not need this, but it making my life easier. So I will turn to java or ask for exception. In case of trnsition to jdk9, I will *not* kepp java-1.8.0-openjdk unless something terrible happens. As counter-proposal I recommend starting discussion within Java SIG on how to handle JDK deprecation. The end result could be documenting what was agreed somewhere on the wiki. This one have issue to add much more work to people alr
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote: - Original Message - From: "Jiri Vanek" To: devel@lists.fedoraproject.org Sent: Tuesday, February 24, 2015 3:02:38 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/24/2015 01:50 PM, Dominik 'Rathann' Mierzejewski wrote: On Tuesday, 24 February 2015 at 13:34, Severin Gehwolf wrote: On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote: [...] option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy Fedora already supports multiple JDKs installable in parallel. This was inherited from JPackage project. This breaks long-established rule of naming JDK packages as "java-x.y.z-vendor" used across different distributions (JPackage, Fedora, RHEL, SUSE, ...) [...] The idea behind this "-legacy" suffix was to ensure a reasonable upgrade path for people *only* using default java-x.y.z-openjdk package. Consider the following scenario (all hypothetical, not saying that any Fedora releases and JDK releases align in this way): F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default. The upgrade from F22 => F23 will install java-1.9.0-openjdk and remove java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure that no old JDKs stick around on the majority of Fedora systems. If the name was kept there does not seem to be a good way to: 1.) Ensure dist upgrades update JDK packages 2.) Ensure dist upgrades remove old JDK package (which may no longer get security updates). Do you see a way to achieve this without a name change of the package? Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk are different packages? yes they are, but the secon *is* update of first. If there are any packages requiring java-1.8.0-openjdk they can keep using it as long as it has a maintainer. java-1.9.0-openjdk will be a completely new package. Yes they can. But until now it was really bad idea. IcedTea-Web was also wrong example - it is requiring *main* jdk. Nothing else. And as it is not strightforward to compile ITW agains different jdks, then the strict rule have sense. I agree with Mikołaj that there's no need for what you're proposing. There is. Not using those rules will completly break fedaora+java as we know it now. I would much rather live without any legacy jdk, and if so then without any rules. But not setting them will bring chaos for majority of users. I have a question: Is there anybody that stepped in to maintain the legacy jdk? If there is nobody to maintain it trying to come up with this guidelines now would be pointless. In short I think that such guidelines would better be created *only* when there are interested parties, jointly with them and the process is played a bit by some copr repo or similar. Purely theoretical work is not needed. There were several attempts in past like "can you please support jdk 7,6...in newer fedoras" and we always told no. When come speech about "do it on your own" suddenly many questions marks raised up. The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to maintain it. So deciding that legacy jdks are not never ever supportable, is also option. Then we will move all users to that statement, and we will let them do theirs builds in copr... Yes its possibility. It is actually the simplest one, but maybe not the generally desired one. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 02:58 PM, Dominik 'Rathann' Mierzejewski wrote: On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote: [...] There were several attempts in past like "can you please support jdk 7,6...in newer fedoras" and we always told no. When come speech about "do it on your own" suddenly many questions marks raised up. The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to maintain it. Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk and its successors. You shouldn't arbitrarily block people from re-introducing an older branch of any package back into Fedora in the first place. We can not do it. It will keep legacy jdks in users system. We don't wont 99% of users to keep (unwillingly and unknowingly) old jdks. 99% of users is hepy with one - main - jdk. To provide new jdk , we have to obsolate old jdk... If you have workaround for this, please share. (Sewerin already higlighted it on devel discussion). J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 03:11 PM, Dominik 'Rathann' Mierzejewski wrote: On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote: * Dominik 'Rathann' Mierzejewski [2015-02-24 09:04]: On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote: [...] There were several attempts in past like "can you please support jdk 7,6...in newer fedoras" and we always told no. When come speech about "do it on your own" suddenly many questions marks raised up. The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to maintain it. Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk and its successors. You shouldn't arbitrarily block people from re-introducing an older branch of any package back into Fedora in the first place. We have no intention of blocking it. The reason for proposing these restrictions is that the Fedora Java stack will not work with older JDKs, therefore we need to make sure that it goes not get installed on the system unless explicitly requested by someone who knows what they are doing. Well, you do that by adding/updating (Build)Requires: in the packages which won't work otherwise, not by adding Obsoletes:. No. They are (B)R java. We are obsoleting older version of java and doing mass rebuild. Thats the only way how to ensure whole stack is build by same jdk - main jdk - and we need to ensure 99% of people will be using the correct jdk with correct application I probably miss your point, you seems to be unaware about haw java udates and stack is working best regards from cz, J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 04:03 PM, Mikolaj Izdebski wrote: On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote: 2.) Ensure dist upgrades remove old JDK package (which may no longer get security updates). Firstly, as I understand upgrade isn't supposed to remove packages by default, unless they are obsoleted or conflict with something. Are you saying that JDKs should be treated exceptionally by package management systems? I should add that user can easily remove packages which were installed as dependencies, but which are no longer needed by running "yum autoremove" command. So by other words - from option "one" and "two" you vote for two, no renaming, and removing rules 4,5,6,7. You do not complain about rule 2 and 3.Right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/25/2015 10:07 AM, Mikolaj Izdebski wrote:
On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:
However, if there are JAR files which are useful
for a developer, they can have a -legacy version too!
There is no technical reason to suffix anything - you can put JARs that
depend on old version of JDK in /usr/{share,lib}/java-x.y.z, for example
/usr/share/java-1.7.0/ for JARs that require JDK 7.
The reason for suffix is to be able properly obsolete, and so protect 99% of users from having also
old java installed.
I dont know how to technically solve this without obsolete. In all other scenarios manual touch of
user is needed to keep only one (main) jdk.
If you will come with way how to keep 99% of users safe from any legacy jdk then I wil lbe happy to
abandon -legacy and go with simple orphaning.
*however* legacy have also one advantage - any user - even unskilled - may easily spot that
something in his system is using legacy jdk or (after he typed (yum install java-1.*" immediately
see that something then just simple opened is installed)
J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote: /*Kevin Kofler*/ wrote on Wed, 25 Feb 2015 01:31:59 +0100: Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek IMHO, this is not implementable for a simple practical reason: All the JARs we ship are built from source with our default JDK. They will in general NOT work on any JRE that's older than the default JDK. (A JRE/JDK that's NEWER than the default JDK can work though, e.g., the java-1.8.0-openjdk packages in Fedora 19 and 20. But we were already providing those.) To avoid state of things you just described, this proposal was described. Nothing will be compiled or run by legacy jdk if those rules are kept, not even by accident. Howevewr people willingly and with full consequence wil be able to use legacy jdk for third party apps, or go on theirs system on theirs own responsibility. I'd say this proposal is very similar to my proposal[1] for libraries: the legacy JDKs can be useful for the user when facing with non-Fedora development. IMHO, it is fine, and even great, that no Fedora JARs will depend on legacy JDK. However, if there are JAR files which are useful for a developer, they can have a -legacy version too! Yes. This is the intention. Regards, Hedayat [1] "Proposal to (formally/easily) allowing multiple versions of the same library installable" thread J, -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 04:36 PM, Deepak Bhole wrote: * Mikolaj Izdebski [2015-02-24 10:12]: On 02/24/2015 04:06 PM, Deepak Bhole wrote: * Mikolaj Izdebski [2015-02-24 09:58]: On 02/24/2015 03:32 PM, Deepak Bhole wrote: * Dominik 'Rathann' Mierzejewski [2015-02-24 09:29]: On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote: * Dominik 'Rathann' Mierzejewski [2015-02-24 09:04]: On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote: [...] There were several attempts in past like "can you please support jdk 7,6...in newer fedoras" and we always told no. When come speech about "do it on your own" suddenly many questions marks raised up. The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to maintain it. Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk and its successors. You shouldn't arbitrarily block people from re-introducing an older branch of any package back into Fedora in the first place. We have no intention of blocking it. The reason for proposing these restrictions is that the Fedora Java stack will not work with older JDKs, therefore we need to make sure that it goes not get installed on the system unless explicitly requested by someone who knows what they are doing. Well, you do that by adding/updating (Build)Requires: in the packages which won't work otherwise, not by adding Obsoletes:. That would generally work for most packages, but there is a new JDK released every 2 years. This means that we would have to change the BR and Requires for the entire Java stack (100s and 100s of packages) every 2 years, which is non-trivial. First, we have versioned auto-requires generated during package build. Explicit requires on java aren't usually needed. If package requires "java > 1:1.7" then it is correct - the package can be assumed to work with older JDK. While that is true in terms of source compatibility, it will work only if it is compiled with the older JDK. Secondly, it is fairly easy to add requires on "java-devel >= 1:1.8" to packages related to build systems like ant, maven or gradle. This would cover most cases of building Java packages using latest JDK. As you stated, it will cover most cases, but not all. More critically, this does not solve the issue with requirement of 'java' itself. These few remaining cases can be easily handled by provenpackager as mass-change. Also, my proposal of introducing "java" metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the issues via some metapackage. At the end I gave up, because the touch of user was always necessary. J. Ah, I had missed that. Yes, the metapackage solution should work to the same effect. I don't know if we can just call it 'java' though, unless you are proposing that 'java' provision be removed from current openjdk packages? Deepak -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 05:04 PM, Mikolaj Izdebski wrote: On 02/24/2015 04:36 PM, Deepak Bhole wrote: * Mikolaj Izdebski [2015-02-24 10:12]: On 02/24/2015 04:06 PM, Deepak Bhole wrote: * Mikolaj Izdebski [2015-02-24 09:58]: On 02/24/2015 03:32 PM, Deepak Bhole wrote: * Dominik 'Rathann' Mierzejewski [2015-02-24 09:29]: On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote: * Dominik 'Rathann' Mierzejewski [2015-02-24 09:04]: On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote: [...] There were several attempts in past like "can you please support jdk 7,6...in newer fedoras" and we always told no. When come speech about "do it on your own" suddenly many questions marks raised up. The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to maintain it. Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk and its successors. You shouldn't arbitrarily block people from re-introducing an older branch of any package back into Fedora in the first place. We have no intention of blocking it. The reason for proposing these restrictions is that the Fedora Java stack will not work with older JDKs, therefore we need to make sure that it goes not get installed on the system unless explicitly requested by someone who knows what they are doing. Well, you do that by adding/updating (Build)Requires: in the packages which won't work otherwise, not by adding Obsoletes:. That would generally work for most packages, but there is a new JDK released every 2 years. This means that we would have to change the BR and Requires for the entire Java stack (100s and 100s of packages) every 2 years, which is non-trivial. First, we have versioned auto-requires generated during package build. Explicit requires on java aren't usually needed. If package requires "java > 1:1.7" then it is correct - the package can be assumed to work with older JDK. While that is true in terms of source compatibility, it will work only if it is compiled with the older JDK. Secondly, it is fairly easy to add requires on "java-devel >= 1:1.8" to packages related to build systems like ant, maven or gradle. This would cover most cases of building Java packages using latest JDK. As you stated, it will cover most cases, but not all. More critically, this does not solve the issue with requirement of 'java' itself. These few remaining cases can be easily handled by provenpackager as mass-change. Also, my proposal of introducing "java" metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. Ah, I had missed that. Yes, the metapackage solution should work to the same effect. I don't know if we can just call it 'java' though, unless you are proposing that 'java' provision be removed from current openjdk packages? I'm not really proposing as I haven't thought about this much yet, but the idea was about be adding a few empty binary packages "java", "java-devel", "java-headless" and so on (they could be subpackages of javapackages-tools). Existing provides with the same names could be removed from JDK packages. "java" would be the preferred JRE in Fedora. The package would have no content, but it would have Requires on preferred Fedora JRE, currently java-1.8.0-openjdk. This could be easily changed as default JRE changes. The same is for other binary subpackages of "java", respectively. All system packages would require subpackages of "java" as they do now (unless there is good reason not to). Users that install "java" would get latest JRE, which would be updated to new major versions as they become default. Older JDKs would not be removed during update (unless there is no maintainer and they are obsoleted as currently), but users could remove them with "yum autoremove", unless something requires older JDK or they installed it explicitly. Does it really seem to you as more simple solution both for packagers and users? it does snot to me... J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 05:21 PM, Mikolaj Izdebski wrote: On 02/24/2015 04:59 PM, Pete Travis wrote: On Feb 24, 2015 8:32 AM, "Mikolaj Izdebski" wrote: On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote: I would much rather live without any legacy jdk, and if so then without any rules. But not setting them will bring chaos for majority of users. I have a question: Is there anybody that stepped in to maintain the legacy jdk? If there is nobody to maintain it trying to come up with this guidelines now would be pointless. In short I think that such guidelines would better be created *only* when there are interested parties, jointly with them and the process is played a bit by some copr repo or similar. Purely theoretical work is not This pure theoretical work is based on various troubles various multiple/legacy jdks caused in last years. So it is preventing the issues we know will rise. needed. I fully agree with Alex here. I would add that if someone really wants to maintain older JDK in Fedora then it should up to *them* to come up with a solution that will work Them? ANy packaging/openjdk newbie? Cool. It will break and will breaak a lot. Those guidelines were written to protect fedora from possible harm. and satisfy expectations of JKD maintainers and Java SIG. Maintaining package is more than clicking "unorphan" in pkgdb. -- -- If some third party supplies 'java' as the $legacy jdk, and the user installs a Fedora package built on $current jdk, which provider will win, and what packages will break? Hopefully none. And the guidelines should prevent any unsuitable jdk to "win" automatically. It's implementation detail of different package management systems (yum/dnf etc) and in general it's unspecfied. My experience shows that multiple packages providing the same thing are unreliable in practice and best avoided. If the user uses alternatives to set the jdk (that applies here, right?) any applications that need one version or the other could break? I don't know how to avoid this issue. But at least it will happen - if happen at all - after the manual switch is done. Particular applications can be configured to use different JRE/JDK versions (for example you can run Maven with Java 8, but Ant with Java 7). Per-user configuration is also possible (user bob runs Maven with Java 8, but fred with Java 7). Fedora is quite flexible in this aspect. Moreover, Fedora can be configured not to use alternatives for Java apps, so you can have /usr/bin/java pointing to old JDK while Fedora applications are running with default (latest) JDK. I understand these are relatively ignorant questions, but if the aim is to provide a path for someone to maintain older JDKs it seems better to offer them guidelines and best practices instead of "you'd better be competent enough to figure it out". They might not think of all the potential conflicts. Yes, this sounds right. If someone wants to maintain old JDK they are free to do so. Moreover, they will surely get help from Java SIG with implementing that, provided they show enough involvement. But IMO packaging guidelines is not a What is an better place? place for listing details how compat packages for JDK should look like. Java SIG is busy enough. Why to add you more work? J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote: Hi All, I have been reading this mail chain for some time and there is something I wanted to say. It's kind of a long mail, I apologize for taking so much of your time but request you to please bear with me. I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and Python technology stacks, who has to code on Java/J2EEquite often as well and I use Fedora 21 Workstation as my primary OS. My field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, all from time to time. This is because as time passed, solutions delivered to customers were built using incremental versions of Java/J2EE specifications and were not frequently upgraded. In my role, the changes/fixes I do to these enterprise apps are usually small and require only a certain jar file to be recompiled, or in some cases only one class. In such cases, maintaining binary compatibility is a must and for that I need to recompile that one jar/class with the original version of JDK that was used to compile the rest of the project in the first place. I use Oracle java in most cases due to corporate policies (for personal use, I use the latest version of OpenJDK). Now as per Oracle's policy, which I am sure is similar for OpenJDK as well, a particular version of JDK/JRE is updated till and even some time after the next major version is released, and then at a certain Update level, Oracle stops supporting it. That update version becomes the final update for that particular major release, and is sent into archives, while updates keep on getting released for the current version. With Oracle JDK, there are two installation approaches available for RPM based systems. They provide an RPM package which installs java in /usr/java, i.e. in system area and the latest installed java version become default. However, they also provides tarballs of JDKs, that contain certain standard directory structure of JDK intact inside one folder. These tarballs can be extracted and placed in any place on file system and once JAVA_HOME is pointed towards these+PATH is locally updated to include it, user can basically use this JDK without any issues. What version of Java is installed in system as default, in system area (/usr/java) become irrelevant. With IDEs like Eclipse and NetBeans the process is even simpler, as you can define these individual folders as JDKs for particular API versions in IDE configuration permanently and while creating a project can choose to use any of these "defined JDKs". This is the approach that I take. I have the last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I have these configured in Eclipse and NetBeans for each API version and I use them all as required by the project. So I guess if OpenJDK can follow the same approach and can give an option to download tarballs of older versions and use them in place, without requiring any installation, as a definite directory structure, then the problem is solved. There is no need to maintain old version per se in repositories, as these are not updated anymore and the user will be able to use multiple versions without conflict of any kind. As for the default JDK, it can be kept how it is now i.e. The latest available JDK can be maintained in Fedora repos as they are being maintained now and updates can be provided for the defined lifetime of that JDK. Let me know what you guys think about this approach. This is lying on openjdk table for long time to have at least source tarballs... As you can see, nothing,. However once you are able to build jdk on your own, nothing prevents you form mercurial clone of *any* version. So this is the way you should go. If you wont binary images to be supported by openjdk itself, its completely different and more complex story. J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 06:22 PM, Mikolaj Izdebski wrote: On 02/24/2015 05:21 PM, Mario Torre wrote: On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote: On 02/24/2015 02:15 PM, Jiri Vanek wrote: On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote: I am against official guidelines or policy for legacy JDK packages. I don't think that any such policy is needed and it would only encourage adoption of old packages for which there might be no security updates. Well thats the point - people are calling for them. And wont to maintain them with this risk. I thought that the point of this change proposal was "enabling community to maintain legacy JDKs", not encouraging people to package them without good reason or without involvement to truly maintaining them. Packaging older JDKs is *already* possible, so IMHO this change accomplishes nothing but showing people how they can dump old, unmaintained software into Fedora. Well, in this case it would not be un-maintained, the Fedora package would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we are still actively contributing to the upstream software in its various versions. While you as a packager cannot specifically count on that, there's still a level of confidence that the base software won't be abandoned any time soon. And even when we will stop supporting those older versions, the community will take over if there is a need for that, exactly like we have done ourselves before. Indeed, there's an overhead for the downstream maintainers, we may need to drop specific version of OpenJDK, or skip a release, or do other funny things and the Fedora maintainers will have to adapt, but this is no different than usual I believe. Realistically, we are so conservative with older JDKs that I doubt this will ever really be an issue. Correct me if I am wrong, but in my understanding maintaining JDK package requires a lot of ongoing work (including obtaining and applying Here you are right, patches, running TCK, pushing updates in timely manner and so on). JDK maintainers should know this and I'm assuming that the amount of required work is the main reason for them not wanting to maintain older JDKs. I would say here you are not. No one will force the legacy jdks to be uodated. And afaik there will be no need to do it somehow furiously. Keeping package of EOLed programis actually most simple thing... (unles it FBfS and die by naturalk death) The work required to add old JDK package to Fedora is relatively small compared to ongoing maintenance work. Someone willing to truly maintain JDK in Fedora should have knowledge about JDK packaging and they shouldn't have problem finding time to come up with a working solution, proposing and discussing it. If you make the process of adding legacy JDKs to Fedora too easy then someone without enough time and required knowledge will surely do that Thats not an intention of the proposal. But the need to highlight that regular review can not appy to java packages was necessary. and we may easily end with unmaintained package. I'd rather not have old JDK than have unmaintained JDK with security holes. There is no workaround for human factor. Package that doesn't pass review shouldn't be part of Fedora. Well, if your goal is to reduce the user base of Fedora, I'm sure we can talk about removing the JDK :) We can't sacrifice our basic principles (such as passing review) for the sake of increasing user base. As told, it is not it. But java packages will not never ever pass regular review. And in adition the legacy ones will probably need to follow even more rules (aka this proposal...) J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote: On 02/26/2015 08:42 AM, Jiri Vanek wrote: Also, my proposal of introducing "java" metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the issues via some metapackage. At the end I gave up, because the touch of user was always necessary. I described it in much detail in other posts in this thread (for example message-ID 54eca102.1070...@redhat.com) Yah. Sorry. I walked across it later then replied this. However - I'm not convinced that metapackage will work as expected. If nothing else it will need some changes in current infrastructure which I wonted to avoid. Thanx for that! J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 09:16 AM, Mikolaj Izdebski wrote: On 02/25/2015 06:58 PM, Miloslav Trmač wrote: On 02/24/2015 06:41 PM, Miloslav Trmač wrote: Hello, "java" would be the preferred JRE in Fedora. The package would have no content, but it would have Requires on preferred Fedora JRE, currently java-1.8.0-openjdk. This could be easily changed as default JRE changes. The same is for other binary subpackages of "java", respectively. All system packages would require subpackages of "java" as they do now (unless there is good reason not to). Users that install "java" would get latest JRE, which would be updated to new major versions as they become default. Older JDKs would not be removed during update (unless there is no maintainer and they are obsoleted as currently), AFAIK nothing obsoletes a package just because it is orphaned… If no volunteer shows up for maintenance of old JDK then it would be deprecated and obsoleted, as it's was done with previous JDK packages. How would that work _exactly_? 1) JDK maintainers announce deprecation in advance and call for volunteers to maintain old JDK 2) when the time of deprecation comes, JDK package is reassigned to new maintainer, if such showed up; no obsoletes are added This is heavily untrue. The obsolete (or similar mechanism) is necessary. We do not wont any user to live unvoulenteerly and unwillingly with legacy jdk. I would like also to avoid just keeping the legacy jdk on his drive. Two reasons 1- the stack will eb compiled by nex (newr) jdk - so old jdk will not be bel tun it. - even keeping it on drive may lead to risk of usage it (speaking about basic user here). Not speaking about vasting of space on drive after several major updates. 2- low mainatainance. The community maintained jdk can never be expected to be so uptodate == so safe asmain jdk, which is mainatined by openjdk upstream-working people. 3) if there is no new maintainer then old JDK is redired in pkgdb, blocked in koji and obsoleted by some other package 4) if maintainer shows up after old JDK was retired then he can just revive package (passing review if needed); package release is bumped to be higher that obsoletes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote: - Original Message - From: "Mikolaj Izdebski" To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 10:16:26 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/25/2015 06:58 PM, Miloslav Trmač wrote: On 02/24/2015 06:41 PM, Miloslav Trmač wrote: Hello, "java" would be the preferred JRE in Fedora. The package would have no content, but it would have Requires on preferred Fedora JRE, currently java-1.8.0-openjdk. This could be easily changed as default JRE changes. The same is for other binary subpackages of "java", respectively. All system packages would require subpackages of "java" as they do now (unless there is good reason not to). Users that install "java" would get latest JRE, which would be updated to new major versions as they become default. Older JDKs would not be removed during update (unless there is no maintainer and they are obsoleted as currently), AFAIK nothing obsoletes a package just because it is orphaned… If no volunteer shows up for maintenance of old JDK then it would be deprecated and obsoleted, as it's was done with previous JDK packages. How would that work _exactly_? 1) JDK maintainers announce deprecation in advance and call for volunteers to maintain old JDK 2) when the time of deprecation comes, JDK package is reassigned to new maintainer, if such showed up; no obsoletes are added We speak about people that are already Fedora packagers, right? Just sponsoring someone that showed up and let him/her maintain Still it is possible scenario. I can even guess that this person will be apckaging newbe - most of java developers do not care about packaged stuff below. They have theirs Java EE and are happy that packages are solving all the issues they dont like. On contrary, if such a person wonts to pack it then you cna expect him to learn quicly. > legacy JDK in Fedora is recipe for disaster. Thats what this guidelines should prevent... For not-yet-packagers they would have to go through the full review-sponsoring process. Alexander Kurtakov Red Hat Eclipse team 3) if there is no new maintainer then old JDK is redired in pkgdb, blocked in koji and obsoleted by some other package 4) if maintainer shows up after old JDK was retired then he can just revive package (passing review if needed); package release is bumped to be higher that obsoletes -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 09:43 AM, Aleksandar Kurtakov wrote: - Original Message - From: "Jiri Vanek" To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 10:39:35 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote: - Original Message - From: "Mikolaj Izdebski" To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 10:16:26 AM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/25/2015 06:58 PM, Miloslav Trmač wrote: On 02/24/2015 06:41 PM, Miloslav Trmač wrote: Hello, "java" would be the preferred JRE in Fedora. The package would have no content, but it would have Requires on preferred Fedora JRE, currently java-1.8.0-openjdk. This could be easily changed as default JRE changes. The same is for other binary subpackages of "java", respectively. All system packages would require subpackages of "java" as they do now (unless there is good reason not to). Users that install "java" would get latest JRE, which would be updated to new major versions as they become default. Older JDKs would not be removed during update (unless there is no maintainer and they are obsoleted as currently), AFAIK nothing obsoletes a package just because it is orphaned… If no volunteer shows up for maintenance of old JDK then it would be deprecated and obsoleted, as it's was done with previous JDK packages. How would that work _exactly_? 1) JDK maintainers announce deprecation in advance and call for volunteers to maintain old JDK 2) when the time of deprecation comes, JDK package is reassigned to new maintainer, if such showed up; no obsoletes are added We speak about people that are already Fedora packagers, right? Just sponsoring someone that showed up and let him/her maintain Still it is possible scenario. I can even guess that this person will be apckaging newbe - most of java developers do not care about packaged stuff below. They have theirs Java EE and are happy that packages are solving all the issues they dont like. On contrary, if such a person wonts to pack it then you cna expect him to learn quicly. > legacy JDK in Fedora is recipe for disaster. Thats what this guidelines should prevent... No, no guidelines can prevent someone putting %post rm -fr /etc in a spec file. There is a reason for not having blank approval for anybody. Then we are discussing only one point of this proposal. And I guees "formal review" one. Level of the formalness have to be agreed. And somebody have look over pacakge. I would say the rm rf / in postun is protected by step 5. By "formal review" I was higlighting that no jdk package can actually pass general review. J. Alexander Kurtakov Red Hat Eclipse team For not-yet-packagers they would have to go through the full review-sponsoring process. Alexander Kurtakov Red Hat Eclipse team 3) if there is no new maintainer then old JDK is redired in pkgdb, blocked in koji and obsoleted by some other package 4) if maintainer shows up after old JDK was retired then he can just revive package (passing review if needed); package release is bumped to be higher that obsoletes -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote: On 02/26/2015 09:23 AM, Jiri Vanek wrote: On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote: On 02/26/2015 08:42 AM, Jiri Vanek wrote: Also, my proposal of introducing "java" metapackage (see my other post in this thread), which would always require the latest JDK, solves this problem in a different way, without modifying ordinary Java packages at all. May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the issues via some metapackage. At the end I gave up, because the touch of user was always necessary. I described it in much detail in other posts in this thread (for example message-ID 54eca102.1070...@redhat.com) Yah. Sorry. I walked across it later then replied this. However - I'm not convinced that metapackage will work as expected. If Still the metapackge's correct dependence have to be someones responsibility. Will you be able to take this burden? nothing else it will need some changes in current infrastructure which I wonted to avoid. It works exactly how I described it. Old JDK won't be removed during Is it really wonted? If so, we can skip the "option one" and continue with with option two. update, but that's expected behaviour of package management software, such as DNF, and JDK packages should not differ from other Fedora Really should not? We done pretty god work to have only one main jdk unlike python1, python2,python3 or glib2,glib3,glibN... We are settled in special directory and so on. So in what is JDK actually similar to other packages? packages in this aspect. Consider a detailed example below. Thank you for this. I understood it from yuor describtion and already had the same. However I consider the keeping of old jdk as no-go for this. J. Assume we start with Java 7: sh-4.3# rpm -qa | grep java java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 java-1.7.0-1.fc23.x86_64 Then update to newer version of java metapackage, which brings Java 8: sh-4.3# dnf -y update Using metadata from Thu Feb 26 09:51:07 2015 Dependencies resolved. Package Arch Version Repository Size Installing: java-1.8.0-openjdk x86_64 666:1.8.0-1.fc23 rpm 5.6 k Upgrading: java x86_64 666:1.8.0-1.fc23 rpm 5.6 k Transaction Summary Install 1 Package Upgrade 1 Package Total size: 11 k Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Installing : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/3 Upgrading : java-666:1.8.0-1.fc23.x86_642/3 Cleanup : java-666:1.7.0-1.fc23.x86_643/3 Verifying : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/3 Verifying : java-666:1.8.0-1.fc23.x86_642/3 Verifying : java-666:1.7.0-1.fc23.x86_643/3 Installed: java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23 Upgraded: java.x86_64 666:1.8.0-1.fc23 Complete! Now both Java 8 and legacy Java 7 are installed: sh-4.3# rpm -qa | grep java java-1.8.0-1.fc23.x86_64 java-1.7.0-openjdk-1.7.0-1.fc23.x86_64 java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 But user can easily remove packages which were installed to satisfy dependency, but which are no longer needed using autoremove command: sh-4.3# dnf -y autoremove Using metadata from Thu Feb 26 09:51:07 2015 Dependencies resolved. Package ArchVersion Repository Size Removing: java-1.7.0-openjdk x86_64 666:1.7.0-1.fc23@System0 Transaction Summary Remove 1 Package Installed size: 0 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Erasing : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 1/1 Verifying : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 1/1 Removed: java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23 After autoremove Java 7 is no longer installed: Complete! sh-4.3# rpm -qa | grep java java-1.8.0-1.fc23.x86_64 java-1.8.0-openjdk-1.8.0-1.fc23.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and "Legacy JDKs in Fedora guidelines" pages ___ Small restart. Looking to the discussion, although many people claimed "against any rules" at the end it seems to me that everybody agree on "some rules" - even if it would be existence of metapackage or only removed virtual provides and priority From that point of view, do you mind to help me to improve those rules? J. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 04:20 PM, Robert Marcano wrote: On 02/24/2015 05:04 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. I think for this to work, real work should be done by all Java packagers. There is no advantages of being able to install any community maintained legacy JDK if I can't use already packaged code. An example PostgreSQL JDBC driver is currently built with Java 8 bytecode level, it can't be used with any previous Java release. This happen because upstream developers frequently forget to add the --target javac command line argument for the minimum supported Java release they support (and work with upstream to add it). So a lot of packages need to be patched because they will target the built time Java bytecode level. The legacy jdk have not unvoulenteerly run this regular fedora-java stack code - never. Thats what those rules should achieve. The usage should be for third party development/usage only. J. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules.
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 04:26 PM, Aleksandar Kurtakov wrote: - Original Message - From: "Robert Marcano" To: devel@lists.fedoraproject.org Sent: Thursday, February 26, 2015 5:20:04 PM Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora On 02/24/2015 05:04 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. I think for this to work, real work should be done by all Java packagers. There is no advantages of being able to install any community maintained legacy JDK if I can't use already packaged code. An example PostgreSQL JDBC driver is currently built with Java 8 bytecode level, it can't be used with any previous Java release. This happen because upstream developers frequently forget to add the --target javac command line argument for the minimum supported Java release they support (and work with upstream to add it). So a lot of packages need to be patched because they will target the built time Java bytecode level. Now, this is the kind of work I would not do for my packages. There are 2 options for this to happen: * Interested person becomes maintainer of the package and takes care of such patching. I'll happily give maintainership to any such person. * Interested person fixes setting target upstream properly (note that this is double edged sword as target 1.5 would not work with Java 9 and requires keeping track). Once Fedora version is updated this would be fixed in Fedora. This should be out of scope. Nothing of javastack should be allowed to use use legacy jdk - see rule 7. Togehter with rule 2 it should prevent this happening. Alexander Kurtakov Red Hat Eclipse team === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight w
Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
On 02/26/2015 02:51 PM, Jiri Vanek wrote: On 02/24/2015 10:34 AM, Jaroslav Reznik wrote: = Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' option one - introducing new packages - preferred 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. option two - orphaning legacy jdks and ensure update path 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and "Legacy JDKs in Fedora guidelines" pages ___ Small restart. Looking to the discussion, although many people claimed "against any rules" at the end it seems to me that everybody agree on "some rules" - even if it would be existence of metapackage or only removed virtual provides and priority From that point of view, do you mind to help me to improve those rules? Looking to more inputs from https://fedorahosted.org/fpc/ticket/503 : Current state is fight between -legacy suffix and metapackage with provides. Excep
Re: F27 Self Contained Change: Java 9
On 04/19/2017 06:45 PM, James Hogarth wrote: So to be clear about this... The OpenJDK9 packages won't have a provides of "java" and the alternatives system won't prioritise this package over OpenJDK8? Hi! Yes you are right. It will not provide java, nor java-devel. Nor it will provide java-openjdk, java -devel-openjdk and similar. But it will provide versioned provides - java-9, java-devel-9, java-9-openjdk and similarly... As for alternatives, the package will be integrate in classical schema we provide, so you will be able to change it via alternatives --config java/javac/... For automode the priority will be 1, and of debug subpackages 0. so your statement about prioritise over OpenJDK8 eshould (must!) remain true. Thanx! J. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: F27 Self Contained Change: Decouple system java setting from java command setting
There are may reasons to not to do this change. At least not to do this as it is specified. Where is best place to discus? Discussion already started at java-proj...@redhat.com.[1] Please advice, J. [1] http://post-office.corp.redhat.com/archives/java-project/2017-June/date.html On 06/08/2017 03:55 PM, Jan Kurik wrote: = Proposed Self Contained Change: Decouple system java setting from java command setting = https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting Change owner(s): * Michael Simacek * Mikolaj Izdebski Alternatives can be used to specify which Java installation should be the default for the system. Currently, changing the default java command causes not only a change to the /usr/bin/java symlink, but also affects the which runtime is used for system installed Java applications. We propose introduction of separate setting for system-wide java applications. == Detailed Description == Fedora allows parallel installation of multiple Java runtime environments and it uses alternatives mechanism to allow the user to switch between them. JDK packages provide a set of alternatives symlinks for it's executables. The java symlink is used to determine the java command (/usr/bin/java), but also determines which runtime environment is used to run system-wide Java applications installed from RPMs, such as maven or eclipse. While in theory different Java runtime environments are drop-in replacements for each other, in practice some of the applications may stop working properly. Users usually install alternative JDKs in order to run their own applications and don't expect that changing the java command will have effect on the system applications. By introducing a separate setting for system-wide java, we would avoid this problem. We propose specifying default Java runtime for RPM-managed applications in /etc/java/java.conf (this is already possible, but not currently used). Administrators would still be able to override the system default if they need to. == Scope == * Proposal owners: Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf * Other developers: N/A (not a System Wide Change) * Release engineering: https://pagure.io/releng/issue/6831 * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Bump of giflib broken OpenJDK (and many other packages I guess)
Hi! Although it is more then nice to have giflib 5 in rawhide, I would encourage you to untag[1] it from rawhide, and prepare doubled packages in koji to give dependent packages time to rebuilt: 1) Find a provenpackager / releng member to work on rebuilding all the packages quickly (in dep order) 2) Introduce a libgif4 compat package with the old soname, to satisfy deps while the packages are being rebuilt. Right now any openjdk can not build, because it need itself to build. And old version still needs giflib4. So the build fail on dependency reolution. Many other packages will have similar problem, or will even need changes in code. Please really work around it quickly, as right now whole update proces of java packages is stopped. Thanx for updating libgif (and thanx for future time to fix it :) J. [1] koji untag-pkg f21 giflib-5.0.5-1.fc21 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: No mass rebuild in Fedora 25
Hello! this link > [1] https://meetbot.fedoraproject.org/teams/fesco/fesco.2016-01-08-17.22.html Do not explain more about the missing mass rebuild. Are there more infomration about? [2] https://fedoraproject.org/wiki/Releases/25/Schedule Thanx! J. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Creating an new update is failing
On 11/30/2016 07:10 PM, Patrick マルタインアンドレアス Uiterwijk wrote: Hi, Hello, I'm trying to create a new update and I'm getting this error: Builds : Unable to create update. Parent instance is not bound to a Session; lazy load operation of attribute 'release' cannot proceed The build looks fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=821471 Any ideas what the problem is? I'm very sorry for the problems here, they should now be fixed. Still not better :( J. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Creating an new update is failing
On 12/01/2016 10:55 AM, Jiri Vanek wrote: On 11/30/2016 07:10 PM, Patrick マルタインアンドレアス Uiterwijk wrote: Hi, Hello, I'm trying to create a new update and I'm getting this error: Builds : Unable to create update. Parent instance is not bound to a Session; lazy load operation of attribute 'release' cannot proceed The build looks fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=821471 Any ideas what the problem is? I'm very sorry for the problems here, they should now be fixed. Still not better :( Working now. TY! J. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33
On 3/30/20 5:11 PM, Miro Hrončok wrote: > On 30. 03. 20 16:04, Ben Cotton wrote: >> === Other === >> * Proposal owners: >> ** based on above, adapt jdk8 and jdk11 package provides >> ** If necessary tune the build environment >> >> * Other developers: >> ** based on selected approach to tune the main build tools >> *** at least jpackage-tools and maven will be very likely affected >> ** based on selected approach to tune the rpmbuild/macros >> ** many java package maintainers will maybe need to adapt theirs packages >> *** After the approach is agreed, mass rebuild must be performed >> *** FTBFS bugs connected with this proposal, maybe with jira ticket to >> allow discussion. Thank you for bringing it up! > > I don't understand who does all the hard work. Will the change owners just > change the default and go > away, or will the change owners handle the rebuilds? We will handle the tuning of jdk8 and jdk11 rpms. Also we will do an initial testing if it does what it should. Once it is done, mass rebuild is launched. we will then see. But it will be in on individual package owners to fix theirs packages. We will definitely help where necessary or where needed, and will most likely gather the most common cases, but to push to not-owned repos... only in critical cases. Of course we can reconsider, but it is not on powers of few (5?) individuals to fix 2500 packages, even if it will be only two or three most common cases. As for the runtime part, it is another story. There again we will do everything necessary to fix the problems both usptream and downstream, but the runtime casaes will flow up only in later stages of lifecycle of f33. Possibly even after f33 release. Note, that if there is serious runtime issues, then it would be really poorly written usptream application or very outdated downstream, not broken migration. Still the help will be attempted to be provided. > > As a side not, please don't mix in Jira tickets, that sounds RH internal to > me. Sure. If I did, then not intentionally. By jira ticket in the above I had in mind general ticket on pagure or similarly. The word jira did not belonged here. fixed the doc. > Thanx! thanx a lot, J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33
On 3/30/20 5:26 PM, Fabio Valentini wrote: > On Mon, Mar 30, 2020 at 4:05 PM Ben Cotton wrote: >> >> https://fedoraproject.org/wiki/Changes/Java11 . >> >> == Summary == >> Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk. >> >> == Owner == >> * Name: [[User:jvanek| Jiri Vanek]] >> * Email: >> * Product: java and java stack >> * Responsible WG: java-sig (java and java-maint) >> >> == Detailed Description == >> Fedora currently ships: >> * java-1.8.0-openjdk (LTS) >> * java-11-openjdk (LTS) >> * an java-latest-openjdk (on jdk14, STS). >> where the version-less '''java''' and '''javac''' (and friends) are >> provided by java-1.8.0-openjdk. >> >> So every package honoring the packaging rules and requiring java , >> java-headless or java-devel is built in brew by > > What is brew? Sorry, that was supposed to be koji. Fixed in the document. > >> java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in >> runtime (See [https://fedoraproject.org/wiki/Java java] ). Also >> javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime >> (see >> [https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting >> changes]) ... >> >> === "Political disclaimer" === >> In previous bumps, we, Red Hat's openjdk team, were a driving force to >> bump the system JDK. In this case, we are a bit reluctant, but the >> desire from users to bump the JDK seems strong. We are quite happy to >> skip JDK11 as system JDK at all, and jump directly from 8 to 17 in >> some three years. > > Skipping all the way from 8 → 17 sounds like there would be even more > potential for breaking things, so switching to 11 as an intermediary > step seems like a good idea to me. Right you are. thank you. > >> == Benefit to Fedora == >> JDK11 is out for some time, and most of the bleeding edge >> distributions already make it default. Most of the projects already >> adapted new features and make necessary forward-compatible chnages. >> Although we can can expect some family of packages to remain on jdk8 >> for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should >> flow] ... >> * Other developers: >> ** based on selected approach to tune the main build tools >> *** at least jpackage-tools and maven will be very likely affected >> ** based on selected approach to tune the rpmbuild/macros >> ** many java package maintainers will maybe need to adapt theirs packages >> *** After the approach is agreed, mass rebuild must be performed >> *** FTBFS bugs connected with this proposal, maybe with jira ticket to >> allow discussion. >> *** Solutions to most common errors should be gathered and published >> * Release engineering: [https://pagure.io/releng/issue/9347 9347] >> ** mass rebuild will be required for this change >> * Policies and guidelines: how to deal with build failures, eventually >> how to use some jdk11 specific build features will be provided >> * Trademark approval: N/A (not needed for this Change) > > I agree with Miro. These changes should be done in a side tag, or even > better, also tested in COPR before that. Kind of like how the python > 3.9 bringup is happening right now. This way, potential issues can be > caught early. Not sure how the coper cna be managed. As side tag, yes, woudl be awesome. > > Additionally, just switching 1.8.0 → 11 and walking away will probably > break rawhide packages for years to come, given the state the Java > stack is in. Some Java packagers / packages will definitely need some > help there. The Stewardship SIG can help with some issues (a few > members are provenpackagers), but our resources are limited, and we > "only" maintain ~200 Java packages directly. As replied to Miro. Help will definitely be provided. But direct touch to packages(two provenpackagers on board here), only in great need. Otherwise the few of us, incluing fwhat remained from java-sig, would get swamped. Hope that sounds reasonable. J. > > Fabio > > PS: I hope my post doesn't sound too negative. I'm happy this switch > is finally happening :) Not at all. Those must be clarified. Tahnx, cross fingers :) ___ 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
Re: Fedora 33 System-Wide Change proposal: java-11-openjdk as system JDK in F33
On 3/30/20 5:04 PM, Miro Hrončok wrote: > On 30. 03. 20 16:04, Ben Cotton wrote: >> * Contingency mechanism: Return jdk8 as system jdk and mass rebuild >> again. Note, that this may be very hard, because during build of >> packages by jdk8, by jdk11 built dependencies will be picekd up, so >> build will fail. Maybe several iterations of mass rebuild will be >> needed. > > Can we lease do this in a side tag instead and verify basic functionality > before we merge it to > rawhide? Than the contingency might just be: Don't merge the side tag. > Sounds like good idea..the way how to go. Only I'm not familiar with how it works. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
F33 system wide change, java-11-openjdk as system jdk
Hello fellow java package maintainers! We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see https://fedoraproject.org/wiki/Changes/Java11 Short Story: * if you have some java package, be aware that we are bumping JDK in rawhide * Ensure your package builds and runs fine with JDK11 (see the https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/) * there is special tooling ready for this, before mass rebuild is launched ** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild * If you do not want Fedora rotten with JDK8 for ever, continue reading Long Story: We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You can see, the result was quite dramatic: 1225 total; attempted to rebuild 483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that) 186 succeeded 556 orphans or dead or otherwise tragic so the build did not even start I would kindly ask you to search yourself in this list: https://jvanek.fedorapeople.org/java11/people If you are here, please check status of your package in https://jvanek.fedorapeople.org/java11/init (pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds). * If your package is "succeeded", congratulations nothing to do, and just keep en eye on JDK bump * If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it, please ensure it runs against JDK11 (see lower) * If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target lower then 1.6 JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or maybe it is enough to update to more fresh upstream release which supports JDK11? it may happen, that after the fix, your build will fail in more terrible way (see below) * If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years. Please, try to fix the package. Don't hesitate to ask on de...@fedoraproject.org or java-de...@fedoraproject.org or directly to me jva...@redhat.com. If you fix the fail, feel free to share your fix, it may help others. We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions . Feel free to enhance the page, or write us your case (possibly both with solution and without) so we can add it here. Debugging Your failures. The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this copr repo in several ways. * first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your build (select "all" instead of "25" at the bottom), ** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is build.log.gz. * anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in rawhide broken a bit currently) ** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it ** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use - https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg: sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg # change spec, bump sources, apply patches fedpkg srpm mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm Or any other packaging workflow you use, and you can use against the copr repo. Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard. Thank You! On behalf of Fedora java group 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.fedorapr
F33 system wide change, java-11-openjdk as system jdk
Hello fellow java package maintainers! We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk for F33. Please see https://fedoraproject.org/wiki/Changes/Java11 Short Story: * if you have some java package, be aware that we are bumping JDK in rawhide * Ensure your package builds and runs fine with JDK11 (see the https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/) * there is special tooling ready for this, before mass rebuild is launched ** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild * If you do not want Fedora rotten with JDK8 for ever, continue reading Long Story: We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy & comp for build. You can see, the result was quite dramatic: 1225 total; attempted to rebuild 483 failed; from those 191 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that) 186 succeeded 556 orphans or dead or otherwise tragic so the build did not even start I would kindly ask you to search yourself in this list: https://jvanek.fedorapeople.org/java11/people If you are here, please check status of your package in https://jvanek.fedorapeople.org/java11/init (pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds). * If your package is "succeeded", congratulations nothing to do, and just keep en eye on JDK bump * If there is "failed" but contains "- -" then it is probably orphan. If you wish to resurrect it, please ensure it runs against JDK11 (see lower) * If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target lower then 1.6 JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or maybe it is enough to update to more fresh upstream release which supports JDK11? it may happen, that after the fix, your build will fail in more terrible way (see below) * If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. JDK 11 is out for several years. Please, try to fix the package. Don't hesitate to ask on de...@fedoraproject.org or java-de...@fedoraproject.org or directly to me jva...@redhat.com. If you fix the fail, feel free to share your fix, it may help others. We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions . Feel free to enhance the page, or write us your case (possibly both with solution and without) so we can add it here. Debugging Your failures. The copr repo we maintain, contains builds of java-11-openjdk as system JDK, javapackages-tools honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this copr repo in several ways. * first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your build (select "all" instead of "25" at the bottom), ** Click its number, select chroot (currently fedora-32-x86_64 ) and check the logs. Main log is build.log.gz. * anything you push to rawhide, will automatically rebuild here in f32 chroot (we have a JDK in rawhide broken a bit currently) ** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it ** If yo need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use - https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . Eg: sudo cp downloaded-fedora-32-x86_64.cfg /etc/mock/jvanek-java11-fedora-32-x86_64.cfg # change spec, bump sources, apply patches fedpkg srpm mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm Or any other packaging workflow you use, and you can use against the copr repo. Thank you very much for your help, there are 500 failures, and 1000 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard. Thank You! On behalf of Fedora java group J. ___ devel-announce mailing list -- devel-annou...@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives
Re: F33 system wide change, java-11-openjdk as system jdk
elete, retired or somehow else utterly missing in action >> (see lower) >> 1 failed, from those 0 failed very quickly (see lower) >> >> Details: >> * Passed: N/A >> * Missing: N/A >> is/are probably orphan. If it is intentional, you may ignore it. If it is >> error, you should resurrect the package and if in that, ensure it runs >> against JDK11 (see failed) >> * Failed, suspiciously quickly: N/A >> those packages failed so quickly, that the build was in initial phases. That >> usually mean that you build with source/target lower then 1.6 JDK11 supports >> 1.6 and up. We recommend to bump the source/target to 1.8, to allow >> existence of compact 1.8 packages alongside main javastack. See >> https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. >> Don't forget to upstream the patch, or maybe it is enough to update to more >> fresh upstream release which supports JDK11? it may happen, that after the >> fix, your build will fail in more terrible way (see bellow) >> * Failed: rstudio >> those packages failed. Very often the scary error may be fixed by bump to >> latest upstream version. JDK 11 is out for several years. Please, >> try to fix the package. Don't hesitate to ask on >> devel@lists.fedoraproject.org or java-de...@lists.fedoraproject.org or >> directly to me jva...@redhat.com. If you fix the fail, feel free to share >> your fix, it may help others. >> We are trying to gather the most common issues at >> https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions >> . Feel free to enhance the page, or write us your case (possibly both with >> solution and without) so we can add it here. >> >> >> Debugging Your failures. >> The copr repo we maintain, contains builds of java-11-openjdk as system JDK, >> javapackages-tools honoring that, and java-1.8.0-openjdk as non system JDK. >> Also it contains successfully rebuilt packages. You can directly use this >> copr repo in several ways. >> * first glance on error. On >> https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your >> build (select "all" instead of "25" at the bottom), >> ** Click its number, select chroot (currently fedora-32-x86_64 ) and check >> the logs. Main log is build.log.gz. >> * anything you push to rawhide, will automatically rebuild here in f32 >> chroot (we have a JDK in rawhide broken a bit currently) >> ** It is the best approach. If you can fix your package in rawhide >> directly, without breaking the rawhide too much, go for it >> ** If you need to experiment, I have a mock config for you (generated from >> copr-cli mock-config jvanek/java11 fedora-32-x86_64) which you can copy to >> your /etc/mock and use - >> https://jvanek.fedorapeople.org/java11/jvanek-java11-fedora-32-x86_64.cfg . >> Eg: >> >> sudo cp downloaded-fedora-32-x86_64.cfg >> /etc/mock/jvanek-java11-fedora-32-x86_64.cfg >> or >> cp downloaded-fedora-32-x86_64.cfg >> ~/.config/mock/jvanek-java11-fedora-32-x86_64.cfg >>then >> # change spec, bump sources, apply patches >> fedpkg srpm >> mock -r jvanek-java11-fedora-32-x86_64 *.src.rpm >> >> Or any other packaging workflow you use, and you can use against the copr >> repo. >> Thank you very much for your help, there are 500 failures, and 1000 java >> packagers, but only 2 active members of java sig. Without your help, the JDK >> bump will be very hard. >> >> Thank You! >> J. >> >> Those should be links to build logs: >> FAIL >> https://download.copr.fedorainfracloud.org/results/jvanek/java11/fedora-32-x86_64/01355829-rstudio/build.log.gz >> MISSING: N/A >> >> -- >> Jiri Vanek >> jva...@redhat.com >> +420 775 39 01 09 >> > > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: F33 system wide change, java-11-openjdk as system jdk
On 5/4/20 11:15 AM, Iñaki Ucar wrote: > Hi, thanks for your assistance, comments inline: > > On Mon, 4 May 2020 at 10:48, Jiri Vanek wrote: >> >> Generally, no program can say, that do not support jdk11, because any >> javac/java application can be >> *hacked* to work with java11 - see >> https://jvanek.fedorapeople.org/devconf/2017/portingjavaInternalToJdk9/portingOfItwToJdk9-II.pdf >> (really all except package split over modules, which is impossible) >> >> Now above mentione approaches are indeed *hacked*, and I discourage >> everybody to do so. > > As you mentioned below, I depend on GWT, and it's waaay to complex to > take this approach. > >> If you package is really bound to jdk8, you can move to the version-full >> requires: >> BuildRequires: java-1.8.0-openjdk-devel (or java-devel <= 1:1.8.0 or similar) >> ... >> Requires: java-1.8.0-openjdk(-headless) (or java(-headless) <= 1:1.8.0 or >> similar) >> >> However there is an trap - packages you depends on. Once some of your >> dependencies will be compiled >> with --target > 8, you are doomed, and you have to bundle it or create its >> compact version. By doing >> so you can easily end in dependency hell. > > RStudio only uses Java to compile a series of web components during > build time. Then, the requires are clean from Java components, and its > usage doesn't invoke the JVM. So it's been identified as a Java app > because build-requires java-devel, but it's not really a Java app. > >> With GWT, I'm afraid you will need to try this approach, as it is to >> complex framework that any >> hacking on this field is really risky. And I'm sorry to hear they are not on >> jdk11 already, as this >> fate can likely met many other packages. > > They build against a very specific version of GWT, and that's why it's > bundled. Future versions will update GWT and we will probably be able > to use Java 11. Let's see. > >> Looking to spec of rstudio, and considering it have nearly no not-bundled >> dependence, and its >> upstream being stuck on jdk8, requiring jdk8 looks like correct step for a >> while. If yo have any >> influence in upstream, please be force GWT to move to jdk11. >> Be aware, that you may end in needing to adapt also launcher, as >> japackage-tools will be enforcing >> java-11-openjdk. You can easily do it by exporting JAVA_HOME with >> /usr/lib/jvm/java-1.8.0-openjdk value >> >> Good luck, >> Please let me know once you success with it. I willa dd an chapter to >> https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions > > Thanks, but as I said above, the RStudio rpms don't pull the JVM, > because it's not required at runtime. So I suppose that, beyond fixing > the java-devel version in BuildRequires, I don't need to do anything > more, right? Hopefully:) TYVM! > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: F33 system wide change, java-11-openjdk as system jdk
On 5/4/20 12:59 PM, Iñaki Ucar wrote: > On Mon, 4 May 2020 at 11:22, Jiri Vanek wrote: >> >>> Thanks, but as I said above, the RStudio rpms don't pull the JVM, >>> because it's not required at runtime. So I suppose that, beyond fixing >>> the java-devel version in BuildRequires, I don't need to do anything >>> more, right? >> >> Hopefully:) TYVM! > > On second thought, there's one potential problem. The build process > requires ant. If ant is built against Java 11 and I require java-devel > <= 1:1.8.0, is that an issue? > It can be a serious issue, if ant will be compiled with target > 8. Except that, it should be working fine, but yuou will be i mercy of ant maintainers. If they cooperate, it should work for next two or three years. J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: F33 system wide change, java-11-openjdk as system jdk
Hello! An raw schedule of mass rebuilds was added to the Java11 feature list: https://fedoraproject.org/wiki/Changes/Java11#Expected_schedule You can expect second copr-based mass rebuild, in 1st June 2020. Please try to fix your packages until then, as on the result of this mass rebuild, future steps will be based. Thanx! J. On 4/30/20 6:29 PM, Jiri Vanek wrote: > Hello fellow java package maintainers! > > We are planning to bump the JDK from java-1.8.0-openjdk to java-11-openjdk > for F33. Please see > https://fedoraproject.org/wiki/Changes/Java11 > > Short Story: > * if you have some java package, be aware that we are bumping JDK in rawhide > * Ensure your package builds and runs fine with JDK11 (see the > https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/) > * there is special tooling ready for this, before mass rebuild is launched > ** See https://fedoraproject.org/wiki/Changes/Java11#copr_preliminary_rebuild > * If you do not want Fedora rotten with JDK8 for ever, continue reading > > Long Story: > We ran a preliminary mass rebuild of javastack in copr repo > https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ (select "all" > instead of "25" at the > bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy > & comp for build. You > can see, the result was quite dramatic: > 1225 total; attempted to rebuild > 483 failed; from those 191 are trivial failures (but if you fix it, there > is no guarantee real > troubles are not hidden behind that) > 186 succeeded > 556 orphans or dead or otherwise tragic so the build did not even start > > I would kindly ask you to search yourself in this list: > https://jvanek.fedorapeople.org/java11/people > If you are here, please check status of your package in > https://jvanek.fedorapeople.org/java11/init > (pain text of https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds). > * If your package is "succeeded", congratulations nothing to do, and just > keep en eye on JDK bump > * If there is "failed" but contains "- -" then it is probably orphan. > If you wish to resurrect it, > please ensure it runs against JDK11 (see lower) > * If there is "failed" but failed in "seconds", then those packages failed > so quickly, that the > build was in initial phases. That usually mean that you build with > source/target lower then 1.6 > JDK11 supports 1.6 and up. We recommend to bump the source/target to 1.8, to > allow existence of > compact 1.8 packages alongside main javastack. See > https://fedoraproject.org/wiki/Changes/Java11#Wrong_source.2Ftarget_version. > Don't forget to > upstream the patch, or maybe it is enough to update to more fresh upstream > release which supports > JDK11? it may happen, that after the fix, your build will fail in more > terrible way (see below) > * If there is "failed", and its none of above, then your package simply > failed. Very often the > scary error may be fixed by bump to latest upstream version. JDK 11 is out > for several years. > Please, try to fix the package. Don't hesitate to ask on > de...@fedoraproject.org or > java-de...@fedoraproject.org or directly to me jva...@redhat.com. If you fix > the fail, feel free to > share your fix, it may help others. > We are trying to gather the most common issues at > https://fedoraproject.org/wiki/Changes/Java11#common_issues_packagers_can_face_and_gathered_solutions > . > Feel free to enhance the page, or write us your case (possibly both with > solution and without) so > we can add it here. > > Debugging Your failures. > The copr repo we maintain, contains builds of java-11-openjdk as system JDK, > javapackages-tools > honoring that, and java-1.8.0-openjdk as non system JDK. Also it contains > successfully rebuilt > packages. You can directly use this copr repo in several ways. > * first glance on error. On > https://copr.fedorainfracloud.org/coprs/jvanek/java11/builds/ find your > build (select "all" instead of "25" at the bottom), > ** Click its number, select chroot (currently fedora-32-x86_64 ) and check > the logs. Main log is > build.log.gz. > * anything you push to rawhide, will automatically rebuild here in f32 > chroot (we have a JDK in > rawhide broken a bit currently) > ** It is the best approach. If you can fix your package in rawhide directly, > without breaking the > rawhide too much, go for it > ** If yo need to experiment, I have a mock config for you (generated from > copr-cli mock-config > jvanek/java11 fedora-32-x86_64) which you can copy to your /etc/mock and use - > https://jvanek.
Re: Switching Maven and Ant to OpenJDK 11
any package can switch to jdk11, but sysem jdk should be jdk8, at least for some more time... On 10/25/19 8:47 PM, Miro Hrončok wrote: > On 25. 10. 19 19:30, Mikolaj Izdebski wrote: >> Hello, >> >> Currently default Java runtime in Fedora is OpenJDK 8. This is not the >> latest OpenJDK packaged, but still remains system-default version. >> Because of that Apache Maven and Apache Ant in Fedora are built using >> OpenJDK 8 and run on OpenJDK 8. >> >> I am planning to switch Maven 3.6 and Ant 1.10 modules to build with >> and run on OpenJDK 11, which is the latest LTS release of OpenJDK. >> This also means that future streams of javapackages-tools module will >> default to use OpenJDK 11 for building packages. Please let me know if >> you have any concerns. > > Hello, I am not very familiar with how Java works in this regard, but since > this is the default > stream etc., wouldn't it be wise to coordinate such change with a general > OpenJDK 11 default Fedora > system wide change? > > E.g. would the dependent OpenJDK 8 packages still build in stable releases if > this change is done > globally and for example if Ursa Major/Prime/... is activated? > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] Re: Switching Maven and Ant to OpenJDK 11
On 10/26/19 4:33 PM, Neal Gompa wrote: > On Sat, Oct 26, 2019 at 9:53 AM Jiri Vanek wrote: >> >> any package can switch to jdk11, but sysem jdk should be jdk8, at least for >> some more time... >> > > If anything, we're late to the party of moving to JDK 11 by default. > Java 8 has been EOL for a while now. > Oh this is heavily incorrect. JDK8 is very much alive, and fully supported by upstream. Will be getting all security patches and also many enhancements for several another years. > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: [fedora-java] Re: Switching Maven and Ant to OpenJDK 11
On 10/28/19 12:38 PM, Neal Gompa wrote: > On Mon, Oct 28, 2019 at 6:04 AM Andrew Dinn wrote: >> >> On 26/10/2019 15:33, Neal Gompa wrote: >>> If anything, we're late to the party of moving to JDK 11 by default. >>> Java 8 has been EOL for a while now. >> Please do not spread misinformation like this. It is very unhelpful. >> > > Okay, sure, paid support continues for two more years, but general > (freely available) support for Java 8 ended in January. > > For most of us peons, general support EOL is functionally equivalent > to full EOL. That's why we end EPEL support on general support EOL > dates, and not the more nebulous LTSS EOL dates. > Hi Neal, you are really wrong. Openjdk8 is, and will remain fully supported for few next years. We are not speaking about any commercial support, we are speaking about free and open support, provided by project groups, which consists from nearly all oepnjdk8 interested corporations, and namely RH, which is Openjdk8 project lead, and hundreds of community members. Please really do not spread miss-informations like this. J. > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 7/15/19 11:34 AM, Vitaly Zaitsev via devel wrote: > Hello, Dridi Boukelmoune. > > Mon, 15 Jul 2019 08:26:59 + you wrote: > >> Emulate as in not run natively even though the hardware might be able to? > > Sorry for misinformation. Wine64 is still require 32-bit libraries in > order to run legacy 32-bit Windows PE executables. > > https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F Exactly. I really do not understand this rush change. The original change, to remove only 32 kernel is definitely the way to go. But This one, should be postponded to f32, with much better contingency plan. > > > -- > 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 > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On 7/15/19 9:10 AM, Vitaly Zaitsev via devel wrote: > Hello, Dridi Boukelmoune. > > Mon, 15 Jul 2019 06:59:33 + you wrote: > >> game that cannot move to 64bit support because it's dragging binaries >> for which it doesn't have source code. > > Wine64 can still emulate 32-bit WinPE executables. That is not enough. See what hapened to Ubuntu once they dropped i686 > > -- > 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 > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jva...@redhat.comM: +420775390109 ___ 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
Re: Node.js repackaging status and questions
Hello! I woudl like to - https://fedoraproject.org/wiki/Changes/NodejsRepackaging#Feedback - add, that also java is using alternatives for major versions of jdk switching. Weahve master java - to switch runtime, and javac to switch devel subpackages. Man pages are also slaves to the java/javac master so the always corespond to the proper selected java. I would heavily recomend to use alternatives for this,a nd thus remain aligned with other major runtimes. One more reason to use alternatives might be theirs future - build over overlayfs, an *userspace* version of alternatives is being.. discussed ( I would realy lke to say developed, but it seems it is still ony on paper). Still the proof of concept already existed. Thanx! J. On Sat, 1 Apr 2023 at 12:04, Iñaki Ucar wrote: > > Hi, > > As a brief summary: > > - The Node.js repackaging change [1-2] was accepted for F38. > - Packages nodejs16 and nodejs18 were created without any review [3-4] (?). > - Package nodejs20 was created a month ago, but I didn't find any > review request. Why? > - This repackaging has been pushed to F37 too. Why, if this was a F38 change? > - Now we have conflicts in F37 and F38 [5], with FTBFS for those > requiring unversioned nodejs. > > It seems to me that there hasn't been a proper review and tracking of > this change. > > [1] https://fedoraproject.org/wiki/Changes/NodejsRepackaging > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2130002 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=2150093 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=2150094 > [5] https://bugzilla.redhat.com/show_bug.cgi?id=2179086 > > -- > Iñaki Úcar > ___ > 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 ___ 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)
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)
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. 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 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)
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, J. 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 -- 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 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)
> 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)
> 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)
> 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)
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)
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 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.
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)
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. 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:( 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. +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. See my reply I ha just sent to Robert. Thanx! J. - 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)
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 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 6/2/23 01:09, Kevin Kofler via devel wrote: Demi Marie Obenour wrote: I haven’t written Java in years, but my understanding is that AOT compilation has three major advantages: 1. It reduces the size of total deliverables because the final executable only includes the libraries it needs. This may be true for real AOT compilation where the result is really independent of a JRE (e.g., what GCJ, which is no longer maintained, used to produce by default), but if the AOT compilation requires you to bundle the whole JRE (and that is the only case where having a statically vs. dynamically linked JRE matters), the total deliverable size is going to be much larger. Interesting discusson, indeed! The aot should create portable minialistic image. If you build it from dynamicaly linked JDK, iirc, the image will not be trasnferable (as it will still require those dynamicaly linked libraries). As fot rhe size, werer the goal of minimalistic was there, it si proving to not be exactly true, and final iage is quite big. 2. It is the _only_ way to have decent performance on platforms where JIT compilation is forbidden. That is also irrelevant in this thread: If it matters how the JRE is linked, the AOT-compiled output includes a bundled copy of the GNU/Linux JRE (otherwise why would it matter?), so it will only run on GNU/Linux, which is NOT a "platform where JIT compilation is forbidden". (There is only really one such platform, iOS with Apple's totalitarian app store rules.) Java without JIT is useles for anythingbigger then hello world:( 3. AOT-compiled apps start up faster and use less memory. That part may be true, but there too, if we are talking about a solution that includes bundling the JRE, I doubt it. This is actually the only reason I'm finding as really valid. In world of micro services, which even run with epsilongc, this is saving enourmous resources. > necessary because Java applications are NOT designed to be built like native > applications (e.g., pure AOT compilation without a JIT and/or interpreter > fallback cannot handle classes loaded at runtime, such as dynamically > generated or downloaded class files). Many applications worked with GCJ only I agree that java is not designed tobebuilt lilenative app, and that is why gaarl/mandrel and qaurkus are so terribly complicated. Future will show. Thanx! J. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
es-sk orphan 0 weeks ago mythes-sl orphan 0 weeks ago mythes-sv orphan 0 weeks ago mythes-uk orphan 0 weeks ago openoffice-lv orphan 0 weeks ago openoffice.org-diafilter orphan, sbergmann0 weeks ago pentaho-libxmlorphan, sbergmann0 weeks ago pentaho-reporting-flow-engine orphan 0 weeks ago rasqalkde-sig, orphan, rdieter 0 weeks ago redland jreznik, orphan, rdieter, than 0 weeks ago sac orphan 0 weeks ago writer2latex orphan, sbergmann0 weeks ago zaf orphan 0 weeks ago zxing-cpp orphan, sbergmann, tdawson 0 weeks ago 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)
Hello! I have updated contingency plan: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#Contingency_Plan / https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=679828&oldid=679493 Sorry for not writing this out of the box. It was written so many times I consider it as "widely known" but obviously I was wrong. Sorry for that. J. On Tue, 30 May 2023 at 20:38, Aoife Moloney wrote: > > 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. > > == Owner == > > * Name: [[User:jvanek| Jiri Vanek]] > * Email: jva...@redhat.com > > > == Detailed Description == > > 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. > > * 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 > > * 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. > > 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. > > == Feedback == > > > == 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. > > If we fail to build once and repack everywhere, java maintainers will > most likely need to lower the number of JDKs in fedora to system one > only. > > == Scope == > * Proposal owners: Technically all jdks (except 8, where some more > tuning is needed, and epels for java-latest) are prepared, as they > have portable version, and rpms just reapck it. Except tuning up the > jdk8 and epel for latest, scope owners are done. > > > * Other developers: There will be needed significant support from RCM > and maybe senior fedora leadership to help to finish the build in > oldest and enable to repack everywhere Aoife Moloney > > Product Owner > > Community Platform Engineering Team > > Red Hat EMEA > > Communications House > > Cork Road > > Waterford > ___ > 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 ___ 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: Allow Removal of tzdata (System-Wide)
JDK will behave similarly. We ave (small) advantage that we have also
in-jdk-bundled tzdata. However fallback in case of removed system
tzdata is not automatic, and requires human touch. Long ago we have a
patch in jdk which looked to system tzdata - if they were present,
they were used. If not, the bundled copy was used. Also user could
set up on startup which to use. But it had not prooved itself, as it
was casue of weird missonfigurations.
If this proposal will come live, we may introduce this patch again, or
leave it as it is now - on human touch.
TY!
J.
On Tue, 27 Jun 2023 at 11:00, Miro Hrončok wrote:
>
> On 26. 06. 23 20:24, Fabio Valentini wrote:
> > On Mon, Jun 26, 2023 at 8:10 PM Miro Hrončok wrote:
> >>
> >
> > (snip)
> >
> >> ---
> >>
> >> The current problem with Python without tzdata is:
> >>
> >> ===
> >> >>> from zoneinfo import ZoneInfo
> >> >>> ZoneInfo("Europe/Prague")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key
> >> Europe/Prague'
> >> ===
> >>
> >> Not that ZoneInfo("UTC") also fails:
> >>
> >> ===
> >> >>> ZoneInfo("UTC")
> >> Traceback (most recent call last):
> >> ...
> >> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> >> ===
> >>
> >> So we would need to patch Python to detect missing tzdata and report
> >> something
> >> like:
> >>
> >>ZoneInfoNotInstalledError: 'No time zone information installed on the
> >> system,
> >> you can only use UTC'
> >>
> >> We would also need to ensure UTC work even without tzdata installed.
> >>
> >> I would be reluctant to carry this as a downstream-only patch. And the
> >> upstream
> >> window for changes like this has already closed for Python 3.12.
> >
> > Does this mean that tzdata needs to be present for doing datetime /
> > timezone calculations at runtime with the zoneinfo module?
>
> Yes. That's why it is Required and not Recommended.
>
> > Would this Change require that all Python programs that use this
> > module add "Requires: tzdata"? I don't think that would be a
> > reasonable change.
>
> Either that or adapt their code to fail in a reasonable way. Both sound quite
> unreasonable to me.
>
> > There's a similar issue with some Rust libraries (and probably other
> > language-specific timezone handling libraries), where they explicitly
> > assume that the timezone database is available, and will either fail
> > (bad case) or fall back to UTC (less bad case). Similar to the Python
> > case, I don't think adding "Requires: tzdata" to all packages like
> > these (either to the library in the case of dynamically linked /
> > scripting languages, or to all affected *applications* in the case of
> > statically linked languages) would be reasonable.
>
> Thanks for sharing a similar concern.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
___
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) - Proposal Addendum
Hi Tom! Thanx a lot of for input. Although I did my bes with the tagging, it will be learning on the go. I had adapted https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution as you suggested. It is great improvement. Especially the config, I was not aware about. That woudl indeed help a lot. The usage of pernament tag is someging I have to learn, but is moreover necessary for proper srpm rebuil. TYVM! J. On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > > On 6/26/23 09:21, Aoife Moloney wrote: > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > > > > 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 > > tarballs into RPMs. Currently, the portable 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 repack in > > all live Fedoras. If jdk is buitl in epel, it will be built in oldest > > possible epel and repacked in newer live epels. > > > > > > == Owner == > > * Name: [[User:jvanek| Jiri Vanek]] > > > > * Email: jva...@redhat.com > > > > > > == Detailed Description == > > > > As described in > > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > > during last year, packaging of JDKs had changed dramatically. As > > described in the same wiki page and in individual sub changes and > > devel threads, the primary reason for this is to lower maintenance and > > still keep Fedora Java friendly. > > > > * In the first system wide change, we have changed the JDKs to build > > properly as standalone, portable JDK - the way 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 upstream, but this > > has become a fight which can not be won. > > > > * As a second step we introduced portable RPMs, which do not have any > > system integration, only build JDK and pack the final tarball in RPM > > for Fedora 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. > > > > 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 latests STS JDK - currently 20, soon briefly 21 and a bit > > after 22... If we would built java-latest-openjdk in oldest live EPEL > > - epel8 now, we have verified, that such repacked JDKs works fine, > > however repack from epel seem to not be acceptable, thus > > ajva-latest-openjdk will be built twice - one in oldest live fedora, > > and once in oldest live epel. Build forme oldest possible epel will be > > repacked to that one or newer epels, and build from oldest live fedroa > > to all fedoras. > > > > === theoretical tagging solution === > > > >1. request side tags for all releases > >2. build the actual Java in the side tag for the oldest thing > > Could you use the real package name here. I think that will make it easier > to understand. You can still put 'actual Java' in parens or something. > > >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) > > Same thing here, can you use the real package name. > > >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. > > > > Yes, we could make a 'fN-openjdk' tag and mark it protected... that part > > would be easy enough. > >
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several time in the proposal. Still the https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution adjusted Tahnx! On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: > > On 6/29/23 09:52, Jiri Vanek wrote: > > Hi Tom! > > > > Thanx a lot of for input. Although I did my bes with the tagging, it > > will be learning on the go. > > I had adapted > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > as you suggested. It is great improvement. > > > > Thanks, this looks better. > > For step 5. should the first mention of java-xy-openjdk-portable actually > be java-xy-openjdk ? Same question for step 7. > > -Tom > > > Especially the config, I was not aware about. That woudl indeed help a lot. > > The usage of pernament tag is someging I have to learn, but is > > moreover necessary for proper srpm rebuil. > > > > TYVM! > > J. > > > > On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > >> > >> On 6/26/23 09:21, Aoife Moloney wrote: > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > >>> > >>> 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 > >>> tarballs into RPMs. Currently, the portable 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 repack in > >>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest > >>> possible epel and repacked in newer live epels. > >>> > >>> > >>> == Owner == > >>> * Name: [[User:jvanek| Jiri Vanek]] > >>> > >>> * Email: jva...@redhat.com > >>> > >>> > >>> == Detailed Description == > >>> > >>> As described in > >>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > >>> during last year, packaging of JDKs had changed dramatically. As > >>> described in the same wiki page and in individual sub changes and > >>> devel threads, the primary reason for this is to lower maintenance and > >>> still keep Fedora Java friendly. > >>> > >>> * In the first system wide change, we have changed the JDKs to build > >>> properly as standalone, portable JDK - the way 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 upstream, but this > >>> has become a fight which can not be won. > >>> > >>> * As a second step we introduced portable RPMs, which do not have any > >>> system integration, only build JDK and pack the final tarball in RPM > >>> for Fedora 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. > >>> > >>> 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 latests STS JDK - currently 20, soon briefly 21 and a bit > >>> after 22... If we would built java-latest-openjdk in oldest live EPEL > >>> - epel8 now, we have verified, that such repacked JDKs works fine, > >>> however repack from epel seem to not be acceptable, thus > >>> ajva-latest-openjdk will be built twice - one in oldest live fedora, > >>> and once in oldest live epel. Build forme oldest possible epel will be > >>> repacked to that one or newer epels, and build from oldest live fedroa > >>> to all fedoras. > >>> > >>> === theoretical tagg
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Hi Kevin! I'm unabel to answer that. First release will be a bit experiemntal for sure. But final target is sure - to persist the underlying portables and to enable srpm rebuild as comfortably as possible. As far rawhide itself, as it is unreleased distro, if no other paths will remain, rawhide may remian self building. Aka using protbales from rawhide to buidl rawhide's rpms. Thax! On Thu, 29 Jun 2023 at 19:43, Kevin Fenzi wrote: > > On Thu, Jun 29, 2023 at 10:14:31AM -0700, Tom Stellard wrote: > > On 6/29/23 09:52, Jiri Vanek wrote: > > > Hi Tom! > > > > > > Thanx a lot of for input. Although I did my bes with the tagging, it > > > will be learning on the go. > > > I had adapted > > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > > as you suggested. It is great improvement. > > > > > > > Thanks, this looks better. > > > > For step 5. should the first mention of java-xy-openjdk-portable actually > > be java-xy-openjdk ? Same question for step 7. > > I don't think the fixed sidetag idea will work. (Unless you are planning > on doing something different with rawhide). > > Bodhi won't let you make an update from a non sidetag tag, so you would > have to tag them into fN-updates-candidate, but then they would go one > by one into rawhide and not be tested/gated as a unit. > > But of course we could do fixed tags for stable releases and have a > sidetag flow for rawhide, but that might make things more confusing. > > kevin > ___ > 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 ___ 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) - Proposal Addendum
nn. You were right. There are going to be two separated packages. Portable, built once in oldest live, and "normal" which is going to repack them for all and shipp them. My apologise for typo in last second change: https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=681794&oldid=681791 narrowed. On Thu, 29 Jun 2023 at 21:16, Tom Stellard wrote: > > On 6/29/23 11:06, Jiri Vanek wrote: > > Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several > > time in the proposal. Still the > > https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > > adjusted > > > > OK, I see. I thought there were going to be two different packages. > java-xy-openjdk-portable > and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped in > Fedora and > java-xy-openjdk-portable lives only in the side-tags. > > -Tom > > > Tahnx! > > > > On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: > >> > >> On 6/29/23 09:52, Jiri Vanek wrote: > >>> Hi Tom! > >>> > >>> Thanx a lot of for input. Although I did my bes with the tagging, it > >>> will be learning on the go. > >>> I had adapted > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > >>> as you suggested. It is great improvement. > >>> > >> > >> Thanks, this looks better. > >> > >> For step 5. should the first mention of java-xy-openjdk-portable actually > >> be java-xy-openjdk ? Same question for step 7. > >> > >> -Tom > >> > >>> Especially the config, I was not aware about. That woudl indeed help a > >>> lot. > >>> The usage of pernament tag is someging I have to learn, but is > >>> moreover necessary for proper srpm rebuil. > >>> > >>> TYVM! > >>>J. > >>> > >>> On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > >>>> > >>>> On 6/26/23 09:21, Aoife Moloney wrote: > >>>>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > >>>>> > >>>>> 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 > >>>>> tarballs into RPMs. Currently, the portable 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 repack in > >>>>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest > >>>>> possible epel and repacked in newer live epels. > >>>>> > >>>>> > >>>>> == Owner == > >>>>> * Name: [[User:jvanek| Jiri Vanek]] > >>>>> > >>>>> * Email: jva...@redhat.com > >>>>> > >>>>> > >>>>> == Detailed Description == > >>>>> > >>>>> As described in > >>>>> https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > >>>>> during last year, packaging of JDKs had changed dramatically. As > >>>>> described in the same wiki page and in individual sub changes and > >>>>> devel threads, the primary reason for this is to lower maintenance and > >>>>> still keep Fedora Java friendly. > >>>>> > >>>>> * In the first system wide change, we have changed the JDKs to build > >>>>> properly as standalone, portable JDK - the way 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 upstream, but this > >>>>> has become a fight which can not be won. > >>>>> > >&g
Re: F39 Change Proposal: Build JDKs once, repack everywhere (System-Wide) - Proposal Addendum
Once the portables will be built in f37, the repacked binary in f37 and in f38 (39...)will be identical. Rpms have some additional value - split to subpakcages, few symlinks due to system integration, system tzdata, system crypto binding and so on. On Thu, 29 Jun 2023 at 22:20, Tom Stellard wrote: > > On 6/29/23 13:07, Jiri Vanek wrote: > > nn. You were right. There are going to be two separated packages. > > Portable, built once in oldest live, and "normal" which is going to > > repack them for all and shipp them. > > My apologise for typo in last second change: > > https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=681794&oldid=681791 > > > > narrowed. > > > > Ok, that makes sense now. > > My next question is what is the difference between the > java-xy-openjdk-portable package > that is built on f37 and the repacked java-xy-openjdk package that is shipped > on f38. > Are the bits inside the package exactly the same? > > -Tom > > > On Thu, 29 Jun 2023 at 21:16, Tom Stellard wrote: > >> > >> On 6/29/23 11:06, Jiri Vanek wrote: > >>> Nope, xy stands for 1.8.0, 11, 17 and latest. It is enumerated several > >>> time in the proposal. Still the > >>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > >>> adjusted > >>> > >> > >> OK, I see. I thought there were going to be two different packages. > >> java-xy-openjdk-portable > >> and java-xy-openjdk. Where java-xy-openjdk is the one that gets shipped > >> in Fedora and > >> java-xy-openjdk-portable lives only in the side-tags. > >> > >> -Tom > >> > >>> Tahnx! > >>> > >>> On Thu, 29 Jun 2023 at 19:14, Tom Stellard wrote: > >>>> > >>>> On 6/29/23 09:52, Jiri Vanek wrote: > >>>>> Hi Tom! > >>>>> > >>>>> Thanx a lot of for input. Although I did my bes with the tagging, it > >>>>> will be learning on the go. > >>>>> I had adapted > >>>>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution > >>>>> as you suggested. It is great improvement. > >>>>> > >>>> > >>>> Thanks, this looks better. > >>>> > >>>> For step 5. should the first mention of java-xy-openjdk-portable actually > >>>> be java-xy-openjdk ? Same question for step 7. > >>>> > >>>> -Tom > >>>> > >>>>> Especially the config, I was not aware about. That woudl indeed help a > >>>>> lot. > >>>>> The usage of pernament tag is someging I have to learn, but is > >>>>> moreover necessary for proper srpm rebuil. > >>>>> > >>>>> TYVM! > >>>>> J. > >>>>> > >>>>> On Wed, 28 Jun 2023 at 21:31, Tom Stellard wrote: > >>>>>> > >>>>>> On 6/26/23 09:21, Aoife Moloney wrote: > >>>>>>> https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6) > >>>>>>> > >>>>>>> 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 > >>>>>>> tarballs into RPMs. Currently, the portable 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 repack in > >>>>>>> all live Fedoras. If jdk is buitl in epel, it will be built in oldest > >>>>>>> possible epel and repacked in newer live epels. > >>>>>>> > >>>>>>&g
small aarch64 home server
Hello! My rpi based home base server died rpi NAS keep running:). I would very like to replace it with little bit better thing - in work, I have https://softiron.com/blog/news_20160624/ , unluckily, It seems that similar machines - I can call it aarch64 desktop, somehow died off. Does anybody have any tips for similar machines? As for tech spec - strongest rpi *2 :); 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: Inactive packagers to be removed after the F37 release
Just very minor contribution to alrready very complex trhead. - to remove packager status if they are not using it, is just wrong. OpenJDK was using it far years and it really did not proved itself. Now OpenJDK have policy, that once you earn any status, you remain with it. The downgrade or no longer propagated status (eg form project to project) was super confussing and made more issues then it solved. Now it is much better. - to remove proven packager status, if they are nto using proven packagers powers, is similarly wrong. Well, if there is email with deadlnie.. then maybe... As for my case - I'm not using my proven packager powers, but once per two years, I'm bumping system JDK. And n that moment I'm using my proven packager skill heavily. So hard timeout, would again do just confussion (like negotiating proven packager status again 5 minutes before dealines) I belive all liek thsi was already said Thanx all for making fedora just better and better! J. On 9/3/22 22:04, Kevin Fenzi wrote: On Sat, Sep 03, 2022 at 12:24:11PM -0700, Adam Williamson wrote: So, I have a probably-controversial idea for a follow-up on this. Even after this sweep, we have 141 proven packagers. That's a lot of people who can build almost anything in Fedora. It should be possible to check whether a provenpackager has built any package they don't have direct commit rights to in the last X months. Should we construct that search, run it, and propose removing provenpackager status from folks who aren't using it, to cut down that set? That policy was setup before this one for packagers. ;) https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ kevin ___ 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: small aarch64 home server
Hello! Thanx a lot all for suggestions. Especially I did not know that there is suggested set for running Fedora Server. Yes, I will be running a Fedora on it, yes, I belive I wil share the steps and thoughts, as this usually always hurt :) Most of the recomanded boards are very similar to rpi, which is just week, and usb drives have its bugs. From those the librecomp and honeycomb looks quite promissing. I need to dig deeper:) Thanx a lot for recomandation, Some of the models mentioned were never seen by me. J. On 9/14/22 11:04, Peter Robinson wrote: On Tue, Sep 13, 2022 at 7:51 PM Chris Adams wrote: I'd like to piggy-back - is there a Fedora well-supported board that can use the Pi-targeted hats? I stayed away from the Pi for a long while, because of the support problems, but it just seems like there's so much that's just made for Pis. HATs are hard, there's a lot of devices that claim to be compatible with the HAT interface but there's always caveats so it would depend very much on your usecase. P ___ 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: java-*-openjdk-portable and the FTBFS policy
hi! Yes, there is upcoming release in 17july, and in this release will be all built on f39. If there would be any intermittent release it would be already on f39 anyway. I do not have strong preference on exclude/rebuild. I was going by moreover middle path - to keep building on oldest supported os, considering jdk is built no later then every 3 months, I was not hurrying with rebuild once f38 went eol. Actually during every build I'm ensuring buildability of all jdks on all fedoras, which is ok, except jdk8 on f40+ (but that should go better soon). If you want me to rebuild on each EOL, I'm ok to do it, only do not be to angry if I forget from time to time. I will always respond to ping. Does it make sense? TY! J. On Mon, 24 Jun 2024 at 17:43, Miro Hrončok wrote: > Hello, > > I am about to send a reminder about Rawhide packages that were not > successfully > built on a supported Fedora release / fail top build for 2+ releases. > > Amongst the list of the packages, I see: > > java-1.8.0-openjdk-portable-1:1.8.0.412.b06-1.fc38.src > java-11-openjdk-portable-1:11.0.23.0.9-1.fc38.src > java-17-openjdk-portable-1:17.0.11.0.9-1.fc38.src > java-21-openjdk-portable-1:21.0.3.0.9-1.fc38.src > java-latest-openjdk-portable-1:22.0.1.0.8-1.rolling.fc38.src > > Technically, those packages do not fail to build, but they were built on > Fedora > 38 on purpose. However, Fedora 38 is now EOL so the package do violate the > "built on supported release" principle of the policy. > > Should those packages be exempted from the policy, or should we rebuild > them on > Fedora 39 now? I don't know if this poses some additional expenses wrt > certification. > > -- > Miro Hrončok > -- > Phone: +420777974800 > Fedora Matrix: mhroncok > > -- ___ 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: java-*-openjdk-portable and the FTBFS policy
Cool. TYVM! On Mon, 24 Jun 2024 at 19:27, Miro Hrončok wrote: > On 24. 06. 24 19:16, Jiri Vanek wrote: > > hi! > > > > Yes, there is upcoming release in 17july, and in this release will be > all > > built on f39. > > > > If there would be any intermittent release it would be already on f39 > anyway. > > > > I do not have strong preference on exclude/rebuild. I was going by > moreover > > middle path - to keep building on oldest supported os, considering jdk > is built > > no later then every 3 months, I was not hurrying with rebuild once f38 > went eol. > > Actually during every build I'm ensuring buildability of all jdks on all > > fedoras, which is ok, except jdk8 on f40+ (but that should go better > soon). > > > > If you want me to rebuild on each EOL, I'm ok to do it, only do not be > to angry > > if I forget from time to time. I will always respond to ping. > > > > Does it make sense? > > Absolutely. If you rebuild every 3 months anyway, I don't think an > explicit > rebuild after EOL is necessary. > > I will exclude the packages from the report to avoid noise. > > > Thanks! > -- > Miro Hrončok > -- > Phone: +420777974800 > Fedora Matrix: mhroncok > > -- ___ 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: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On 02/20/2018 01:02 PM, Zdenek Dohnal wrote: On 02/18/2018 06:09 PM, Igor Gnatenko wrote: List of packages and respective maintainers: https://ignatenkobrain.fedorapeople.org/gcc-removal-pkgs.txt Done in packages where I am admin. TY! J. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
