IBM is requesting Red Hat to look at their process on if it is really necessary to repackage what IBM gives them for IBM Java before putting it on the Supplemental CDs and RHN. This is causing us to have to recertify all the java's on each point release. By changing the package, this causes java compliance not to immediately flow and this is causing us a great deal of heartache. If you have any questions please let us know.
------- Comment From markwiz.com 2009-09-02 11:10 EDT------- Here is where we are: 1) IBM has verified the files given to Red Hat are correct. 2) The problem seems to begin when Red Hat does the packaging which seems to consist of un-ziping the files given by IBM and then repackaged into an RPM. This repackaging seems to remove some files, moves others, and changes the sizes of many of the files. We are not sure which step is doing this. 3) Size problem - I have asked Lillian Angel at Red Hat to look at a file after it is extracted from the un-zip process and compare it to the file extracted from the final RPM. If they are the same, then the problem is probably caused by the unzip problem. If they are different, the problem should be in the rpm build process. 4) Missing files- We have found many of the in other places than we expect. We are still trying to figure out what has happened to several .so files. Hopefully, once we understand the Red Hat RPM build process, we will figure out what happened to the other .so files. 5) We have also verified, if we install Java with the RPMs on DeveloperWorks we don't have any issues. Why does Red Hat need to repackage the Java RPMs and not just take them as-is?
(In reply to comment #1) > ------- Comment From markwiz.com 2009-09-02 11:10 EDT------- > 3) Size problem - I have asked Lillian Angel at Red Hat to look at a file after > it is extracted from the un-zip process and compare it to the file extracted > from the final RPM. If they are the same, then the problem is probably caused > by the unzip problem. For instance, I checked the COPYRIGHT file from the unzipped tarball and the COPYRIGHT file from the installed rpm. They are identical. > If they are different, the problem should be in the rpm > build process. This would not be possible. The process merely unzips the tarballs and installs the files.
------- Comment From markwiz.com 2009-09-02 13:40 EDT------- File size issue - The current theory is that the files are being pre-linked after install and thus the size differences. We are currently investigating this. We feel all the missing files are accounted for, at this time. Red Hat moves the files to be consistent with Linux and the make sure multiple versions of Java do not cause issues.
(In reply to comment #3) > ------- Comment From markwiz.com 2009-09-02 13:40 EDT------- > File size issue - The current theory is that the files are being pre-linked > after install and thus the size differences. We are currently investigating > this. This is possible, but I am not completely sure. Can someone with more knowledge of what happens when the RPMs are installed comment? Radek? > > We feel all the missing files are accounted for, at this time. Red Hat moves > the files to be consistent with Linux and the make sure multiple versions of > Java do not cause issues.
Yeah, prelink modifies IBM java binaries, too. When I unpack the IBM tarball (i386 in my quick test) and examine md5sum and size of `java', I get: # md5sum /opt/ibm-java2-i386-50/jre/bin/java 24734bd329d68b1ff4239e3c2a49278f /opt/ibm-java2-i386-50/jre/bin/java # ll /opt/ibm-java2-i386-50/jre/bin/java -rwxr-xr-x 1 root root 72405 Jul 7 00:08 /opt/ibm-java2-i386-50/jre/bin/java These values match md5sum and size of /usr/lib/jvm/jre-1.5.0-ibm/bin/java when you have a fresh installation of the Red Hat packaged java-1.5.0-ibm. However, after prelink, these values change: # ll /usr/lib/jvm/jre-1.5.0-ibm/bin/java -rwxr-xr-x 1 root root 77957 Jul 7 00:08 /usr/lib/jvm/jre-1.5.0-ibm/bin/java # md5sum /usr/lib/jvm/jre-1.5.0-ibm/bin/java 34a91f15645219089c22fee3dfab5350 /usr/lib/jvm/jre-1.5.0-ibm/bin/java Prelink is able to undo its changes and either save the file as-is or somewhere else. See: # prelink -u /usr/lib/jvm/jre-1.5.0-ibm/bin/java -o /tmp/java # ll /tmp/java -rwxr-xr-x 1 root root 72405 Jul 7 00:08 /tmp/java # md5sum /tmp/java 24734bd329d68b1ff4239e3c2a49278f /tmp/java which is the md5sum and size I mentioned above. If this is undesirable, I believe prelink can be reconfigured to ignore the IBM java files. Oh, and to answer the question why we repackage the IBM Java: yeah, we need to place all files into dedicated locations, so that 1] one can have multiple JREs/JDKs installed and easily switch among them 2] the binaries wouldn't work with SELinux otherwise - by putting them into a *standard* location, SELinux can be set to ignore the main problem of the binaries IBM has in their tarballs, which appears when you run `java' from a custom location: Error loading: /opt/ibm-java2-i386-50/jre/bin/classic/libjvm.so: cannot restore segment prot after reloc: Permission denied I hope I explained the reason why certain files from our RPM don't match corresponding files in the IBM tarball. Please let us know if prelink isn't the only 'culprit'. IOW, please examine our packages immediately after their installation, before prelink touches them. If 'fresh' packages are okay, we don't really have a problem with certification of the RPMs in RHN and on the Supplementary CD, do we? As for "4) Missing files- We have found many of the in other places than we expect...". It would really help if you guys could tell exactly which files are missing - where did you expect to find the given file (and where it actually is, if you think it's incorrectly placed), for every affected file.
------- Comment From tpnoonan.com 2009-09-04 10:23 EDT------- 9/3: -it appears that ibm will internally certify that ibm java as previously posted on rhn complies and then ask red hat to repost ibm java on rhn -note that copyright/license files were simply moved during red hat's required repackaging without violating compliance -ibm will prevent reoccurance on future rhel by doing testing at beta start 9/4: ibm will re-certify ibm java as previously posted on rhn with target of 9/11, once re-certified ibm will request that red hat repost on rhn (note: if ibm java misses any rhel5.4 cd respin it would be okay as new ibm java versions will come out in October and then be requested to be placed on rhn)
------- Comment From markwiz.com 2009-09-09 08:11 EDT------- I sent the following to Lillian Angel at Red Hat: We fully understand what is happening with Java. 1.4.2 looks OK. For Java5 and Java6, can you have the JRE install process include the Copyright and Notices files? Currently you have the Copyright and Notices in the devel package. You can keep them there also. Can you please respin Java5 and Java6 with the changes and put them somewhere we can get to them so we can test and re-certify? Hopefully you can do this in a short amount of time. When you are done, send me a note with the location of the packages. Java5 and Java6 size issue is due to prelink. If we turn it off the size issue goes away so it is not an issue.
Yes, I will work on them today. I will post them internally and let you know the link
------- Comment From markwiz.com 2009-09-09 11:13 EDT------- Lillian, Please stop the re-spin. I have received a note from the JTC stating there are more missing files that need to be resolved. I am waiting for a complete list.
------- Comment From markwiz.com 2009-09-10 07:33 EDT------- Java 1.4.2 is OK. Java5 . license & notices files are missing in JRE rpm Java6 - Copyright, license & notices files are missing in JRE rpm - Following files are missing in javacomm rpm /jar/comm.jar /jar/commtest.jar /jar/tools/BlackBox.jar /jar/tools/ParallelBlackBox.jar /lib/javax.comm.properties /lib/libLinuxSerialParallel.so We need the JRE re-spun for Java5 and have it include the missing files. We need both the JRE and Javacom rpm re-spun for Java6 and have it include the missing files This is needed for all platforms.
I see the issue, I will send you a link to the packages when they are built.
------- Comment From markwiz.com 2009-09-11 16:49 EDT------- We are seeing the following dependancy errors on all platforms with Java6 only. Red Hat has also been able to recreate it. error: Failed dependencies: libc.so.1 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libc.so.1(SUNWprivate_1.1) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libc.so.1(SYSVABI_1.3) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libpthread.so.1 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libpthread.so.1(SUNW_1.2) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 librt.so.1(SUNW_0.7) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libX11.so.1 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libX11.so.4 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libX11.so.4(SUNW_1.1) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXaw.so.1 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXaw.so.5 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXaw.so.5(SUNW_1.1) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXext.so.0 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXmu.so.4 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXt.so.1 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXt.so.4 is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXt.so.4(SUNW_1.1) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 libXt.so.4(SUNWprivate) is needed by java-1.6.0-ibm-1.6.0.5-1jpp.3.el5.i386 unixODBC is needed by java-1.6.0-ibm-jdbc-1.6.0.5-1jpp.3.el5.i386
Looking into it.
------- Comment From markwiz.com 2009-09-14 07:41 EDT------- Lillian, In SystemZ we noticed appletViewer in the Devel package is the same size as appletViewer.bin. Is appletViewer just a wrapper?
yeah it is just a wrapper. These should both be in the tarball, as far as i know.
------- Comment From sglass.com 2009-10-06 14:06 EDT------- Repackaging is required. Closing bug
The java-1.5.0-ibm package has been respun for bug 520149. *** This bug has been marked as a duplicate of bug 520149 ***