This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 253691 - Review Request: java-1.7.0-icedtea - IcedTea runtime and development environments
Review Request: java-1.7.0-icedtea - IcedTea runtime and development environm...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-21 06:26 EDT by Thomas Fitzsimmons
Modified: 2007-11-30 17:12 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-28 17:14:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
stickster: fedora_requires_release_note+
overholt: fedora‑review+
a.badger: fedora‑cvs+


Attachments (Terms of Use)
install the plugin at /usr/lib64/mozilla/plugins under x86_64 (1.47 KB, patch)
2007-08-25 21:14 EDT, Kostas Georgiou
no flags Details | Diff
rpmlint output on x86_64 (26.55 KB, text/plain)
2007-08-27 14:56 EDT, Andrew Overholt
no flags Details

  None (edit)
Description Thomas Fitzsimmons 2007-08-21 06:26:03 EDT
Spec URL: http://icedtea.classpath.org/hg/fedora/file/d30f0842b5c3/java-1.7.0-icedtea.spec
SRPM URL: http://icedtea.classpath.org/download/fedora/java-1.7.0-icedtea-1.7.0.0-0.11.b18.snapshot.nosrc.rpm
Description:
The IcedTea runtime and development environments.
Comment 1 Thomas Fitzsimmons 2007-08-21 07:06:36 EDT
rpmlint commentary:

$ rpmlint java-1.7.0-icedtea-1.7.0.0-0.11.b18.snapshot.nosrc.rpm
E: java-1.7.0-icedtea hardcoded-library-path in %{_prefix}/lib

  See comment in spec file:

  # Hard-code libdir on 64-bit architectures to make the 64-bit JDK
  # simply be another alternative.

E: java-1.7.0-icedtea configure-without-libdir-spec

  The %configure macro causes problems for IcedTea.  I plan to fix this before
  Fedora 8, but it doesn't seem release critical.

$ rpmlint java-1.7.0-icedtea-1.7.0.0-0.11.b18.snapshot.i586.rpm
E: java-1.7.0-icedtea useless-explicit-provides jdbc-stdext

  This comes from JPackage.  I'll remove it from the next package build.

E: java-1.7.0-icedtea binary-or-shlib-defines-rpath
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/bin/keytool
['$ORIGIN/../lib/i386/jli', '$ORIGIN/../jre/lib/i386/jli']

  rpmlint should check for $ORIGIN before issuing this message since $ORIGIN
  rpaths are not hard-coded.

E: java-1.7.0-icedtea file-in-usr-marked-as-conffile
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/security/cacerts

  IcedTea expects jre/lib/security files to be in this location.  I plan to fix
  this before Fedora 8 but it is not release-critical.

W: java-1.7.0-icedtea uncompressed-zip
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/jsse.jar

  This is an rpmlint bug: the jar file is compressed.

$ rpmlint java-1.7.0-icedtea-demo-1.7.0.0-0.11.b18.snapshot.i586.rpm
W: java-1.7.0-icedtea-demo devel-file-in-non-devel-package
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/demo/jvmti/hprof/src/hprof_error.h

  These are fine since the demo package contains demos geared towards
  developers.

E: java-1.7.0-icedtea-demo non-standard-executable-perm
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/sample/scripting/scriptpad/src/scripts/memory.sh
0555
E: java-1.7.0-icedtea-demo script-without-shebang
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/sample/scripting/scriptpad/src/scripts/memory.sh

  I'll fix these in the next package build.

E: java-1.7.0-icedtea-demo invalid-soname
/usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/demo/jvmti/mtrace/lib/libmtrace.so
libmtrace.so

  These files are meant to be dlopen'd, not linked-to directly, so they should
  not have a versioned soname.

$ rpmlint java-1.7.0-icedtea-devel-1.7.0.0-0.11.b18.snapshot.i586.rpm 
W: java-1.7.0-icedtea-devel dangling-relative-symlink
/usr/lib/jvm-exports/java-1.7.0-icedtea java-1.7.0-icedtea-1.7.0.0

  /usr/lib/jvm-exports/java-1.7.0-icedtea-1.7.0.0 is provided by the base
  package which java-1.7.0-icedtea-devel requires.

