Hide Forgot
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
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.