Bug 1190137
|
Description
Julius Schwartzenberg
2015-02-06 12:30:53 UTC
Hello. Unluckily this is intentional. In fedora 21+ is no openjdk7. So during update, your jdk7 was replaced by jdk8 There was long thread about this on devel list, with no clear result. Issue is, that java maintainers do not have enough man power to maintain more then one jdk in fedora. The 8 is main jdk now. From time to time we push also techpreview jdk ito fedora - as we did in f20 and f19 with jdk8. This is currently closed not a bug. The only solution is, that somebody will be willing to take ownership of jdk7 onto himself. Are you wiling? If so, you may start to take care for jdk7 for f21/rawhide. The only necessary thing is to be sure that it not appear in buildroot. For example by removing provides java/java-devel and similar. (In reply to jiri vanek from comment #1) > Unluckily this is intentional. In fedora 21+ is no openjdk7. So during > update, your jdk7 was replaced by jdk8 The problem is not the availability of the package. I took the source RPMs from CentOS 7 and managed to build them on Fedora 21 without any changes. It's these packages that I have in my local yum repository. The problem is that these packages are not installable through yum, because of its strict obsolete handling. It appears there is no way to avoid this now. I wouldn't mind maintaining jdk6 and jdk7 for Fedora. RedHat will provide updates for CentOS 7 for a long time and those sources compile perfectly fine on Fedora 21. I don't think that would solve this issue directly however. Another main issue with adding OpenJDK < 8 in Fedora will be that it will be incompatible with all other Java packages in the stack. All packages are presently built with OpenJDK8 and the class file format is not backwards compatible with OpenJDK7. In CentOS7 this is not an issue because OpenJDK7 is the base JDK there. (In reply to Deepak Bhole from comment #3) > Another main issue with adding OpenJDK < 8 in Fedora will be that it will be > incompatible with all other Java packages in the stack. All packages are > presently built with OpenJDK8 and the class file format is not backwards > compatible with OpenJDK7. In CentOS7 this is not an issue because OpenJDK7 > is the base JDK there. There's no reason to change the base JDK. I keep OpenJDK8 as the base JDK in Fedora 21. OpenJDK7 and OpenJDK6 are installed in addition and can be used to build applications for older application servers while all the included tools such as Maven, Eclipse, etc. run in OpenJDK8. Why not just use CentOS or RHEL? That would seem like the simpler solution, rather than maintaining your own Fedora packages for 6 & 7. (In reply to Julius Schwartzenberg from comment #4) > (In reply to Deepak Bhole from comment #3) > > Another main issue with adding OpenJDK < 8 in Fedora will be that it will be > > incompatible with all other Java packages in the stack. All packages are > > presently built with OpenJDK8 and the class file format is not backwards > > compatible with OpenJDK7. In CentOS7 this is not an issue because OpenJDK7 > > is the base JDK there. > > There's no reason to change the base JDK. I keep OpenJDK8 as the base JDK in > Fedora 21. OpenJDK7 and OpenJDK6 are installed in addition and can be used > to build applications for older application servers while all the included > tools such as Maven, Eclipse, etc. run in OpenJDK8. Is it not possible to use '-source 7 -target 7' for this? Furthermore, what would such builds be targeting? They will still not work on Fedora unless they are fully self-contained. If the target is not Fedora, then building on CentOS as Andrew mentioned in comment #5 might be easier.. (In reply to Andrew John Hughes from comment #5) > Why not just use CentOS or RHEL? That would seem like the simpler solution, > rather than maintaining your own Fedora packages for 6 & 7. The Eclipse environment which is shipped with Fedora is much more extensive than the Eclipse environment from CentOS/RHEL or its developers toolset. Running Fedora's Eclipse (on OpenJDK 1.8), it is possible to add OpenJDK 1.6 and OpenJDK 1.7 in it and run software, unit tests, etc. directly these JDKs. (It's also possible to install and add Oracle's JDKs as well for instance.) (In reply to Deepak Bhole from comment #6) > Is it not possible to use '-source 7 -target 7' for this? Furthermore, what > would such builds be targeting? They will still not work on Fedora unless > they are fully self-contained. If the target is not Fedora, then building on > CentOS as Andrew mentioned in comment #5 might be easier.. That could potentially allow things to work, but it is usual to build, run tests, the software itself against the same JDK which is used on the production system. There have been significant differences between JDKs, so it is always preferable to stay as close to the production version as possible. The final build itself is done on CentOS, but development is easier on Fedora (some even do this on MS Windows with MS Windows versions of the same JDKs). As we were used to use obsolete always, when main jdk was changed in fedora, this example is crossing the intention to orpahne 8 only. So actually fixing this bug prepare us to this way. if jdk8 would not obsolete jdk7, but jdk7 will provide java7* stuff, and jdk8 priority will be higher, then the result for basic user will be same: - he will have jdk8 as mian jdk - it will be installed and set during update - side effect is, that jdk7 will remain installed too. Obviously, removing the obsolete later in lifecycle is not an best option.... (In reply to jiri vanek from comment #8) > As we were used to use obsolete always, when main jdk was changed in fedora, > this example is crossing the intention to orpahne 8 only. So actually fixing > this bug prepare us to this way. > > if jdk8 would not obsolete jdk7, but jdk7 will provide java7* stuff, and > jdk8 priority will be higher, then the result for basic user will be same: > - he will have jdk8 as mian jdk > - it will be installed and set during update > > - side effect is, that jdk7 will remain installed too. > > Obviously, removing the obsolete later in lifecycle is not an best option.... Hi Jiri, So to clarify, you are okay with removing the Obsoletes directive if OpenJDK < 8 provides only javaX where X is the version? I have no better (aka not similar) idea how to allow legacy jdks alive in Fedora.
I'm maybe for more removal of all possible provides instated of %{name} ) rather then adding X ones. Even if it is wrong, it is more symple to add them later then remove them later.
But to clarify - Me (we) are not going to maintain those packages. Volunteers have to.
Imho this will need Fesco involvement... Hi again!
I'm trying to prepare some policy for f22 how to support legacy jdkS in fedora.
From curiosity, how evil will you consider, if you will be recommended (read "must" to rename the packages? eg to java-1.7.0-openjdk{,-devel,-javadoc,...}-legacy ?
No need for a new policy. Just drop the Obsoletes: java-1.7.0-openjdk from java-1.8.0-openjdk.spec. (In reply to Dominik 'Rathann' Mierzejewski from comment #13) > No need for a new policy. Just drop the Obsoletes: java-1.7.0-openjdk from > java-1.8.0-openjdk.spec. 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). Also please continue discussion about htose polycies rather on devel list, then here. For a sake of information - https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora - is What Dominik was mentioning as "polycies" Hello again! If you really wont to maintain legacy JDK in fedora, you can. https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora. I would strongly encourage youto go with: https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred During your work the rules will evolve. If you do not wont to maintainit, I will close this as "closed wontfix" (In reply to jiri vanek from comment #16) > I would strongly encourage youto go with: > https://fedoraproject.org/wiki/User:Jvanek/Changes/ > LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred I think I should try option 3 first and if that works out, migrate to option 1. I'll try to find time to look into this. Thanks for your help, it will be a good guide for me! Ok. Still - even in coper repo - I would encourage you to go with -legacy suffix. Because otherwise the yum will prevent you to install it, because of openjdk8 still obsolate java-1.7.0-openjdk. Created attachment 998783 [details]
patch for centos spec file
I created a patch based on the spec file I got from the CentOS 7 source RPM to implement option 1. It would seem the easiest way to maintain this, but I don't really know what is the normal policy. What do you think of this?
One question I have regarding point 3, the priority among the alternatives. What is the reason that the number of digits should be 5? Wouldn't a six-digit priority starting with 18 always win over a six-digit priority starting with 17? In the current patch I do reduce the number of digits to 5, but I think this change is not really necessary.
Hi! The rule 3 - simply lowering the priority is not enough. You need to include also this 4 lines : http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec?id=fb001ce997e7fc95c1eeca02d3ed004dc59035a1#n956 from this patch: http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=fb001ce997e7fc95c1eeca02d3ed004dc59035a1 With one necessary change - to make this to die on size of 5. The reason why I'm "forcing" you to reduce to 5 (or less) is this - By some accident, you may increase the priority to 8 or more digits. It is improbable, but may happen. And suddenly 17000000 > 180000. So thats why it is needed here. I'mnot forcing you to downgrade to less digits then 5, because I would like to keep you as much fredom as play with priority as possible. Patch itself: Except missing priority checks , I can see: - Patch106: %{name}-freetype-check-fix.patch + Patch106: java-%{javaver}-%{origin}-freetype-check-fix.patch I would recommend you to include global of origname java-%{javaver}-%{origin} and use this origname in places where name needs update. The rest of the patch are removed provides. You really have to remove *all* virtual provides, unless it will kill your usecase. If it will kill your usecase, then there are two options: If you will be runing copr repo - then you actually can keep them all in, as no uninterested user will be affected by acidence, nor build root and so on.. If you are going to include them in regular fedora, I'm afraid all of them really have to be removed - or theirs existence must be heavily discussed. Next - if you are doing copr repo, then there are no official rules I'm aware about. If you wont to include this java-1.7.0-openjdk-legacy in fedora then you need to pass regular review process - https://fedoraproject.org/wiki/Join_the_package_collection_maintainers - Here I will be your's reviewer probably and we may try to push it in. Thanks for your quick response. I'll create a new version of the patch with your feedback.
About the provides however. I think that all provides which include %{javaver} in the package name part can stay. They should never overlap in any way with anything from a newer version, but they would enable packages which would depend on a specific JDK version to continue to work. All provides which do not include %{javaver} should be removed by the patch.
Created attachment 998940 [details]
patch for centos spec file v2
Here's the revised version of the patch.
Created attachment 1001431 [details]
patch for centos spec file v3
Here's another version. I've added a provide to provide the original java-1.7.0-openjdk-devel package. This seems the most appropriate way to solve the build dependency and allow packages still depending on specifically this JDK version to build.
I've tried to set up a copr repository, but my build fails in a way I do not understand. Here are the logs: https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-21-x86_64/java-1.7.0-openjdk-legacy-1.7.0.75-2.5.4.2.fc21/ Locally I do not have any problems with building. I've published these builds in a yum repo here (also to bootstrap the copr build): http://schwart6.home.xs4all.nl/fedora21/binaries/ Janek, you think I should look into fixing the issue with copr first or try the Fedora review process already? What do you think of my current patch? When I've got OpenJDK 1.7 up properly, I can arrange the same for OpenJDK 1.6. I expect it will be almost the same patch. (In reply to Julius Schwartzenberg from comment #24) > I've tried to set up a copr repository, but my build fails in a way I do not > understand. It's bug 1194817. (In reply to Julius Schwartzenberg from comment #24) > I've tried to set up a copr repository, but my build fails in a way I do not > understand. Here are the logs: > https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-21- > x86_64/java-1.7.0-openjdk-legacy-1.7.0.75-2.5.4.2.fc21/ > > Locally I do not have any problems with building. I've published these > builds in a yum repo here (also to bootstrap the copr build): > > http://schwart6.home.xs4all.nl/fedora21/binaries/ > Awesome! > Janek, you think I should look into fixing the issue with copr first or try According to bugid Omair posted, the issue in coper have been already resolved. > the Fedora review process already? What do you think of my current patch? Looks good, except the provides:) Why you are keeping few of them inside? If you wont to go with fedora review process, I would really like you to remove *all* virtual provides, *unless* it kills yours usecase. So why you are keeping them in? Have it already caused any troubles? Don't forget, that package always provides NAME = VR. In your case individual rpms provides: java-1.7.0-openjdk-legacy = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-accessibility = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-debuginfo = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-demo = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-devel = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-headless = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-javadoc = 1.7.0.75-2.5.4.2.fc21 java-1.7.0-openjdk-legacy-src = 1.7.0.75-2.5.4.2.fc21 So basically you do not need any virtual provides. If you need any (build)requirement, you would use for java Reuires: java-1.7.0-openjdk-legacy or for javac eg: BuildReuires: java-1.7.0-openjdk-legacy-devel Isn't it enough? I have tested your packages a bit, and they are working great! > > When I've got OpenJDK 1.7 up properly, I can arrange the same for OpenJDK > 1.6. I expect it will be almost the same patch. Its completely up to you:). But I agree that waiting until jdk7 is in or "in coper" is definitely good idea. Also I'm impressed by small necessary patch. Thats making me believe that https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred is really best way to go. Thank you your efforts. I'm hoping to see those in fedora soon! (In reply to jiri vanek from comment #26) > (In reply to Julius Schwartzenberg from comment #24) > > Janek, you think I should look into fixing the issue with copr first or try > > According to bugid Omair posted, the issue in coper have been already > resolved. I just restarted the build there, let's see whether it'll finish now. > > the Fedora review process already? What do you think of my current patch? > > Looks good, except the provides:) Why you are keeping few of them inside? > If you wont to go with fedora review process, I would really like you to > remove *all* virtual provides, *unless* it kills yours usecase. > > So why you are keeping them in? Have it already caused any troubles? I would say that the provides which include a version number would never cause problems. At the same time keeping them increases compatibility with existing packages and compatibility with the RHEL/CentOS packages. Are there any disadvantages in keeping them? > Don't forget, that package always provides NAME = VR. > In your case individual rpms provides: > java-1.7.0-openjdk-legacy = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-accessibility = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-debuginfo = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-demo = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-devel = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-headless = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-javadoc = 1.7.0.75-2.5.4.2.fc21 > java-1.7.0-openjdk-legacy-src = 1.7.0.75-2.5.4.2.fc21 > > So basically you do not need any virtual provides. If you need any > (build)requirement, you would use for java > Reuires: java-1.7.0-openjdk-legacy > or for javac eg: > BuildReuires: java-1.7.0-openjdk-legacy-devel > > Isn't it enough? Yes, for my usecase this would be enough. > Also I'm impressed by small necessary patch. Thats making me believe that > https://fedoraproject.org/wiki/User:Jvanek/Changes/ > LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred is > really best way to go. I think it shows how great the (source) compatibility is between RHEL/CentOS & Fedora. > Thank you your efforts. I'm hoping to see those in fedora soon! Thank you for all the support with this. I'll do my best to get this in! > > So why you are keeping them in? Have it already caused any troubles? > > I would say that the provides which include a version number would never > cause problems. Hmhmhmh, maybe you are right and I'm just to much paranoid > At the same time keeping them increases compatibility with > existing packages and compatibility with the RHEL/CentOS packages. I would like to avoid *legacy packages being used as dependency in any regular fedora package. This is a bit prevention. > Are there any disadvantages in keeping them? Yes. I would like to avoid any possible by-accident usage. Consider this scenario: I have package, and I had brroken rules, and I'm requiring java-1.8.0-openjdk-headless instead of java JDK8 will eoled, I do not notice. Somebody pickup jdk8 and will create java-1.8.0-openjdk-legacy But because of it still provides java-1.8.0-openjdk then my pacage will suddenly being dependent on obsoilated jdk, instead on main fedora jdk. Then it may be also pulled to unaware user's system, > > > > Don't forget, that package always provides NAME = VR. > > In your case individual rpms provides: > > java-1.7.0-openjdk-legacy = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-accessibility = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-debuginfo = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-demo = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-devel = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-headless = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-javadoc = 1.7.0.75-2.5.4.2.fc21 > > java-1.7.0-openjdk-legacy-src = 1.7.0.75-2.5.4.2.fc21 > > > > So basically you do not need any virtual provides. If you need any > > (build)requirement, you would use for java > > Reuires: java-1.7.0-openjdk-legacy > > or for javac eg: > > BuildReuires: java-1.7.0-openjdk-legacy-devel > > > > Isn't it enough? > > Yes, for my usecase this would be enough. > > Then I'm +1 to remove all virtual provides. Maybe add them back in live time. Created attachment 1002881 [details] patch for centos spec file v4 (In reply to jiri vanek from comment #28) > Then I'm +1 to remove all virtual provides. Maybe add them back in live > time. Here's a new patch that does this. I indeed suppose we can always add back these provides when it turns out that we need compatibility with existing packages which depend on specific JDK versions. The build with this is also available here: https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/ Let me know when/what should be the next step to get this further! I'm ok with this approach. Now depends on you if you wants to keep them in kopr or do an reiw request. If the first, you are done. If the second then do an review request. I will be happy to be an reviwer for this (please let me know once it is posted on review - via this bug or by email - and I will take it) Also note - during the formal review, this effort may be suspended form fedora-devel. We did not completely agreed on some rules, and actually it was 50/50 nearly on each. So you will need to be patient with us. https://fedoraproject.org/wiki/Join_the_package_collection_maintainers http://fedoraproject.org/wiki/Package_Review_Process As resutl of the https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora and of this official review some modifications to current pacakging guidelines or to your current patch may evolve Ah yes, I had missed this discussion. For now I will put both OpenJDK 1.6 and 1.7 with your guidelines in COPR then, which will enable installation without any obsolete-issues. My intention for this bug report originally wasn't to get the old JDKs in Fedora itself, just a way to get around yum's obsolete checking. It was easy to build Fedora packages from the CentOS sources. I just needed a way around yum removing them for supposedly being obsolete. (In reply to Julius Schwartzenberg from comment #31) > Ah yes, I had missed this discussion. For now I will put both OpenJDK 1.6 You did not miss to much, there was a lot of loud, but not much results > and 1.7 with your guidelines in COPR then, which will enable installation > without any obsolete-issues. oook:( As you feel right!-) If you ever wont those in main repo, feel free to let me know. > > My intention for this bug report originally wasn't to get the old JDKs in > Fedora itself, just a way to get around yum's obsolete checking. It was easy > to build Fedora packages from the CentOS sources. I just needed a way around > yum removing them for supposedly being obsolete. Then I will close this bug. Created attachment 1008578 [details]
patch for centos spec file v5
Bugfix for OpenJDK 1.7 patch.
Created attachment 1008580 [details]
OpenJDK 1.6 patch for centos spec file
I've packaged both OpenJDK 1.6 and OpenJDK 1.7 for Fedora 21 now. The patches are attached here. The Copr repositories are here: https://copr.fedoraproject.org/coprs/jschwart/openjdk-6/ https://copr.fedoraproject.org/coprs/jschwart/openjdk-7/ I guess this would help most developers that need the older OpenJDKs in Fedora. If anyone would like this to be pushed into Fedora officially, I'm open to cooperate more on this. If anyone finds problems with these builds, please let me know! So it happened in time, that I become yours regural user. Ty for maintain those! J. Glad to hear this! I just noticed my OpenJDKs on CentOS got upgraded and pushed the same updates to the respective COPRs. I didn't do much more than applying the patches from here and pushing it to COPR, so please let me know if there are any issues! Any chance we can get a fedora22 builds up as well? I haven't got a Fedora 22 system yet, but should have one soon to see what needs to be done for the build. I tried it now without any changes, but for some reason the build failed: https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-22-x86_64/java-1.7.0-openjdk-legacy-1.7.0.79-2.5.5.1.fc21/ Maybe the Fedora 21 builds will install/work on Fedora 22 for now? They seems to be working. The build issue should be fixable by: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-June/032239.html (In reply to Julius Schwartzenberg from comment #39) > I haven't got a Fedora 22 system yet, but should have one soon to see what > needs to be done for the build. I tried it now without any changes, but for > some reason the build failed: > https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-22- > x86_64/java-1.7.0-openjdk-legacy-1.7.0.79-2.5.5.1.fc21/ On Fedora 22, you may also need the following patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/629f25b8fc9d I'm looking at deploying the new versions on Fedora 21 but it seems updates to Fedora 21 introduced a problem with systemtap. When I compile a build of OpenJDK 1.6 which worked before (locally), I now get this error: checking working sys/sdt.h and g++ support... configure: error: systemtap sdt.h or g++ too old I tried downgrading systemtap (from 2.9 to 2.6) but that does not solve the problem. Does anyone happen to know what's going on here? I hope the Fedora 21 binaries run on 22 and 23, I still haven't found time to get these installations up and running to provide specific packages for them. (In reply to Omair Majid from comment #41) > (In reply to Julius Schwartzenberg from comment #39) > > I haven't got a Fedora 22 system yet, but should have one soon to see what > > needs to be done for the build. I tried it now without any changes, but for > > some reason the build failed: > > https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-22- > > x86_64/java-1.7.0-openjdk-legacy-1.7.0.79-2.5.5.1.fc21/ > > On Fedora 22, you may also need the following patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/629f25b8fc9d That's part of 2.5.6 and 2.6.0. See PR2326 in IcedTea Bugzilla. Created attachment 1118125 [details]
patch for OpenJDK 1.7.0 u95 spec file
I just uploaded the latest versions for Fedora 22. It appears all the required patches are included in the CentOS/RHEL packages now. I hope to move to Fedora 23 as well, but it appears that builds for previous versions should run on newer versions in general.
If anybody needs any extra architectures checked, let me know and I'll run builds for them as well.
Testing building on Fedora 23 reveals that at-spi-devel is removed which contained a libspi-1.0 package config needed to do a plain build. I do not immediately know what would be the best solution for this. The last OpenJDK 1.7 in Fedora (20) also still had this dependency. Are there any known tweaks already to let it work with the newer version 2 of the library which is included? A possible solution could be to provide the old at-spi packages through COPR as well. (In reply to Julius Schwartzenberg from comment #45) > Testing building on Fedora 23 reveals that at-spi-devel is removed which > contained a libspi-1.0 package config needed to do a plain build. > > I do not immediately know what would be the best solution for this. The last > OpenJDK 1.7 in Fedora (20) also still had this dependency. Are there any > known tweaks already to let it work with the newer version 2 of the library > which is included? If you could somehow get at-spi-devel to work, it's not really supported anymore by desktop environments, so it's not going to be very useful. OpenJDK 1.7 should Just Work with java-atk-wrapper (just like java-1.8.0-openjdk does). I think all you need to do is symlink the java-atk-wrapper jar, put the right bits in the accessibility properties and security properties file and you should be good to go. For testing that it works for Swing applications, https://wiki.gnome.org/Accessibility/SmokeTesting has some ideas. I think this is a legacy requirement that could be removed. On RHEL 6, which has GNOME 2: # Java Access Bridge for GNOME build requirements. BuildRequires: at-spi-devel BuildRequires: gawk BuildRequires: libbonobo-devel These aren't there for OpenJDK but for the GNOME Access Bridge. As that was for GNOME 2, and Fedora is now on GNOME 3, I think you could just remove this. On RHEL 7, it seems the access bridge and Bonobo dependency have gone but not at-spi-devel. This seems like a mistake but I'll double-check. The access bridge is java-access-bridge-1.23.0.tar.bz2 in sources, and you can remove this and the rules pertaining to it, if it's still there. at-spi has dependencies on the GNOME 2 libraries: Requires: gtk2 >= %{gtk2_version} Requires: libbonobo >= %{libbonobo_version} Requires: ORBit2 >= %{orbit2_version} Requires: gail >= %{gail_version} Requires: atk >= %{atk_version} some of which have probably gone as well, so I wouldn't try packaging it in COPR. The replacement is the java-1.7.0-openjdk-accessibility package, which depends on java-atk-wrapper. That, in turn, depends on the replacement for at-spi for GNOME 3: BuildRequires: at-spi2-atk-devel BuildRequires: at-spi2-core-devel OpenJDK 1.6 still has the libbonobo-devel BuildRequires on RHEL 7. For 1.7 it is removed. Removing the whole access bridge block indeed gives me a working (1.6) build! I'll try to get the packages in copr soon. Created attachment 1121420 [details]
patch for OpenJDK 1.6.0 u38
Packages for Fedora 23 are in copr now.
I had to add multiple BuildRequires to the spec file to get the build to work. I'm surprised the RHEL builds can work without them.
Created attachment 1121421 [details]
patch for OpenJDK 1.7.0 u95 spec file for Fedora 23
Which RHEL are you syncing against? RHEL 7 is going to be closer to Fedora than RHEL 6, but both will be different as these are stable platforms while Fedora constantly changes. The execstack dependency is a swap for prelink, but neither is required; you'll see there is no execstack call in the spec file any more. The XRender and freetype ones were probably being pulled in by the bridge dependencies that were removed. I see freetype-devel on the OpenJDK 8 RHEL 7 builds, but not XRender. I think that backend is optional so that may be a regression which I'll look into. The RHEL builds only get updated at the quarterly security updates and these changes tend to be limited to what's needed so as not to break anything when we're under strict time restrictions. Hence, stuff like this doesn't get cleaned up. Thanks for this feedback and I'll try and remove some of these dead dependencies. I'm basing everything on the RHEL (CentOS) 7 source RPMs. It seemed the most appropriate source. Without adding a BuildDepends for execstack, the build fails (on copr) for Fedora 23 with a "command not found" for execstack. (With it, it fails for Fedora 22 because it doesn't have the execstack package.) In the attached patches I really add the minimum amount of dependencies to get the builds to finish for Fedora 23 on copr. Without them either it fails during a configure script or it breaks during the build with a missing header file (or command). You're welcome! Having the necessary spec diff for Fedora become smaller is also nice for me of course. Yeah, it should be possible to also remove the execstack calls if they're still present. The files are now marked appropriately upstream.
For java-1.6.0-openjdk, I was able to do the following:
@@ -224,17 +226,15 @@ BuildRequires: libXt-devel
BuildRequires: libXtst-devel
BuildRequires: libjpeg-devel
BuildRequires: libpng-devel
-BuildRequires: wget
-BuildRequires: xalan-j2
-BuildRequires: xerces-j2
BuildRequires: xorg-x11-proto-devel
-BuildRequires: mercurial
BuildRequires: ant
BuildRequires: libXinerama-devel
BuildRequires: rhino
-BuildRequires: redhat-lsb
+# Provides lsb_release for generating identification
+BuildRequires: redhat-lsb-core
%if %{gcjbootstrap}
BuildRequires: java-1.5.0-gcj-devel
+BuildRequires: libxslt
%else
BuildRequires: java6-1.6.0-devel
%endif
The wget removal requires a backport of http://icedtea.classpath.org//hg/icedtea6?cmd=changeset;node=e9935e163815 and the addition of --disable-downloading to the configure line:
@@ -385,7 +386,7 @@ export CFLAGS="$CFLAGS -mieee"
./autogen.sh
./configure %{icedteaopt} --with-openjdk-src-zip=%{SOURCE1} \
--with-pkgversion=rhel-%{release}-%{_arch} --enable-pulse-java \
- --with-abs-install-dir=%{_jvmdir}/%{sdkdir} \
+ --with-abs-install-dir=%{_jvmdir}/%{sdkdir} --disable-downloading \
--with-rhino --with-parallel-jobs=$NUM_PROC --disable-lcms2
This is a good idea anyway as it ensures the build won't download its own OpenJDK tarball and is forced to use the one in the RPM sources or fail.
jfyi, if we want fedora to target developers, android is perpetually on an ancient java version (marshmallow is on openjdk-1.7). And it would be nice not to force users to ubuntu in order to build android. (not really adding anything constructive to this bug, other than to say +10000 for being able to easily parallel install older jdk versions in fedora) (In reply to Rob Clark from comment #54) > jfyi, if we want fedora to target developers, android is perpetually on an > ancient java version (marshmallow is on openjdk-1.7). And it would be nice > not to force users to ubuntu in order to build android. > > (not really adding anything constructive to this bug, other than to say > +10000 for being able to easily parallel install older jdk versions in > fedora) They already are possible to install together. Julius - huge thanx to him for doing it - is keeping copr repo with them . https://bugzilla.redhat.com/show_bug.cgi?id=1190137#c35 cat /etc/yum.repos.d/alternativeJvms.repo [jschwart-openjdk-7] name=Copr repo for openjdk-6 owned by jschwart baseurl=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-$releasever-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/pubkey.gpg enabled=1 [jschwart-openjdk-6] name=Copr repo for openjdk-6 owned by jschwart baseurl=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/fedora-$releasever-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/pubkey.gpg enabled=1 [omajid-openjdk9] name=Copr repo for openjdk9 owned by omajid baseurl=https://copr-be.cloud.fedoraproject.org/results/omajid/openjdk9/fedora-$releasever-$basearch/ skip_if_unavailable=True gpgcheck=1 gpgkey=https://copr-be.cloud.fedoraproject.org/results/omajid/openjdk9/pubkey.gpg enabled=1 You can install them all together, and switch by alternatives. They are just not available in main repos. I fyou wont to keep them in main repos, brace yourself and take the wand :) (In reply to jiri vanek from comment #55) > (In reply to Rob Clark from comment #54) > > jfyi, if we want fedora to target developers, android is perpetually on an > > ancient java version (marshmallow is on openjdk-1.7). And it would be nice > > not to force users to ubuntu in order to build android. > > > > (not really adding anything constructive to this bug, other than to say > > +10000 for being able to easily parallel install older jdk versions in > > fedora) > > They already are possible to install together. Julius - huge thanx to him > for doing it - is keeping copr repo with them . > > https://bugzilla.redhat.com/show_bug.cgi?id=1190137#c35 > oh, awesome.. I suppose this should be better publicised so it actually shows up when someone searches for 'openjdk 1.7 fedora' > > You can install them all together, and switch by alternatives. They are just > not available in main repos. I fyou wont to keep them in main repos, brace > yourself and take the wand :) heh, fair enough.. but there are a limited number of wands I can hold at one time ;-) > > (In reply to Rob Clark from comment #54)
> > > jfyi, if we want fedora to target developers, android is perpetually on an
> > > ancient java version (marshmallow is on openjdk-1.7). And it would be nice
> > > not to force users to ubuntu in order to build android.
> > >
This slipped a bit form previous reading. There is no need to do so. You can create for any ancient android on openjdk8 - as it is ready on Fedora.
I *do* develop for android pretty much. You set the version of lowest supported in Android Studio, and JDK (which is ready for this) do the rest.
(In reply to jiri vanek from comment #57) > > > (In reply to Rob Clark from comment #54) > > > > jfyi, if we want fedora to target developers, android is perpetually on an > > > > ancient java version (marshmallow is on openjdk-1.7). And it would be nice > > > > not to force users to ubuntu in order to build android. > > > > > > This slipped a bit form previous reading. There is no need to do so. You can > create for any ancient android on openjdk8 - as it is ready on Fedora. > > I *do* develop for android pretty much. You set the version of lowest > supported in Android Studio, and JDK (which is ready for this) do the rest. hmm, I wonder what is different for apps? I was just building latest AOSP, and it specifically checks for 1.7 (and build seems to explode with a lot of java issues if I try to bypass that..). I guess it's at least nice if this issue only effects people trying to build android, vs trying to build android apps. Created attachment 1155768 [details]
patch for OpenJDK 1.6.0 u39 (Fedora 23)
I had to add another BuildRequires this time to get the OpenJDK 1.6 u39 build going on Fedora 23, this time it was libXcomposite-devel.
I've attached a new patch for this.
Created attachment 1155788 [details]
patch for OpenJDK 1.7.0 u101 (Fedora 23)
OpenJDK 1.7 also required the extra libXcomposite-devel BuildRequires and a change to cope with the number of update digits going from 2 to 3.
I made only Fedora 23 AMD64 builds. If anybody needs any other builds, let me know and I'll try to let COPR build them as well.
There are build issues with the 1.6 source on Fedora 24: https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/fedora-24-x86_64/00360625-java-1.6.0-openjdk-legacy/build.log.gz It appears to be this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1306558 As this is not fixed yet, I'm not sure what kind of 1.8 build is included with Fedora 24 now, but I guess I can try a build with that spec file patch applied. (In reply to Julius Schwartzenberg from comment #61) > There are build issues with the 1.6 source on Fedora 24: > > https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/fedora-24- > x86_64/00360625-java-1.6.0-openjdk-legacy/build.log.gz > > It appears to be this issue: > https://bugzilla.redhat.com/show_bug.cgi?id=1306558 > > As this is not fixed yet, I'm not sure what kind of 1.8 build is included > with Fedora 24 now, but I guess I can try a build with that spec file patch > applied. The issue in bug 1306558 has been worked-around. However, the underlying issue is that hotspot uses UB which is harder to get fixed (hence, still in assigned). Especially in a stable release. The work-around is to add -fno-lifetime-dse and -fno-delete-null-pointer-check. Upstream bug for JDK 9 is: https://bugs.openjdk.java.net/browse/JDK-8151841 I managed to create a 1.6 build on Fedora 24. In addition to the spec file changes, I had to backport pr2462.patch from 1.8 to 1.6 to let it build with the new GCC 6. A similar patch set seems to be here http://mail.openjdk.java.net/pipermail/build-dev/2016-May/017168.html The changes go beyond just the spec file now. Is it possible that such changes will appear upstream at some point? In theory I could still put everything in a single patch file against the RHEL source rpm tree, but in a way it's becoming less practical. As I'd like to continue basing everything off the RHEL sources, I'm wondering in general what's the recommended practice to deal with such a situation. The GCC 6 changes are something that should happen upstream in IcedTea 2.x/OpenJDK 7 and IcedTea 1.x/OpenJDK 6. Once I have time to look at builds with GCC 6, I intend to get that fixed across all three current JDKs. The build for OpenJDK 7 seems to have gone without issues. I think it already includes the patch. That means both OpenJDK 6 and 7 are available in copr for Fedora 24 now. If there's anything I could do to help with getting certain fixes in the right place, please let me know! Of course it would also be nice if some of my spec file changes could go upstream (to RHEL) as well, but I can imagine you're reluctant with that. If you have a patch for the spec file, I can review it. It's not trivial to get changes into the RHEL RPMs, because they have to be approved. I got some fixes into the upcoming java-1.6.0-openjdk RPM for RHEL 7.3. Now would be a good time to look over a patch as changes could be included with the security update in July if they're not too dangerous. I keep the changes between the RHEL and Fedora spec already as patch files in this bug in general. They also contain the -legacy suffix and other Fedora specific things though. Should I mail you variants without those things? In general I also tend to not add any changelog entries at the bottom to keep this diff smaller and thus more likely to just apply against a newer RHEL spec. Is this important? Another possibility would be that I would split the individual changes over multiple diffs. Please let me know what's the best approach! Yes please. I'd like a patch of whatever you would like applied to the RHEL spec files basically. You don't need to worry about a Changelog; I'll write one and credit you. Created attachment 1171950 [details]
patch for OpenJDK 1.6.0 u39 (Fedora 24)
I mailed you the changes that would be nice to have upstream. I'm attaching the current spec file patches for Fedora 24 here now
Created attachment 1171951 [details]
patch backported from 1.8 to solve GCC 6 compile issues
Created attachment 1171952 [details]
patch for OpenJDK 1.7.0 u101 (Fedora 24)
I just pushed 1.7.0.111 for Fedora 24 AMD64. I could use my patch for 101 without any changes. I didn't see any response to my mail anymore btw. if you're still interested, let me know if there's anything I could still do. I expect it'll make supporting OpenJDK 1.7 (and 1.6) on RHEL 8 easier as well when the Fedora and RHEL spec files are more in sync. I've been very busy making those updates you just picked up... :P I'll take a look again when 6 is done. FWIW, the new 6 & 7 releases will work out of the box with GCC 6. You shouldn't need any additional patches. Created attachment 1199522 [details]
patch for OpenJDK 1.6.0 u40 (Fedora 24)
Alright :)
Here the patch for the new OpenJDK 1.6 as well. It indeed compiled without the extra patch! Thanks!!
This version is also available from the copr repo now.
Created attachment 1218963 [details]
patch for OpenJDK 1.6.0 u40 1.13.12.9 (Fedora 24)
The OpenJDK 6 & 7 versions released with the new RHEL 7.3 are also available for Fedora 24 now.
Created attachment 1218964 [details]
patch for OpenJDK 1.7.0 u121 (Fedora 24)
The GCC 6 CFLAGS (final hunk) shouldn't be necessary. The latest IcedTea 2.6.8 / OpenJDK 7 u121, and indeed the prior release, build fine on GCC 6, as I test with that locally. Created attachment 1250289 [details]
patch for OpenJDK 1.6.0 u41 (Fedora 25)
I can confirm it works. Here is the new 1.6 patch with the last hunk removed. Both the latest 1.6 and 1.7 are in copr now. (1.7 didn't need a new patch.)
There's a problem with the recent 1.7.0 (Fedora 25) builds though, the file /usr/lib/jvm/java-1.7.0-openjdk-legacy-1.7.0.131-2.6.9.0.fc25.x86_64/jre/lib/resources.jar is only readable for root, not for any other users. I do not see this problem on RHEL 7. Did anything change regarding file permissions and packaged files on Fedora 25? Other files in the same directory do seem to have the correct permissions.
The above problem was probably caused by me building the source rpms as root instead of a regular user. I was using a Docker container and was too lazy to create a builder user the previous time. The current release and the previous release shouldn't have had this problem anymore. For Fedora 25, the 151 version of 1.7 is available now. In Fedora 26 there's a new version of Ant which requires running in 1.8 and breaks the build of 1.6 and 1.7. Installing the previous version allows the builds to work again. I'll look into getting this building on COPR. I've put some initial packages for 1.6 here: https://schwart6.home.xs4all.nl/fedora26/binaries/ The packages for Fedora 25 should also work on 26. It seems more packages in Fedora are being built to run against 1.8 now. If there really are people who depend on JARs in /usr/share/java to be compatible with 1.6 or 1.7 it would probably make sense to switch to the software collections (SCL) infrastructure instead of relying on alternatives. I do not have any experience with this however (only used SCLs, never created packages for them) and it's not really needed for my use case. |