$ rpmlint java-1.7.0-icedtea-javadoc-1.7.0.0-0.11.b18.snapshot.i586.rpm

  No warnings or errors.

$ rpmlint java-1.7.0-icedtea-plugin-1.7.0.0-0.11.b18.snapshot.i586.rpm
W: java-1.7.0-icedtea-plugin no-documentation

  This subpackage doesn't require documentation.

$ rpmlint java-1.7.0-icedtea-rmi-1.7.0.0-0.11.b18.snapshot.i586.rpm
W: java-1.7.0-icedtea-plugin no-documentation

  Likewise.

$ rpmlint java-1.7.0-icedtea-src-1.7.0.0-0.11.b18.snapshot.i586.rpm
W: java-1.7.0-icedtea-src no-documentation

  Likewise.

E: java-1.7.0-icedtea-src only-non-binary-in-usr-lib

  Applications that refer to src.zip expect it to be in JAVA_HOME.
Comment 2 Thomas Fitzsimmons 2007-08-21 07:10:37 EDT
I noticed that I didn't package the IcedTea documentation.  I'll do so in the
next build.
Comment 3 Ville Skyttä 2007-08-21 07:49:33 EDT
(In reply to comment #1)

Not a full review, just a few observations:

> E: java-1.7.0-icedtea binary-or-shlib-defines-rpath
> /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/bin/keytool
> ['$ORIGIN/../lib/i386/jli', '$ORIGIN/../jre/lib/i386/jli']
> 
>   rpmlint should check for $ORIGIN before issuing this message since $ORIGIN
>   rpaths are not hard-coded.

Not all $ORIGIN RPATHs are desirable anyway though.  See
/usr/lib/rpm/check-rpaths-worker in >= 4.4.2.1 rpm-build versions (or
rpmdevtools <= 5.4) and/or try building the package with these checks enabled
(see rpmdev-setuptree) to see if it flags them as bad.

> W: java-1.7.0-icedtea uncompressed-zip
> /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/jsse.jar
> 
>   This is an rpmlint bug: the jar file is compressed.

Can you upload the binary package or just the jsse.jar which triggers this
message somewhere so I can check what's up?

> E: java-1.7.0-icedtea-demo invalid-soname
> /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0/demo/jvmti/mtrace/lib/libmtrace.so
> libmtrace.so
> 
>   These files are meant to be dlopen'd, not linked-to directly, so they should
>   not have a versioned soname.

Isn't versioning the very purpose of sonames?  What would a versionless soname
be useful for?
Comment 4 Thomas Fitzsimmons 2007-08-21 11:12:26 EDT
I ran:

find /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0 -type f -print0 | xargs -0r
/usr/lib/rpm/check-rpaths-worker

and it didn't produce any warning or error messages.

I was wrong about the uncompressed-zip warnings: the jars are created with jar
c0mf, probably to speed class loading.  Are most jars created this way for
lookup speed?  If so, maybe rpmlint should treat jars differently from zip files...

Yes, you're right: I should eliminate soname generation altogether for those
dlopen'd DSOs.
Comment 5 Ville Skyttä 2007-08-21 11:46:55 EDT
It's very much possible that rpmlint's checks could be improved regarding jars,
or perhaps messages filtered out altogether if it's not clear that compressed or
uncompressed jars are in most cases a better choice (classloading performance vs
space savings balanced) for Fedora than the other choice.  I don't have any
numbers nor really even a gut feeling for this.

Regarding classloading from jars, somewhat off topic for this review, it could
also be interesting to see if indexing the jars makes any performance difference
if the jar tool in use supports indexing them (the -i option) and the runtime
uses the indexes (of course if indexing is free of side effects).
Comment 6 Peter Lemenkov 2007-08-23 07:36:46 EDT
Why not to provide all necessary files in SRPM-package? Why it's ugly
nosrc-package? Looks like something from the past, then we can't distribute java
sourcecode. 

Another one technical note - it's a bad idea not to provide direct link to
spec-file but only link to mercurial page.

And one more tech note:

[petro@host-12-89 SPECS]$ LANG=C rpmbuild -ba java-1.7.0-icedtea.spec 
error: Architecture is not included: i386
[petro@host-12-89 SPECS]$

So... Java cannot be built on x86?!
Comment 7 Andrew Haley 2007-08-23 07:39:43 EDT
There were some legal issues covering some of the files which didn't appear to
be free software.  We've fixed those now and we expect soon to provide a real RPM.

Comment 8 Thomas Fitzsimmons 2007-08-23 09:38:00 EDT
The nosrc format also conserves space and bandwidth for icedtea.classpath.org
which is hosted by a GNU Classpath community member.  The first SRPM will be
available when the first Fedora build completes.

Why not refer to a Mercurial revision?

Try:

LANG=C rpmbuild -ba --target i586 java-1.7.0-icedtea.spec

It's an i586 RPM rather than an i386 RPM because the JIT emits i586-level
instructions that will not run on processors earlier than i586.
Comment 9 Peter Lemenkov 2007-08-23 10:09:35 EDT
> Why not refer to a Mercurial revision?

wget downloads html garbage instead of pretty spec-file.
Comment 10 Thomas Fitzsimmons 2007-08-23 10:15:23 EDT
I'll post the raw-file link instead:

http://icedtea.classpath.org/hg/fedora/raw-file/d30f0842b5c3/java-1.7.0-icedtea.spec
Comment 11 Andrew Overholt 2007-08-23 11:41:19 EDT
A few initial questions:

- why the need for "snapshot" in the release?
- is the license tag okay as it's stated?
- where does the access bridge source come from?
- is generate-cacerts.pl in version control somewhere?
- do we really need the registered trademark notice in %description?
- why doesn't the CGI script work on x86_64?  can we have a note about it in the
spec?
- rather than "IcedTea Plugin" can we have something more descriptive?  "Browser
plugin" or "Mozilla plugin" or something?
- why the two stages of symlinking around line 313?
- why the ghost touching?
- should the man pages work with alternatives?  or do I always have to use 'man
java-java-1.7.0-icedtea?  looking at the stuff in %post, it appears it should work.
- do some of the single quotes around line 384 need escaping?
- you had mentioned issues with binfmt_misc at one point to me - is that sorted out?
- wow, the number of alternatives is crazy!

I'll try building now.
Comment 12 Thomas Fitzsimmons 2007-08-23 11:46:19 EDT
(In reply to comment #11)

> I'll try building now.

Before you try a Rawhide mock build, I should point out that IcedTea doesn't
build in Rawhide yet because of a bug in eclipse-ecj 3.3:

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=61

The SRPM will build fine on Fedora 7 though, and I'll include Francis's
workaround in the next review package.
Comment 13 Thomas Fitzsimmons 2007-08-23 12:09:13 EDT
(In reply to comment #11)
> A few initial questions:
> 
> - why the need for "snapshot" in the release?

The release string format is: significant_digits.OpenJDK_build.IcedTea_version

IcedTea_version = snapshot means that the IcedTea tarball is a snapshot rather
than an IcedTea release.  I will include IcedTea 1.3 when it is released.

> - is the license tag okay as it's stated?

Yes, that's the new rpmlint-suggested License tag format.

> - where does the access bridge source come from?

http://ftp.gnome.org/pub/GNOME/sources/java-access-bridge/

I'll add a comment in the spec file.

> - is generate-cacerts.pl in version control somewhere?

Yes:

http://icedtea.classpath.org/hg/fedora/raw-file/f38a4e9e2134/generate-cacerts.pl

> - do we really need the registered trademark notice in %description?

No, I suppose not.

> - why doesn't the CGI script work on x86_64?  can we have a note about it in the
> spec?

No good reason I can see.  We plan to enable it before Fedora 8.  I can add a
comment in the meantime.

> - rather than "IcedTea Plugin" can we have something more descriptive?  "Browser
> plugin" or "Mozilla plugin" or something?

Sure.

> - why the two stages of symlinking around line 313?

So that you can specify e.g., "a sasl jar", "a sasl 1.7.0 jar" or "the sasl
1.7.0.0 jar".

$ ls -l /usr/lib/jvm-exports/jre-1.7.0-icedtea/sasl*
lrwxrwxrwx 1 root root 51 2007-07-14 21:51
/usr/lib/jvm-exports/jre-1.7.0-icedtea/sasl-1.7.0.0.jar ->
../../jvm/java-1.7.0-icedtea-1.7.0.0/jre/lib/rt.jar
lrwxrwxrwx 1 root root 16 2007-07-14 21:51
/usr/lib/jvm-exports/jre-1.7.0-icedtea/sasl-1.7.0.jar -> sasl-1.7.0.0.jar
lrwxrwxrwx 1 root root 16 2007-07-14 21:51
/usr/lib/jvm-exports/jre-1.7.0-icedtea/sasl.jar -> sasl-1.7.0.0.jar

> - why the ghost touching?

ISTR this addressing some RPM warning.  I'll experiment with it for the next
package build.

> - should the man pages work with alternatives?  or do I always have to use 'man
> java-java-1.7.0-icedtea?  looking at the stuff in %post, it appears it should
work.

They should work, e.g. "man java" should bring up java-java-1.7.0-icedtea when
IcedTea's java alternative is selected.

> - do some of the single quotes around line 384 need escaping?

No, the three strings are concatenated in shell, e.g.:

$ echo 'a'b'c'
abc

> - you had mentioned issues with binfmt_misc at one point to me - is that
sorted out?

I'm not sure what issues I mentioned.  I enabled binfmt_misc as an experiment so
that people could try it.  I'm not sure if it's useful or not.  It only helps on
the command-line, since GNOME uses a different mechanism for executing files.

> - wow, the number of alternatives is crazy!

Yes, but all (except maybe the jce policy one) are necessary.
Comment 14 Thomas Fitzsimmons 2007-08-23 16:19:45 EDT
Here are the updated spec file and nosrc RPM, which have the ecj 3.3 workaround
and should build in Rawhide:

Spec URL:
http://icedtea.classpath.org/hg/fedora/raw-file/7d5daf9e46e0/java-1.7.0-icedtea.spec
SRPM URL:
http://icedtea.classpath.org/download/fedora/java-1.7.0-icedtea-1.7.0.0-0.12.b18.snapshot.nosrc.rpm

I'm testing a mock build now.  Here's the changelog:

- Fully qualify Java Access Bridge for GNOME and generate-cacerts
  source paths.
- Fix plugin post alternatives invocation.
- Include IcedTea documentation.
- Update icedteasnapshot.

I didn't fix items that don't seem release-critical: I didn't fix memory.sh
because it's only a demo file, I didn't eliminate sonames in demo files and I
didn't look into why we touch ghosted files.  I'll fix all these later in the
Fedora 8 release cycle.

With the inclusion of the IcedTea documentation the licensing situation is now
clearly explained.  The NoSource comment was out-dated so I updated it.  Here is
the relevant excerpt from IcedTea's README:

  A Note About License Headers
  ----------------------------

  Some sources downloaded from openjdk.java.net do not display the GPL
  license header.  Instances are:

   - The files in openjdk/j2se/src/share/classes/javax/xml/stream/ seem to 
     comprise the BEA-StAX source code

     http://ftpna2.bea.com/pub/downloads/jsr173.jar

     with some Sun-specific modifications.  We're assuming that Sun is
     bundling BEA-StAX under the terms of the Apache License 2.0 and
     that the modifications are owned by Sun.

   - We are assuming that these files are owned by Sun:
     openjdk/j2se/src/share/classes/**/resources/*.properties

  The downloaded sources include two scripts that insert proprietary
  license headers into the source files they generate.  The scripts
  themselves are GPL'd so we patched them to emit the GPL header.  These
  files are:

    openjdk/j2se/make/java/nio/genExceptions.sh
    openjdk/hotspot/src/share/vm/prims/jvmtiLib.xsl

I've CC'ed Tom Callaway for a second opinion:  Tom does this reasoning satisfy
you that IcedTea can be shipped in Fedora?
Comment 15 Kostas Georgiou 2007-08-23 19:31:13 EDT
Is it sensible to drop java-rmi.cgi in cgi-bin considering that it's puprose is
to tunnel rmi to any host/port bypassing any local firewall? Here is what
http://java.sun.com/developer/onlineTraining/rmi/RMI.html says about it:

"Additionally, using the java-rmi.cgi script exposes a fairly large security
loophole on your server machine, as now, the script can redirect any incoming
request to any port, completely bypassing your firewalling mechanism."

IMHO it would be better to install it somewhere else, anyone that needs to use
it will have to modify it anyway to restrict to specific ports at the minimum so
it's more of an example than a usefull application.
Comment 16 Thomas Fitzsimmons 2007-08-23 21:02:00 EDT
(In reply to comment #15)
> Is it sensible to drop java-rmi.cgi in cgi-bin considering that it's puprose is
> to tunnel rmi to any host/port bypassing any local firewall? Here is what
> http://java.sun.com/developer/onlineTraining/rmi/RMI.html says about it:
> 
> "Additionally, using the java-rmi.cgi script exposes a fairly large security
> loophole on your server machine, as now, the script can redirect any incoming
> request to any port, completely bypassing your firewalling mechanism."
> 
> IMHO it would be better to install it somewhere else, anyone that needs to use
> it will have to modify it anyway to restrict to specific ports at the minimum so
> it's more of an example than a usefull application.

What about just restricting all ports in the default configuration?  I put
java-rmi.cgi in its own subpackage so that it is completely optional, and to
isolate the cgibindir requirement.  Other options would be to move the script to
the demo subpackage or just not include it in the IcedTea packages.

Is the java-rmi.cgi script actually deployed frequently, or is it just meant as
a demo for system administrators?  The comments seem to suggest that it's useful
in practice and not just a demo.  If it's actually deployed frequently, I'd like
to keep the subpackage + cgibindir requirement + all ports locked down.  This
minimizes the fiddling needed to get the script working while still providing
out-of-the-box security.  On the other hand, if java-rmi.cgi is just a toy then
it should go in the demo subpackage and we can drop the cgibindir requirement in
favour of a README.
Comment 17 Kostas Georgiou 2007-08-24 06:33:10 EDT
(In reply to comment #16)
> What about just restricting all ports in the default configuration?  I put
> java-rmi.cgi in its own subpackage so that it is completely optional, and to
> isolate the cgibindir requirement. Other options would be to move the script to
> the demo subpackage or just not include it in the IcedTea packages.

It got dropped from windows at 1.1
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4418631 and nobody really
cared so I don't think it will be missed here either. 

> Is the java-rmi.cgi script actually deployed frequently, or is it just meant as
> a demo for system administrators?  The comments seem to suggest that it's useful
> in practice and not just a demo.  If it's actually deployed frequently, I'd like
> to keep the subpackage + cgibindir requirement + all ports locked down.  This
> minimizes the fiddling needed to get the script working while still providing
> out-of-the-box security.  On the other hand, if java-rmi.cgi is just a toy then
> it should go in the demo subpackage and we can drop the cgibindir requirement in
> favour of a README.

I never had to deploy it but I don't have any rmi programs either. I suspect
that anyone that needs rmi will try to open the firewall ports first and if for
some reason it's not possible and the proxy is required they will go for the
servlet version instead of the cgi. It's best to ask around for someone that
uses rmi just to make sure though.
Comment 18 Andrew Overholt 2007-08-24 10:39:54 EDT
I'll take this.
Comment 19 Thomas Fitzsimmons 2007-08-24 15:51:03 EDT
Andrew requested a full SRPM.  Here it is, along with the exact spec file used
to create it:

Spec URL: http://fedorapeople.org/~fitzsim/java-1.7.0-icedtea.spec
SRPM URL:
http://fedorapeople.org/~fitzsim/java-1.7.0-icedtea-1.7.0.0-0.12.b18.snapshot.src.rpm

In addition, I've posted the IcedTea snapshot so that its md5sum is verifiable:

http://icedtea.classpath.org/download/source/icedtea-1.3-200060a622000dd98da0ad0c3f4d1e5d49e350bc.tar.gz
Comment 20 Andrew Overholt 2007-08-24 16:12:54 EDT
MUST items:

? package is named appropriately
 - falls in line with JPackage JVM naming
 - what's going to happen with the release tag when we hit 1.3?  Will it just
   be 1.3%{?dist}?  Or will we always have the leading
0.NN.%{openjdkver}.%{icedtearelease}?
OK it is legal for Fedora to distribute this
 - assuming the assumptions about the three things listed in comment #14 are
   okay
OK license field matches the actual license.
OK license is open source-compatible.
OK specfile name matches %{name}
NEEDS_FIXING verify source and patches 
 - there's a "1.19" missing in the java-access-bridge URL
 - if I get the actual java-access-bridge tarball, all of the source files check out
OK summary and description fine
OK acceptable buildroot
OK %{?dist} used correctly
OK license text included in package and marked with %doc
OK packages meets FHS (http://www.pathname.com/fhs/)
 - except for the /usr/lib on x86_64 stuff which I'm okay with, I think we're
   good
OK changelog fine
OK Packager tag not used
OK Vendor tag not used
OK Distribution tag not used
OK use License and not Copyright 
OK Summary tag should not end in a period
OK if possible, replace PreReq with Requires(pre) and/or Requires(post)
OK specfile is legible
? package successfully compiles and builds on at least x86
 - I don't have enough disk space on my laptop.  I'm trying a build on another
   box and will report back when it's done.
OK BuildRequires are proper
 - I know Tom's done mock builds so I'm going to assume they're okay
OK summary should be a short and concise description of the package
OK description expands upon summary
OK make sure lines are <= 80 characters
 - except for changelog lines, I think we're okay
OK specfile written in American English
OK make a -doc sub-package if necessary
 - the package layout is JPackage-standard and we have -javadoc for API docs
? packages including libraries should exclude static libraries if possible
 - I guess I'll have to wait until my build finishes
? are the rpath issues all sorted out in the comments above?
OK config files marked with %config(noreplace)
OK not a GUI app so no .desktop
OK macros used appropriately and consistently
OK don't use %makeinstall
OK install section must begin with rm -rf $RPM_BUILD_ROOT or %{buildroot}
OK locale data handling correct (find_lang)
 - no locale data
NEEDS_FIXING consider using cp -p to preserve timestamps
 - can we add -p to the accessibility bridge copying?
OK split Requires(pre,post) into two separate lines
OK package should probably not be relocatable
OK package contains code
OK package should own all directories and files
OK there should be no %files duplicates
OK file permissions should be okay; %defattrs should be present
OK %clean should be present
OK %doc files should not affect runtime
OK rpmlint on <this package>.srpm gives no output

E: java-1.7.0-icedtea hardcoded-library-path in %{_prefix}/lib
 - I'm okay with this as alternatives for x86_64 and 32-bit JVMs is very
   important ... it's also consistent with JPackage standards
E: java-1.7.0-icedtea configure-without-libdir-spec
E: java-1.7.0-icedtea configure-without-libdir-spec
 - I see Tom's comment in comment #1 about this and I'm okay with it.  Does
   anyone disagree?

? verify the final provides and requires of the binary RPMs
 - awaiting results
? run rpmlint on the binary RPMs
 - awaiting results

SHOULD items:

OK package should include license text in the package and mark it with %doc
? package should build on i386
 - awaiting results
? package should build in mock
 - awaiting results

Remaining issues:
- rmi cgi script - are we keeping it?
Comment 21 Thomas Fitzsimmons 2007-08-24 18:41:06 EDT
(In reply to comment #20)
> MUST items:
> 
> ? package is named appropriately
>  - falls in line with JPackage JVM naming
>  - what's going to happen with the release tag when we hit 1.3?  Will it just
>    be 1.3%{?dist}?  Or will we always have the leading

No, the IcedTea release will continue to be encoded in the symbolic part of the
release string.  The 0.X prefix of the release string means that this is a
pre-release of what will become the 1.7.0.0 IcedTea release (derived from the
OpenJDK 1.7.0 final sources).  When 1.7.0.0 is released, the prefix will become
just X, representing a package revision of a final-release package.

> 0.NN.%{openjdkver}.%{icedtearelease}?
> OK it is legal for Fedora to distribute this
>  - assuming the assumptions about the three things listed in comment #14 are
>    okay

I talked to spot about this on IRC and he's fine with our rationale.

> NEEDS_FIXING verify source and patches 
>  - there's a "1.19" missing in the java-access-bridge URL

Fixed.

> ? are the rpath issues all sorted out in the comments above?

There weren't any rpath issues, according to the more-precise-than-rpmlint
checks in check-rpaths-worker.

> NEEDS_FIXING consider using cp -p to preserve timestamps
>  - can we add -p to the accessibility bridge copying?

I'm already using cp -a which implies -p.

> Remaining issues:
> - rmi cgi script - are we keeping it?

No, I removed it.

Spec URL: http://fedorapeople.org/~fitzsim/java-1.7.0-icedtea.spec
SRPM URL:
http://fedorapeople.org/~fitzsim/java-1.7.0-icedtea-1.7.0.0-0.13.b18.snapshot.src.rpm
Comment 22 Kostas Georgiou 2007-08-25 19:14:54 EDT
Under x86_64 the plugin rpm requires and is installed under
/usr/lib/mozilla/plugins, it should be /usr/lib64/mozilla/plugins.
Comment 23 Kostas Georgiou 2007-08-25 21:14:18 EDT
Created attachment 172721 [details]
install the plugin at /usr/lib64/mozilla/plugins under x86_64

Here is a patch to install the plugin at /usr/lib64/mozilla/plugins. Note that
the alternatives name had to be changed to something else than libjavaplugin.so
since otherwise it fails with:

the primary link for libjavaplugin.so must be
/usr/lib/mozilla/plugins/libjavaplugin.so
error: %post(java-1.7.0-icedtea-plugin-1.7.0.0-0.13.b18.snapshotFC7.x86_64)
scriptlet failed, exit status 2
Comment 24 Andrew Overholt 2007-08-27 14:48:36 EDT
My build went fine on x86_64.  I've reviewed the rpmlint output for the binary
RPMs.  When read in light of the comments above, I'm okay with most of the
issues.  I've attached the rpmlint output for brevity's sake.  Here are the only
remaining issues as I see them:

Release critical items:

1. move plugin on x86_64 as per Kostas' patch
2. remove useless-explicit-provides jdbc-stdext
3. are you going to disable soname generation for the dlopen'd .sos?
4. should there be documentation for -plugin and -src?

Non-critical but please fix before F8:

1. fix missing shebang and permissions on
sample/scripting/scriptpad/src/scripts/memory.sh
2. other non-critical items brought up by rpmlint (see comments above and
attached rpmlint output)

Thanks, Tom!  It'll be great to have IcedTea in Fedora.
Comment 25 Andrew Overholt 2007-08-27 14:56:38 EDT
Created attachment 174201 [details]
rpmlint output on x86_64
Comment 26 Thomas Fitzsimmons 2007-08-27 15:04:53 EDT
(In reply to comment #24)

> Release critical items:
> 
> 1. move plugin on x86_64 as per Kostas' patch

Will do.

> 2. remove useless-explicit-provides jdbc-stdext

Although I said I should remove this in the comments above, after re-reading the
comment I left myself in the spec file, I think both these explicit provides are
necessary:

# Both these versioned provides need to be here since either may be
# required explicitly.  Requiring the first one means requiring a
# version of the JDBC API; requiring the second one means requiring
# the JDBC API provided by this version of the JDK.  This convention
# comes from JPackage.

> 3. are you going to disable soname generation for the dlopen'd .sos?

I'd rather that this wait until post-F8 since fixing it will be fiddly and it
won't negatively affect the initial release.

> 4. should there be documentation for -plugin and -src?

Yeah, probably a good idea, just to explain what they are.  I'll write two READMEs.

Some new minor licensing issues came to our attention today.  They're very
similar to the ones we discussed above.  Lillian Angel and I are currently
working around the newly-discovered issues and we'll keep the workaround list
up-to-date in the IcedTea README.  I consider these issues release-critical, but
we should have things ready-to-go by later today.

> 
> Non-critical but please fix before F8:
> 
> 1. fix missing shebang and permissions on
> sample/scripting/scriptpad/src/scripts/memory.sh
> 2. other non-critical items brought up by rpmlint (see comments above and
> attached rpmlint output)

Yes, thanks for the summary.
Comment 27 Thomas Fitzsimmons 2007-08-27 15:13:18 EDT
One more item: we need to patch the version string so that:

$ /usr/lib/jvm/java-1.7.0-icedtea/bin/java -version
java version "1.7.0"
OpenJDK Runtime Environment (build 1.7.0-mockbuild_23_aug_2007_17_44-b00)
OpenJDK Client VM (build 1.7.0-mockbuild_23_aug_2007_17_44-b00, mixed mode)

becomes

$ /usr/lib/jvm/java-1.7.0-icedtea/bin/java -version
java version "1.7.0"
IcedTea Runtime Environment (build 1.7.0-mockbuild_23_aug_2007_17_44-b00)
IcedTea Client VM (build 1.7.0-mockbuild_23_aug_2007_17_44-b00, mixed mode)
Comment 28 Thomas Fitzsimmons 2007-08-28 05:43:43 EDT
Here are the updated spec file and SRPM:

Spec URL: http://fedorapeople.org/~fitzsim/java-1.7.0-icedtea.spec
SRPM URL:
http://fedorapeople.org/~fitzsim/java-1.7.0-icedtea-1.7.0.0-0.14.b18.snapshot.src.rpm

Here is the new snapshot:

http://icedtea.classpath.org/download/source/icedtea-1.3-a9c9ee1b6479a84f2153be67fce85b0dbf371398.tar.gz

The updated SRPM fixes the remaining release-critical items:

1. plugin location on x86_64
2. documentation for -plugin and -src
3. licensing issues
4. s/OpenJDK/IcedTea/ in version output
Comment 29 Peter Lemenkov 2007-08-28 09:06:55 EDT
BTW any chances to see powerpc-version of  IcedTea? 
Comment 30 Andrew Overholt 2007-08-28 09:11:44 EDT
Approved

Thanks, Tom!  I know there's still work to be done, but this is an excellent
addition to Fedora and I look forward to its inclusion.  Don't forget to do the
fedora-cvs flag setting and requesting.  I'd also say that a release note is in
order, but I'll leave that up to you to set the flag or not (not that I really
know what it does ;).
Comment 31 Thomas Fitzsimmons 2007-08-28 09:14:34 EDT
(In reply to comment #29)
> BTW any chances to see powerpc-version of  IcedTea?

We're working on PowerPC support.  We're investigating using CACAO's JIT as a
short-term solution and longer term we're working on a PPC port of Hotspot.
Comment 32 Andrew Overholt 2007-08-28 09:16:16 EDT
I forgot to thank Kostas for his patch and him and everyone else for their
interest in this.
Comment 33 Thomas Fitzsimmons 2007-08-28 09:26:38 EDT
David Walluck pointed out on IRC that IcedTea should use the system versions of
third-party libraries it requires (e.g., libpng).  I agree and wanted to mention
here that we plan to do this work before Fedora 8.

I also wanted to mention another plan to solve a problem brought up in this
discussion:  I would like a cleaner solution to the lib vs lib64 alternatives
naming problem.  I'm toying with the idea of proposing $LIB support for the
alternatives command.
Comment 34 Thomas Fitzsimmons 2007-08-28 09:35:21 EDT
New Package CVS Request
=======================
Package Name: java-1.7.0-icedtea
Short Description: IcedTea
Owners: fitzsim@redhat.com
Branches: FC-6 F-7
InitialCC:
Cvsextras Commits: yes
Comment 35 Toshio Ernie Kuratomi 2007-08-28 10:26:28 EDT
CVS Done.
Comment 36 Thomas Fitzsimmons 2007-08-28 17:14:47 EDT
java-1.7.0-icedtea-1.7.0.0-0.14.b18.snapshot.fc8 built successfully in Rawhide.
Comment 37 Christopher Stone 2007-09-08 13:03:56 EDT
Hey, I noticed these were branched for F7, I gave it a whirl and compiled your
SRPM for F7 and it seems to work.  Are there plans to build this for FC-6/F7?
Comment 38 Paul W. Frields 2007-09-15 14:24:38 EDT
Definitely should be included in the F8 Release Notes.  The Docs Project could
use some help in including the content, since we are very short on manpower at
the moment.  You can edit content on this page:

http://fedoraproject.org/wiki/Docs/Beats/Java

Edits will be picked up by a number of channels we have for notification, so we
will see it, do any grammar/style editing necessary, and pass it on to
translators.  If any knowledgeable individual on this bug's CC list could do
this in the next 72 hours, that would be very helpful.  Thanks!

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