Bug 417511

Bumped to jruby 1.1rc1. New URLs:
Spec: http://konrad.sobertillnoon.com/fedora/jruby.spec
SRPM: 
http://konrad.sobertillnoon.com/fedora/jruby-1.1-0.3.20080108svn.fc8.src.rpm

Would very much appreciate a review!

I'd wager that most reviewers are going to be waiting for some Java packaging
guidelines first.  Hopefully something will happen there soon.

Many of Fedora's Java packages come either straight or slightly modified from 
the JPackage RPMs. JPackage had an *extremely* outdated jruby package, which I 
have borrowed bits from to make this package.

Bumped to jruby 1.1rc2. New URLs:
Spec: http://konrad.sobertillnoon.com/fedora/jruby.spec
SRPM: 
http://konrad.sobertillnoon.com/fedora/jruby-1.1-0.4.20080216svn.fc8.src.rpm

Well, perhaps for packaging issues this is almost okay,
however:

- To make it sure that this package can be rebuilt from open
  sources really, first please remove all pre-rebuilt binaries
  (like .jar) at %prep.

- In the review we have to check the licenses of all codes in the
  tarball to make it sure that the codes used for jruby are used
  with keeping legal compatibility.

  Would you write the summary about what licenses are used in
  what files in the tarball so that we can check legal issues
  easily?

(In reply to comment #5)
> Well, perhaps for packaging issues this is almost okay,
> however:
> 
> - To make it sure that this package can be rebuilt from open
>   sources really, first please remove all pre-rebuilt binaries
>   (like .jar) at %prep.

Ok. This will take me a bit of time to get worked out.

> - In the review we have to check the licenses of all codes in the
>   tarball to make it sure that the codes used for jruby are used
>   with keeping legal compatibility.
> 
>   Would you write the summary about what licenses are used in
>   what files in the tarball so that we can check legal issues
>   easily?

Sure.

The current status of stuff (or what I would say is most important) is that a 
large portion of the BRs don't exist yet in Fedora (due to the nascent Java 
packaging guidelines) or are hugely outdated. So I predict this package won't 
get in for quite a while because of this.

But here's the shopping list:

