Bug 433070 - Review Request: java-1.6.0-openjdk - The OpenJDK 1.6.0 runtime environment
Review Request: java-1.6.0-openjdk - The OpenJDK 1.6.0 runtime environment
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Thomas Fitzsimmons
Fedora Extras Quality Assurance
: Reopened
: 436022 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-15 17:22 EST by Lillian Angel
Modified: 2013-01-09 23:34 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-10 10:21:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
fitzsim: fedora_requires_release_note?
fitzsim: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Comment 1 Bill Nottingham 2008-02-15 17:55:01 EST
Is there a reason we're going to be shipping two versions?
Comment 2 Mark Wielaard 2008-02-16 06:13:20 EST
(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.
Comment 3 Lillian Angel 2008-02-18 10:29:29 EST
I have updated the srpm. The link is still the same.
Comment 4 Dennis Gilmore 2008-02-18 11:01:25 EST
When updating the package you should bump the release and add a changelog
entry so that it is known what was changed.
Comment 5 Lillian Angel 2008-02-18 11:05:00 EST
i have only been updated the sources, so I didn't see a need. I will in the future.
Comment 7 Lillian Angel 2008-03-04 16:37:09 EST
Changing package name to java-1.6.0-openjdk

New srpm and spec file:


*** This bug has been marked as a duplicate of 436022 ***
Comment 8 Thomas Fitzsimmons 2008-03-04 16:56:39 EST
Reopening and changing summary to maintain CC list and discussion.
Comment 9 Thomas Fitzsimmons 2008-03-04 16:59:46 EST
*** Bug 436022 has been marked as a duplicate of this bug. ***
Comment 10 Thomas Fitzsimmons 2008-03-04 17:02:02 EST
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.
Comment 12 Thomas Fitzsimmons 2008-03-07 11:58:28 EST
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.
Comment 13 Lillian Angel 2008-03-07 16:39:35 EST
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
Comment 14 Thomas Fitzsimmons 2008-03-07 17:41:04 EST
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.
Comment 15 Thomas Fitzsimmons 2008-03-07 17:57:01 EST
New Package CVS Request
=======================
Package Name: java-1.6.0-openjdk
Short Description: OpenJDK 6
Owners: fitzsim,langel
Branches:
InitialCC: 
Cvsextras Commits: yes
Comment 16 Kevin Fenzi 2008-03-08 14:28:34 EST
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.
Comment 17 Kevin Kofler 2008-03-08 18:43:03 EST
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).
Comment 18 Thomas Fitzsimmons 2008-03-09 12:32:35 EDT
(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.
Comment 19 Thomas Fitzsimmons 2008-03-09 12:54:34 EDT
(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.
Comment 20 Erik van Pienbroek 2008-03-11 12:09:37 EDT
Would it be possible to also add this package to EPEL5? 
Comment 21 Lubomir Kundrak 2008-03-12 10:48:16 EDT
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.
Comment 22 Lubomir Kundrak 2008-03-12 17:01:41 EDT
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 :)
Comment 23 Erik van Pienbroek 2008-03-12 17:20:50 EDT
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.
Comment 24 Thomas Fitzsimmons 2008-03-12 17:25:57 EDT
Would having java-1.6.0-openjdk in EPEL cause conflicts if it were introduced
later in RHEL?
Comment 25 Lubomir Kundrak 2008-03-12 17:34:37 EDT
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.
Comment 26 Thomas Fitzsimmons 2008-03-12 17:52:34 EDT
I updated the Java release notes for Fedora 9:

http://fedoraproject.org/wiki/Docs/Beats/Java
Comment 27 Erik van Pienbroek 2008-03-17 11:40:43 EDT
(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.
Comment 28 Lubomir Kundrak 2008-03-17 12:16:10 EDT
(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.

Comment 29 Colin Walters 2008-03-18 15:56:36 EDT
Has anyone looked at building on EL4?
Comment 30 Lubomir Kundrak 2008-03-18 17:01:01 EDT
Progress on RHEL packaging -> bug #438069

Note You need to log in before you can comment on or make changes to this bug.