Spec URL: http://langel.fedorapeople.org/java-1.6.0-icedtea/java-1.6.0-icedtea.spec SRPM URL: http://langel.fedorapeople.org/java-1.6.0-icedtea/java-1.6.0-icedtea-1.6.0.0-0.1.b05.fc9.src.rpm Description: The IcedTea 1.6.0 runtime environment.
Is there a reason we're going to be shipping two versions?
(In reply to comment #1) > Is there a reason we're going to be shipping two versions? From the java-1.7.0-icedtea README: Java compatibility ------------------ IcedTea is derived from OpenJDK, Sun's open-source implementation of the Java SE platform. At this time the build from which IcedTea was constructed corresponds to an early build of JDK 7. When JDK 7 is complete it will implement the Java SE 7 Platform Specification. Work on that specification is underway, but far from final. Any APIs in the JDK 7 implementation, whether new or old, are therefore subject to minor adjustments, major revisions, or even outright removal between now and the time that the Java SE 7 Platform Specification is finalized. Please take these facts into account before depending upon IcedTea. java-1.6.0-icedtea will be the "stable" version that is as close as possible to standard 1.6 compatibility as possible. --- From a compatibility point of view the 1.6.0 version should be shipped as default. The reason IcedTea started with 1.7.0 was because that was the code that was available. Getting it liberated completely and bootstrapping with the free gnu java toolchain was priority one. Now that that work is stabilizing and the new work done upstream on openjdk6, we can concentrate on this more standards compatible version.
I have updated the srpm. The link is still the same.
When updating the package you should bump the release and add a changelog entry so that it is known what was changed.
i have only been updated the sources, so I didn't see a need. I will in the future.
Updated sources to b06 http://langel.fedorapeople.org/java-1.6.0-icedtea/java-1.6.0-icedtea-1.6.0.0-0.1.b06.fc9.src.rpm http://langel.fedorapeople.org/java-1.6.0-icedtea/java-1.6.0-icedtea.spec
Changing package name to java-1.6.0-openjdk New srpm and spec file: *** This bug has been marked as a duplicate of 436022 ***
Reopening and changing summary to maintain CC list and discussion.
*** Bug 436022 has been marked as a duplicate of this bug. ***
The intention is that java-1.6.0-openjdk will replace java-1.7.0-icedtea in Fedora 9. java-1.7.0-icedtea represents a pre-alpha snapshot of Sun's OpenJDK 7 development branch, whereas java-1.6.0-openjdk will track the stable OpenJDK 6 branch. OpenJDK 7 final isn't scheduled for release until sometime in 2009, so it's far out, even for Fedora. We'd prefer not to ship both because we want to limit confusion among Fedora users (which should they use?) and we don't want to needlessly add size to the distribution.
Links to appropriate srpm and spec file (as noted on Bug #436022) http://langel.fedorapeople.org/java-1.6.0-openjdk/java-1.6.0-openjdk.spec http://langel.fedorapeople.org/java-1.6.0-openjdk/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc9.src.rpm
rpmlint output: $ rpmlint ~/Desktop/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc9.src.rpm java-1.6.0-openjdk.src:60: E: hardcoded-library-path in %{_prefix}/lib Fixing this is hard. It involves making jpackage-utils multilib compatible. Work is progressing toward that goal but it is blocked on this rpm bug: https://bugzilla.redhat.com/show_bug.cgi?id=340391 Work is also proceeding on fixing that bug, but slowly. java-1.6.0-openjdk.src:299: E: configure-without-libdir-spec java-1.6.0-openjdk.src:314: E: configure-without-libdir-spec java-1.6.0-openjdk.src:321: E: configure-without-libdir-spec None of these configured codebases -- IcedTea, GNOME Java Access Bridge, Mauve -- is installed. There may be no harm in adding --libdir=%{_libdir} to satisfy rpmlint though. java-1.6.0-openjdk.src: W: patch-not-applied Patch1: java-1.6.0-openjdk-win32.patch java-1.6.0-openjdk.src: W: patch-not-applied Patch2: java-1.6.0-openjdk-jhat.patch Fix. java-1.6.0-openjdk.src: W: strange-permission generate-fedora-zip.sh 0775 Fix. $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk.i386: E: non-standard-dir-perm /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/zi/Australia 02755 ... Fix and add FIXME comment saying we need to fix this upstream. java-1.6.0-openjdk.i386: W: file-not-utf8 /usr/share/doc/java-1.6.0-openjdk-1.6.0.0/THIRD_PARTY_README Fix and add FIXME comment saying we need to fix this upstream. java-1.6.0-openjdk.i386: W: incoherent-version-in-changelog 1:1.6.0.0-.1.b06 1:1.6.0.0-0.1.b06.fc8 Fix. java-1.6.0-openjdk.i386: E: useless-explicit-provides jdbc-stdext I checked Rawhide: it's safe to remove this line and the explanatory comment: Provides: jdbc-stdext = %{epoch}:%{version} since Fedora packages refer to either the versionless jdbc-stdext provides or the JDBC API version. But can you add the leading 0: to the 3.0 provides? java-1.6.0-openjdk.i386: E: binary-or-shlib-defines-rpath /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/keytool ['$ORIGIN/../lib/i386/jli', '$ORIGIN/../jre/lib/i386/jli'] ... rpmlint bug: https://bugzilla.redhat.com/show_bug.cgi?id=436486 java-1.6.0-openjdk.i386: E: file-in-usr-marked-as-conffile /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/security/cacerts ... These should probably eventually be replaced by symlinks somewhere into /etc, but we'll need to discuss this with OpenJDK upstream developers. Can you add a FIXME comment in the %files section saying so? java-1.6.0-openjdk.i386: W: uncompressed-zip /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/jsse.jar ... rpmlint bug: https://bugzilla.redhat.com/show_bug.cgi?id=436487 $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-devel-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk-devel.i386: W: file-not-utf8 /usr/share/doc/java-1.6.0-openjdk-devel-1.6.0.0/THIRD_PARTY_README Fix. java-1.6.0-openjdk-devel.i386: E: non-standard-dir-perm /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include 02755 ... Fix. java-1.6.0-openjdk-devel.i386: W: dangling-relative-symlink /usr/lib/jvm-exports/java-1.6.0-openjdk java-1.6.0-openjdk-1.6.0.0 Fine for now, since devel package requires base package which provides the fully-versioned directory. In the future we may want to eliminate these fully-versioned directories. They're slightly irritating because rpmdiff can't handle them properly, and also because they're simply redundant. java-1.6.0-openjdk-devel.i386: E: binary-or-shlib-defines-rpath /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/bin/jsadebugd ['$ORIGIN/../lib/i386/jli', '$ORIGIN/../jre/lib/i386/jli'] ... rpmlint bug, see above. java-1.6.0-openjdk-devel.i386: W: uncompressed-zip /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/lib/tools.jar rpmlint bug, see above. $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-demo-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk-demo.i386: E: non-standard-dir-perm /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/demo/jvmti 02755 ... Fix. java-1.6.0-openjdk-demo.i386: E: invalid-soname /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/demo/jvmti/mtrace/lib/libmtrace.so libmtrace.so ... These are dlopend, so their SONAMEs are fine. rpmlint should probably recognize that these are not in standard library location and assume they're dlopened. Here's the bug: https://bugzilla.redhat.com/show_bug.cgi?id=436497 $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-javadoc-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk-javadoc.i386: E: non-standard-dir-perm /usr/share/javadoc/java-1.6.0-openjdk/api/java/util/jar 02755 ... Fix. $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-src-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk-src.i386: E: only-non-binary-in-usr-lib This error probably shouldn't apply to subpackages: https://bugzilla.redhat.com/show_bug.cgi?id=436500 $ rpmlint -i /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-debuginfo-1.6.0.0-0.1.b06.fc8.i386.rpm Lots of errors. I'll assume that the debuginfo subpackage isn't expected to be rpmlint-clean. MUST - package naming The package is not named according to the Package Naming Guidelines. It is named according to JPackage naming conventions - spec file name matches base package name - package follows Packaging Guidelines - acceptable license - license field matches actual license - license file marked as %doc in base package - American English - spec file is legible - didn't check md5sum The tarball is a snapshot from the IcedTea Mercurial repository. It is not released so I can't check the md5sum. - package builds on x86 - package should build on all architectures (IcedTea 7 does) - all build requirements listed - no locales - no shared libraries - not relocatable - owns all directories I believe so. To be clear about this though, I'd prefer not to use the -f option to the base and demo files sections, and instead list all files explicitly. This is more verbose but less error prone. This is not a blocker for acceptance of this package though -- we can do this in a subsequent Rawhide update. - check no duplicate files I'm seeing these warnings: *** WARNING: identical binaries are copied, not linked: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/bin/keytool and /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/keytool Can you add a FIXME comment to look into hard-linking these instead? (symlinking won't work since relative directories are calculated based on these tools' fully-expanded locations.) - correct permissions No. See rpmlint output. - clean section - consistent macro use - package contains code - javadoc subpackage - runtime doesn't need docs - header files in -devel package The java-1.6.0-openjdk-devel subpackage isn't a typical Fedora devel package. Instead "-devel" here means "SDK tools". - no static libraries - no pkgconfig files - no suffixed libraries - devel subpackage requires base - no libtool archives - no desktop files - no dual directory ownership - buildroot removed at start of %install - filenames valid UTF-8 SHOULD - license text included - no summary translations - didn't try building in mock - didn't try building on non-x86 architectures - basic functionality works Yes. "Hello World" compiles and runs - sane scriptlets Lots of use of alternatives, but warranted. - subpackages require base package All subpackages except the javadoc subpackage require the base package. - no pkgconfig file - owns its own directories Yes. Requires jpackage-utils for lower-level directories.
rpmlint output: $ rpmlint ~/Desktop/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc9.src.rpm java-1.6.0-openjdk.src: W: patch-not-applied Patch1: java-1.6.0-openjdk-win32.patch java-1.6.0-openjdk.src: W: patch-not-applied Patch2: java-1.6.0-openjdk-jhat.patch Patches are applied, but not using the method expected %patch1. java-1.6.0-openjdk.src: W: strange-permission generate-fedora-zip.sh 0775 Fixed. $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk.i386: E: non-standard-dir-perm /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/zi/Australia 02755 ... I don't see this problem. java-1.6.0-openjdk.i386: W: file-not-utf8 /usr/share/doc/java-1.6.0-openjdk-1.6.0.0/THIRD_PARTY_README Fixed java-1.6.0-openjdk.i386: W: incoherent-version-in-changelog 1:1.6.0.0-.1.b06 1:1.6.0.0-0.1.b06.fc8 Fixed java-1.6.0-openjdk.i386: E: useless-explicit-provides jdbc-stdext Fixed java-1.6.0-openjdk.i386: E: file-in-usr-marked-as-conffile /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/security/cacerts ... These should probably eventually be replaced by symlinks somewhere into /etc, but we'll need to discuss this with OpenJDK upstream developers. Can you add a FIXME comment in the %files section saying so? Done. java-1.6.0-openjdk-devel.i386: W: file-not-utf8 /usr/share/doc/java-1.6.0-openjdk-devel-1.6.0.0/THIRD_PARTY_README Fixed java-1.6.0-openjdk-devel.i386: E: non-standard-dir-perm /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/include 02755 ... Don't see these problems. $ rpmlint /notnfs/fitzsim/rpmbuild/RPMS/i386/java-1.6.0-openjdk-javadoc-1.6.0.0-0.1.b06.fc8.i386.rpm java-1.6.0-openjdk-javadoc.i386: E: non-standard-dir-perm /usr/share/javadoc/java-1.6.0-openjdk/api/java/util/jar 02755 ... Don't see this. MUST - check no duplicate files I'm seeing these warnings: *** WARNING: identical binaries are copied, not linked: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/bin/keytool and /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/bin/keytool I added a comment about this. srpm and spec file updated: http://langel.fedorapeople.org/java-1.6.0-openjdk/java-1.6.0-openjdk.spec http://langel.fedorapeople.org/java-1.6.0-openjdk/java-1.6.0-openjdk-1.6.0.0-0.1.b06.fc9.src.rpm
The permissions differences are strange. We'll have to run rpmlint on the packages produced by koji. When you commit this can you add another FIXME comment above the iconv lines, saying that we need to fix this upstream? Approved.
New Package CVS Request ======================= Package Name: java-1.6.0-openjdk Short Description: OpenJDK 6 Owners: fitzsim,langel Branches: InitialCC: Cvsextras Commits: yes
Just a few comments/issues I see: - Why the Epoch: 1? - Does %{?_smp_mflags} not work? If not, might add a comment about it... if it does, it would speed up building a good amount. It's pretty impressive that there are only 2 patches to get this building in fedora. ;) cvs done.
Hmmm, in some ways this is a downgrade, I'd have expected Fedora to stay with the 1.7 version... > Changing package name to java-1.6.0-openjdk Uh, why? This is still coming from the IcedTea tree, not vanilla OpenJDK. IMHO, it should be named java-1.6.0-icedtea6, as "icedtea6" is the name your upstream tarballs go under. > It's pretty impressive that there are only 2 patches to get this building in > fedora. ;) Only because all the other patches are in the IcedTea tree (which is why I consider the name to be misleading).
(In reply to comment #16) > Just a few comments/issues I see: > > - Why the Epoch: 1? Yes, we'll have to add a comment to the spec file about this. This is required because of an oversight in JPackage that was brought into RHEL. Here's the comment we'll add: # java-1.5.0-ibm from jpackage.org set Epoch to 1 for unknown reasons, # and this change was brought into RHEL-4. java-1.5.0-ibm packages # also included the epoch in their virtual provides. This created a # situation where in-the-wild java-1.5.0-ibm packages provided "java = # 1:1.5.0". In RPM terms, "1.6.0 < 1:1.5.0" since 1.6.0 is # interpreted as 0:1.6.0. So the "java >= 1.6.0" requirement would be # satisfied by the 1:1.5.0 packages. Thus we need to set the epoch in # JDK package >= 1.6.0 to 1, and packages referring to JDK virtual # provides >= 1.6.0 must specify the epoch, "java >= 1:1.6.0". > > - Does %{?_smp_mflags} not work? If not, might add a comment about it... if it > does, it would speed up building a good amount. No, OpenJDK's Makefiles don't support -j. I'll add a comment in the spec file that we should fix this upstream.
(In reply to comment #17) > Hmmm, in some ways this is a downgrade, I'd have expected Fedora to stay with > the 1.7 version... > > > Changing package name to java-1.6.0-openjdk > > Uh, why? This is still coming from the IcedTea tree, not vanilla OpenJDK. IMHO, > it should be named java-1.6.0-icedtea6, as "icedtea6" is the name your upstream > tarballs go under. See Comment #10 for some explanation. Further to those reasons, with Sun releasing replacements for the rest of the encumbrances, OpenJDK now comprises ~99% of the code in this package. IcedTea does still provide two significant pieces: a plugin and NetX support. Basically though, this name change is "forward looking". IcedTea's mandate was never to continue indefinitely as its own project. The intention for it was always to merge as much as possible with upstream OpenJDK. IcedTea served a useful purpose in making OpenJDK useful immediately in Fedora 8 but its relevance is declining, and will hopefully decline further in the future as we merge our patches upstream. > > > It's pretty impressive that there are only 2 patches to get this building in > > fedora. ;) > > Only because all the other patches are in the IcedTea tree Right. We designed IcedTea's repository to follow the RPM "pristine sources" philosophy; the patches IcedTea applies could easily be hosted in Fedora CVS. As the cross-distro IcedTea patches are accepted upstream I expect to see a shift to each distribution maintaining distro-specific patch sets within their respective package source repositories. For now though there's still value in collaborating with other distros on common problems, in the IcedTea repository. > (which is why I > consider the name to be misleading). I wouldn't say the name is misleading -- Source1 is the OpenJDK tarball and contributes ~99% of the package's code.
Would it be possible to also add this package to EPEL5?
Erik: Currently it depends on lesstif (has to be branched for EPEL, not a big deal), freetype >= 2.3.0 (not a BR, but complains during the build. probably would work even with older one that's in RHEL?), and newer jpackage-utils and tzdata-java than are in RHEL. Probably there can be a way found to work this around, I'll experiment a bit when my initial build is done (and will publish a repo with this, if anyone's interested). Moreover, it can be bootstrapped with gcj-1.5.0, but only 1.4.2 is avaliable. This can be probably worked around by manually adding java-1.6.0-openjdk-devel to the EPEL build root. I am bootstrapping with one from f9 and it seems to be sufficient.
Erik: Here's my build of openjdk for RHEL-5, with packages that are not in EPEL: [1]. Dependencies were grabbed from dist-f9, tzdata was changed due to #437150. Should we open another bug for efforts to get that in EPEL, so we don't spam people that were interested in review request into rawhide? [1] http://netbsd.sk/~lkundrak/openjdk-el5/ (will probably be subject to move to http://people.redhat.com/lkundrak/openjdk-el5/ but I am over quota and am waiting for extension approval :)
Great job! I'll try out your repo in a couple of days to install a package called Alfresco which requires Java 1.6 on a CentOS 5 machine. I'll let you know if I notice anything strange.
Would having java-1.6.0-openjdk in EPEL cause conflicts if it were introduced later in RHEL?
Thomas: Not necessarily. It could be removed from EPEL for that release. To allow smooth update you would just bump the revision to be bigger that one of the package in EPEL. We can agree on some revision number and keep the revision number of the EPEL package smaller than it.
I updated the Java release notes for Fedora 9: http://fedoraproject.org/wiki/Docs/Beats/Java
(In reply to comment #22) > Erik: Here's my build of openjdk for RHEL-5, with packages that are not in EPEL: > [1]. I've just tried installing a fresh CentOS 5 system with your repo enabled during the installation and your packages were automatically pulled in. However, when installing Tomcat5 I get the following error : Updating : tomcat5 ####################### [48/74] /usr/bin/build-jar-repository: error: Could not find ecj Java extension for this JVM /usr/bin/build-jar-repository: error: Some specified jars were not found for this jvm This failure makes it impossible to run a tomcat based web-application. I've tried rebuilding eclipse(-ecj) against java-1.6.0-openjdk, but this fails.
(In reply to comment #22) > Should we open another bug for efforts to get that in EPEL, so we don't spam > people that were interested in review request into rawhide?(In reply to comment #27) (In reply to comment #27) > However, when installing Tomcat5 I get the following error : > Updating : tomcat5 ####################### [48/74] > /usr/bin/build-jar-repository: error: Could not find ecj Java extension for this JVM > /usr/bin/build-jar-repository: error: Some specified jars were not found for > this jvm Works for me, on fairly minimal RHEL-5. > > This failure makes it impossible to run a tomcat based web-application. I've > tried rebuilding eclipse(-ecj) against java-1.6.0-openjdk, but this fails.
Has anyone looked at building on EL4?
Progress on RHEL packaging -> bug #438069