* asm 3.0 (we currently have asm2, which is 2.1)
* emma (we don't have this at all yet)
* jarjar (we don't have this either)
* jline (we have 0.9.9, upstream is 0.9.94)
* jna (we don't have it at all)
* joda-time (we don't have it at all)
* joni (we don't have this, but I probably can/will package it)
* junit (we have this one! phew!)
* retroweaver (we don't have this at all either)

So a lot of this stuff needs to enter Fedora before jruby can. I hope that we 
can get this stuff in and then jruby by F10. Maybe that is a lofty goal :).

(In reply to comment #7)
> The current status of stuff (or what I would say is most important) is that a 
> large portion of the BRs don't exist yet in Fedora (due to the nascent Java 
> packaging guidelines) or are hugely outdated. So I predict this package won't 
> get in for quite a while because of this.
> 
> But here's the shopping list:
> 
> * asm 3.0 (we currently have asm2, which is 2.1)
> * emma (we don't have this at all yet)
> * jarjar (we don't have this either)
> * jline (we have 0.9.9, upstream is 0.9.94)
> * jna (we don't have it at all)
> * joda-time (we don't have it at all)
> * joni (we don't have this, but I probably can/will package it)
> * junit (we have this one! phew!)
> * retroweaver (we don't have this at all either)
> 
> So a lot of this stuff needs to enter Fedora before jruby can. I hope that we 
> can get this stuff in and then jruby by F10. Maybe that is a lofty goal :).

Thank you for investigating BR. This list is very useful
for getting jruby into Fedora.

Then would you also write:
- this BR is already in Fedora
- Someone has already submitted a review request for this BR
- Or even no review request has been submitted for this BR
if you know?

BRs currently in Fedora (that are currently shipped from upstream jruby as 
binary .jars):

* asm (old version)
* jline (old version)
* junit

BRs that are not in Fedora but have a review request (that are currently 
shipped from upstream jruby as binary .jars):

* emma (bug# 227052)
* jarjar (bug# 252082)
* joda-time (bug# 227073)

BRs that are not in Fedora and do not have a review request (that are currently 
shipped from upstream jruby as binary .jars):

* jna
* joni (not surprising, jruby is upstream for joni)
* retroweaver

I packaged joni last night and submitted a review request (bug# 435598).

I also packaged asm3 and submitted a review request (bug# 435601).

retroweaver is something we don't need, so strike it off the list. GCJ claims 
to support Java 1.5.0, and Icedtea is the 1.7.0 devel branch, so something that 
provides support for 1.4.0 JVMs can easily be ommitted.

Here is the current list:
BRs in Fedora:
* jline (old version)
* junit

BRs awaiting review:
* asm3 (bug# 435601)
* emma (bug# 227052)
* jarjar (bug# 252082)
* joda-time (bug# 227073)
* joni (bug# 435598)

BRs that are not in Fedora nor awaiting review:
* jna (I hope to get this a review request soon)

Strike out asm3. Rawhide contains asm 3.1 as objectweb-asm. Removing one item
from "awaiting review" to "in Fedora" is good, though.

We also don't need emma or jarjar. We need all of (and only) the following 
still:
* jna (bug# 436036)
* joda-time (bug# 227073)
* joni (bug# 435598)
* jline 0.9.93 or higher (I've asked jline's maintainer about this)

Filed a bug report against jline (bug# 436204).

It looks like JRuby trunk now depends on antlr version 3; I think we need a new
package for that (antlr3?).

I could work on that if you're not already doing it. Looks like JPackage 
doesn't yet have an rpm for it, but one could probably work off the 
current 'antlr' spec.

Just a info:
F-9 final development freeze is due on Apr 8th.

I never planned for jruby to make F9, and think we should push it as an update 
rather than rushing it and making a poor impression on users. All the same I 
feel we're making good, speedy progress :).

I have got JRuby compiling, working, running, etc with Colin's jna, my 
joda-time and joni, and otherwise Fedora packages. The current problem I'm 
trying to address is that gems' binaries in MRI and JRuby will conflict. That 
is, if you install rails in both MRI and JRuby, /usr/bin/rails is contested 
(there may be better examples of this, but it's a definitely a problem). A 
solution might be to install jruby in /opt, which, while OK by FHS seems 
discouraged. I'd like input on this from other Fedora packagers and rubyists.

New URLs:
http://konradm.fedorapeople.org/fedora/SPECS/jruby.spec
http://konradm.fedorapeople.org/fedora/SRPMS/jruby-1.1-1.fc8.src.rpm

Note:
This version does not even attempt to separate MRI's stdlib/gems/etc and 
jruby's; instead, I included ruby as a dependency of jruby's so that jruby can 
use /usr/lib/ruby. Maybe this is the way to go. It certainly is the easiest.

The rationale given to me by the jruby folks for separating the two is that 
much of ruby's stdlib is non-threadsafe and that jruby's use of system threads 
vs MRI's use of green threads makes issues surface that otherwise didn't 
present themselves.

Antlr3 is now pending review, adding as a dependency.

I'm not actually sure jruby depends on antlr3. It builds / runs scripts just 
fine here without it.

I think Ruby 1.9 is using native threads, so presumably the MRI stdlib will need
to become threadsafe as well.

Long term, the best thing would be to have one shared stdlib; you could imagine
modules which are the same on both just being /usr/lib/ruby/foo.rb, but the
VM-specific ones be /usr/lib/jruby/foo.rb, /usr/lib/mi-ruby/foo.rb.

How about in the short term, get the JRuby people to modify their package loader
to first look in /usr/lib/jruby, and then fall back to the normal /usr/lib/ruby?

Yeah, it looks like trunk doesn't have the antlr3 dep anymore.  

I think a shared stdlib is the way to go as well. For now I am just 
using /usr/lib/ruby/ for JRuby, though you're welcome to try and patch it to 
look in /usr/lib/jruby.

In my attempt to try to do so I found that libdir, archdir, sitelibdir and 
sitearchdir as part of Config::CONFIG are defined in 
src/org/jruby/libraries/RbConfigLibrary.java, but unfortunately changing those 
did not affect the load library PATH.

As far as separation between the two in /usr/lib/ruby goes: JRuby already looks 
in /usr/lib/ruby/1.8/java as part of its default LOAD_PATH (but it's not 
anywhere near the first directory checked).

Ruby 1.9 is using native threads, but they have a giant lock that lets them get 
away with much of this (or so says the main JRuby dev -- see 
http://headius.blogspot.com/2008/04/shared-data-considered-harmful.html).

I think upstream should make the call on this; if we (Fedora) pick something on
our own it will increase the likelihood that another OS
(OpenSolaris,Debian,etc.) pick another value and things get confused as other
software vendors won't know where to install their libraries, etc.

It sounds like they want to use a separate prefix; can we install all of their
libraries into /usr/lib/jruby, and get upstream to add that to the default
search path?

They would be fine with us putting their libraries in /usr/lib/jruby and 
submitting a patch to look there first, but AFAICS they weren't going to write 
it themselves. I looked a little bit into where these changes would need to be 
made and RbConfigLibrary.java is one of those places, but there are others.

New URLs:
http://konradm.fedorapeople.org/fedora/SPECS/jruby.spec
http://konradm.fedorapeople.org/fedora/SRPMS/jruby-1.1-2.fc8.src.rpm

Just added a few missing Requires and some extra jars that needed to be in 
CLASSPATH for the /usr/bin/jruby script.

We had a quick IRC discussion about this and concluded that the current solution
of installing the libraries in /usr/lib/jruby and having the "jruby" script
installed as /usr/bin/jruby is a good compromise.

I'll take this package for the final review.

* source files match upstream:
89c41db323d6859021cdbc1747b3498c21c9739b  /tmp/jruby-src-1.1.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text in tarball but not included in package.
* latest version is being packaged.
? BuildRequires are proper (can't build in mock yet)
* %clean is present.
? package builds in mock (rawhide, x86_64).
* package installs properly
* rpmlint clean
X %check is not present, but there is a test suite upstream
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no scriptlets present.
* code, not content.
* %docs are not necessary for the proper functioning of the package.
X No comment above patches; see
http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus

Java-specific bits:
* no pre-built jars
* single jar, named after the package
* jarfiles are under _javadir.

(In reply to comment #31)
> ...
> X %check is not present, but there is a test suite upstream

I'm not sure how this is supposed to look. We'll talk about it tomorrow.

> ...
> X No comment above patches; see
> http://fedoraproject.org/wiki/PackagingDrafts/PatchUpstreamStatus

Fixed in 1.1-3 (along with the conflicting ruby/jruby prefixes). URLs:
http://konradm.fedorapeople.org/fedora/SPECS/jruby.spec
http://konradm.fedorapeople.org/fedora/SRPMS/jruby-1.1-3.fc8.src.rpm

(I am just uploading the src.rpm now, it may a few minutes as it's huge.)

Rebuild failed on dist-f9:
http://koji.fedoraproject.org/koji/taskinfo?taskID=556181

Looks like a bug with OpenJDK on PPC, I guess. I'm trying a scratch build using 
GCJ, we'll see how that goes.

I think GCJ won't build it on any platform because it fails at looking for 
classes in classpath. 
(http://koji.fedoraproject.org/koji/taskinfo?taskID=556250)

If we ExcludeArch ppc{,64} it builds fine:
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=556292

I think the %check should be as easy as:

%check
ant test-all

Once those things are fixed though, I think we're good to go on this.

The JRuby guys are working on fixing JRuby so that it runs on GCJ -- this will 
be in 1.1.1. They're aiming for a release later this week, so I'll upload a new 
Spec/SRPM then.

Ok, but AFAIK GCJ is not a must have but a "nice to have".  There is this draft:
http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ

Right, but right now it won't build *at all* on ppc{,64}. Neither 
java-1.6.0-openjdk nor gcj will build it.

OK, JRuby 1.1.1 came out earlier today and has some interesting new things to 
deal with. It adds three new build-time dependencies (all three of which were 
formerly part of JRuby proper, but have been split off as separate projects). 
I'm working on making rpms for those dependencies and getting review requests 
up for them. When I do I'll add them as blockers for this bug. Hopefully we can 
get jruby into Fedora sometime before F10.

New Spec/SRPM URLs:
http://konradm.fedorapeople.org/fedora/SPECS/jruby.spec
http://konradm.fedorapeople.org/fedora/SRPMS/jruby-1.1.1-4.fc8.src.rpm

It won't build on koji yet because of missing bytelist/jna-posix/jvyamlb. But 
those packages are available as srpms in the blocker bugs on this bug.

rm -f src/org/jruby/util/SunSignalFacade.java

This interface is just specific to OpenJDK, right?  Since most of the community
seems to be coalescing around OpenJDK I don't think we need to remove this. 
Long term having OpenJDK and GCJ share a class library through a
classpath/OpenJDK/GCJ merger would fix this too.

As for the powerpc build; I think we don't need to block getting JRuby in on
that, the process looks like you add the ExcludeArch on ppc, then file a bug
that blocks #121179.  By the way we should get this reported upstream; I believe
the author of that interpreter code in OpenJDK is gbenson.

But regardless of choices on those, I think we're good to go; marking as approved.

New Package CVS Request
=======================
Package Name: jruby
Short Description: Pure Java implementation of the Ruby interpreter
Owners: konradm
Branches: F-8 F-9 EL-5
InitialCC: 
Cvsextras Commits: yes


(In reply to comment #44)
> rm -f src/org/jruby/util/SunSignalFacade.java
> 
> This interface is just specific to OpenJDK, right?  Since most of the
> community seems to be coalescing around OpenJDK I don't think we need to 
> remove this. Long term having OpenJDK and GCJ share a class library through a
> classpath/OpenJDK/GCJ merger would fix this too.

I guess so. It builds fine with the file left in under OpenJDK here.

Thanks for the review, Colin and Mamoru!

cvs done. 

Closing.