This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 417511 - Review Request: jruby - Pure Java implementation of the Ruby interpreter
Review Request: jruby - Pure Java implementation of the Ruby interpreter
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
:
Depends On: 435598 436036 436204 436239 443734 443741 443750
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-09 16:27 EST by Conrad Meyer
Modified: 2008-05-17 14:03 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-17 14:03:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
walters: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Conrad Meyer 2007-12-09 16:27:23 EST
Spec URL: http://konrad.sobertillnoon.com/fedora/jruby.spec
SRPM URL: http://konrad.sobertillnoon.com/fedora/jruby-1.1-0.2.20071209svn.fc8.src.rpm
Description:
JRuby is an 100% pure-Java implementation of the Ruby programming
language.

Features:
  * A 1.8.5 compatible Ruby interpreter
  * Most builtin Ruby classes provided
  * Support for interacting with and defining Java classes from within
    Ruby
  * Bean Scripting Framework (BSF) support
Comment 1 Conrad Meyer 2008-01-08 21:28:49 EST
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!
Comment 2 Jason Tibbitts 2008-01-09 13:48:06 EST
I'd wager that most reviewers are going to be waiting for some Java packaging
guidelines first.  Hopefully something will happen there soon.
Comment 3 Conrad Meyer 2008-01-09 23:37:15 EST
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.
Comment 5 Mamoru TASAKA 2008-02-29 12:12:32 EST
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?
Comment 6 Conrad Meyer 2008-02-29 21:26:12 EST
(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.
Comment 7 Conrad Meyer 2008-03-01 03:44:25 EST
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 :).
Comment 8 Mamoru TASAKA 2008-03-01 04:09:38 EST
(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?
Comment 9 Conrad Meyer 2008-03-01 04:27:56 EST
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
Comment 10 Conrad Meyer 2008-03-02 06:44:45 EST
I packaged joni last night and submitted a review request (bug# 435598).
Comment 11 Conrad Meyer 2008-03-02 07:42:34 EST
I also packaged asm3 and submitted a review request (bug# 435601).
Comment 12 Conrad Meyer 2008-03-02 07:51:29 EST
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)
Comment 13 Conrad Meyer 2008-03-03 10:32:40 EST
Strike out asm3. Rawhide contains asm 3.1 as objectweb-asm. Removing one item
from "awaiting review" to "in Fedora" is good, though.
Comment 14 Conrad Meyer 2008-03-05 01:59:50 EST
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)
Comment 15 Conrad Meyer 2008-03-05 16:25:17 EST
Filed a bug report against jline (bug# 436204).
Comment 16 Colin Walters 2008-03-31 15:23:15 EDT
It looks like JRuby trunk now depends on antlr version 3; I think we need a new
package for that (antlr3?).
Comment 17 Conrad Meyer 2008-04-02 00:29:53 EDT
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.
Comment 18 Mamoru TASAKA 2008-04-05 09:43:15 EDT
Just a info:
F-9 final development freeze is due on Apr 8th.
Comment 19 Conrad Meyer 2008-04-05 16:19:31 EDT
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 :).
Comment 20 Conrad Meyer 2008-04-06 01:06:20 EDT
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.
Comment 21 Conrad Meyer 2008-04-06 02:02:52 EDT
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.
Comment 22 Colin Walters 2008-04-06 14:55:33 EDT
Antlr3 is now pending review, adding as a dependency.
Comment 23 Conrad Meyer 2008-04-06 15:00:14 EDT
I'm not actually sure jruby depends on antlr3. It builds / runs scripts just 
fine here without it.
Comment 24 Colin Walters 2008-04-06 15:10:26 EDT
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?
Comment 25 Colin Walters 2008-04-06 15:22:58 EDT
Yeah, it looks like trunk doesn't have the antlr3 dep anymore.  
Comment 26 Conrad Meyer 2008-04-06 15:36:04 EDT
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).
Comment 27 Colin Walters 2008-04-06 16:27:29 EDT
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?

Comment 28 Conrad Meyer 2008-04-06 16:37:29 EDT
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.
Comment 29 Conrad Meyer 2008-04-06 20:54:32 EDT
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.
Comment 30 Colin Walters 2008-04-07 20:34:58 EDT
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.
Comment 31 Colin Walters 2008-04-07 22:38:20 EDT
* 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.

Comment 32 Conrad Meyer 2008-04-08 00:31:51 EDT
(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.)
Comment 33 Mamoru TASAKA 2008-04-08 02:16:33 EDT
Rebuild failed on dist-f9:
http://koji.fedoraproject.org/koji/taskinfo?taskID=556181
Comment 34 Conrad Meyer 2008-04-08 02:57:30 EDT
Looks like a bug with OpenJDK on PPC, I guess. I'm trying a scratch build using 
GCJ, we'll see how that goes.
Comment 35 Conrad Meyer 2008-04-08 03:35:02 EDT
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)
Comment 36 Conrad Meyer 2008-04-08 04:32:24 EDT
If we ExcludeArch ppc{,64} it builds fine:
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=556292
Comment 37 Colin Walters 2008-04-08 08:57:56 EDT
I think the %check should be as easy as:

%check
ant test-all
Comment 38 Colin Walters 2008-04-10 18:32:26 EDT
Once those things are fixed though, I think we're good to go on this.
Comment 39 Conrad Meyer 2008-04-10 18:39:52 EDT
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.
Comment 40 Colin Walters 2008-04-11 14:21:29 EDT
Ok, but AFAIK GCJ is not a must have but a "nice to have".  There is this draft:
http://fedoraproject.org/wiki/PackagingDrafts/ConditionalGCJ
Comment 41 Conrad Meyer 2008-04-11 18:11:33 EDT
Right, but right now it won't build *at all* on ppc{,64}. Neither 
java-1.6.0-openjdk nor gcj will build it.
Comment 42 Conrad Meyer 2008-04-22 22:01:13 EDT
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.
Comment 43 Conrad Meyer 2008-04-23 21:10:58 EDT
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.
Comment 44 Colin Walters 2008-04-24 17:37:47 EDT
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@redhat.com.

But regardless of choices on those, I think we're good to go; marking as approved.
Comment 45 Conrad Meyer 2008-04-24 18:25:12 EDT
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!
Comment 46 Kevin Fenzi 2008-04-24 21:54:25 EDT
cvs done. 
Comment 47 Mamoru TASAKA 2008-05-17 14:03:04 EDT
Closing.

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