Bug 561484 - Review Request: jruby - Pure Java implementation of the Ruby interpreter
Review Request: jruby - Pure Java implementation of the Ruby interpreter
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alexander Kurtakov
Fedora Extras Quality Assurance
:
Depends On: 560169 560170 561448 561451 561452 561455 561456 561459 561462 561466 561477 561482 646637 646641 691979 705106
Blocks: 691659
  Show dependency treegraph
 
Reported: 2010-02-03 13:33 EST by Mo Morsi
Modified: 2013-02-09 20:46 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-18 15:04:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
akurtako: fedora‑review+


Attachments (Terms of Use)

  None (edit)
Description Mo Morsi 2010-02-03 13:33:05 EST
Spec URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.4.0-1.fc12.src.rpm
Description: 
JRuby is a 100% Java implementation of the Ruby programming language.
It is Ruby for the JVM. JRuby provides a complete set of core "builtin" 
classes and syntax for the Ruby language, as well as most of the Ruby 
Standard Libraries.

Unorphaning package: http://admin.fedoraproject.org/pkgdb/packages/name/jruby

No koji build yet as jruby depends on jffi, nailgun, yydebug, yecht, jnr-x86asm, jgrapht, jaffl, jcodings, jnr-constants, bytelist, jnr-posix, and joni which are all pending Fedora approval as well.

$ rpmlint -i rpmbuild/RPMS/noarch/jruby-1.4.0-1.fc12.noarch.rpm 
jruby.noarch: W: only-non-binary-in-usr-lib
There are only non binary files in /usr/lib so they should be in /usr/share.

jruby.noarch: W: devel-file-in-non-devel-package /usr/lib/jruby/samples/ext/mytest.c
A development file (usually source code) is located in a non-devel package. If
you want to include source code in your package, be sure to create a
development package.

1 packages and 0 specfiles checked; 0 errors, 2 warnings.

Ignoring these two as they don't really apply here.



$ rpmlint -i rpmbuild/RPMS/noarch/jruby-javadoc-1.4.0-1.fc12.noarch.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint -i rpmbuild/SRPMS/jruby-1.4.0-1.fc12.src.rpm 
jruby.src:152: W: libdir-macro-in-noarch-package (main package) %{_libdir}/%{name}
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

Ignoring this last warning as when package is noarch (eg if using java-openjdk)
the libdir file will not be included, and when the package is architecture
specific (eg when using gcj) it will be. See spec file for conditionals.
Comment 1 Jason Smith 2010-09-15 16:27:13 EDT
Since you are already well aware of the issues going on over in bug #470696, I was wondering what the chances are that jruby might get picked back up for Fedora 13/14?  Currently this seems to be the best option for getting a scalable puppet system packaged into rpms for RedHat, especially since there don't seem to be the same upstream source vendor issues.
Comment 2 Mo Morsi 2010-09-15 16:46:12 EDT
Would say the chances are good. The original submission worked 100%, but since some things changed since then, will need to be updated (most significantly the JRuby 1.5 release). 

Regardless this is still on my backlog, albeit a little pushed down due to other higher priority items on my main project, deltacloud. I hope be resuming working on this and the dependencies in the near future though.
Comment 3 Mo Morsi 2010-10-25 15:51:23 EDT
Spent a few cycles updating this submission to the latest upstream release 1.5.3, and sorting the dependency situation for this updated package.

SPEC URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.5.3-1.fc13.src.rpm


This new version adds a few new dependencies:

- BZ 646637 : jnr-netdb - new dependency 
- BZ 646641 : bytelist  - updated dependency

Additionally I will be updating the jaffl (BZ 561462) submission and jffi package in Fedora to respond to feedback and to work with this new JRuby version.
Comment 4 Mo Morsi 2010-10-26 12:44:41 EDT
The jaffl Fedora submission has been updated, and Bytelist and jffi have been updated in rawhide. To test this latest update you will need those latest packages. If we want to ship jruby in F14 or F13 as well, we will need to update those packages there. We can tackle that once this is in rawhide if need be.
Comment 5 Mo Morsi 2010-12-02 11:38:49 EST
jnr-posix and jnr-netdb have been reviewed, approved, and are working their way into Fedora. Those were the last two JRuby dependencies.

Updated jruby to latest upstream release:

SPEC URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.5.5-1.fc13.src.rpm
Comment 6 Alexander Kurtakov 2010-12-05 08:16:17 EST
I'll do this one.
Comment 7 Alexander Kurtakov 2010-12-05 09:18:54 EST
Package Review
==============

Key:
- = N/A
x = Check
! = Problem
? = Not evaluated

=== REQUIRED ITEMS ===
[!]  Rpmlint output:
jruby.noarch: W: only-non-binary-in-usr-lib
You can not install in libdir in noarch package because libdir will be evaluated on the build machine. E.g. rpm build on x86 will break on x86_64. 
Please install jruby in /usr/share/jruby instead on /usr/lib/jruby.
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/gem.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/gem.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/rdoc.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/rdoc.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/spec.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/spec.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/jrubyd.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/jrubyd.bat
jruby.noarch: W: devel-file-in-non-devel-package /usr/lib/jruby/samples/ext/mytest.c
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/jirb_swing.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/jirb_swing.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/jruby.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/jruby.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/ast.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/ast.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/jgem.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/jgem.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/jirb.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/jirb.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/rake.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/rake.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/jrubyc.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/jrubyc.bat
jruby.noarch: E: script-without-shebang /usr/lib/jruby/bin/ri.bat
jruby.noarch: E: wrong-script-end-of-line-encoding /usr/lib/jruby/bin/ri.bat
Please don't install bat files.
jruby.noarch: W: no-manual-page-for-binary jirb
jruby.noarch: W: no-manual-page-for-binary jruby
If there is some please install otherwise we can skip this warnings
./SPECS/jruby.spec:146: W: libdir-macro-in-noarch-package (main package) %{_libdir}/%{name}
Described before that.

[x]  Package is named according to the Package Naming Guidelines[1].
[x]  Spec file name must match the base package name, in the format %{name}.spec.
[x]  Package meets the Packaging Guidelines[2].
[x]  Package successfully compiles and builds into binary rpms.
[!]  Buildroot definition is not present - Please remove it, it's no longer needed
[x]  Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines[3,4].
[x]  License field in the package spec file matches the actual license.
[x]  If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc.
[x]  All independent sub-packages have license of their own
[x]  Spec file is legible and written in American English.
[x]  Sources used to build the package matches the upstream source, as provided in the spec URL.
[x]  All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines[5].
[x]  Package must own all directories that it creates.
[x]  Package requires other packages for directories it uses.
[x]  Package does not contain duplicates in %files.
[x]  Permissions on files are set properly.
[!]  Package does NOT have a %clean section which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). (not needed anymore)
[x]  Package consistently uses macros (no %{buildroot} and $RPM_BUILD_ROOT mixing)
[x]  Package contains code, or permissable content.
[x]  Fully versioned dependency in subpackages, if present.
[x] Package contains a properly installed %{name}.desktop file if it is a GUI applxication.
[x]  Package does not own files or directories owned by other packages.
[x]  Javadoc documentation files are generated and included in -javadoc subpackage
[!]  Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlinks)
[x]  Packages have proper BuildRequires/Requires on jpackage-utils
[x]  Javadoc subpackages have Require: jpackage-utils
[x]  Package uses %global not %define
[-]  If package uses tarball from VCS include comment how to re-create that tarball (svn export URL, git clone URL, ...)
[x]  If source tarball includes bundled jar/class files these need to be removed prior to building
[x]  All filenames in rpm packages must be valid UTF-8.
[x]  Jar files are installed to %{_javadir}/%{name}.jar (see [6] for details)
[!]  If package contains pom.xml files install it (including depmaps) even when building with ant
[!]  pom files has correct add_to_maven_depmap call which resolves to the pom file (use "JPP." and "JPP-" correctly)


=== Other suggestions ===
[x]  If possible use upstream build method (maven/ant/javac)
[x]  Avoid having BuildRequires on exact NVR unless necessary
[x]  Package has BuildArch: noarch (if possible)
[x]  Latest version is packaged.
[x]  Reviewer should test that the package builds in mock.


=== Issues ===
1. Install in /usr/share instead of /usr/lib
2. Don't install bat files.
3. Remove buildroot
4. Remove clean section
5. Install javadoc in unversioned directory
6. Install poms and depmaps
7. Update to 1.5.6
8. There are a bunch of gem files like columnize, rake and etc. system rake, rubygem-columnize and etc. should be used
Comment 8 Mo Morsi 2010-12-06 13:51:41 EST
Thanks for the review. Updated the package

SPEC URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.5.6-1.fc13.src.rpm

Issues 1-7 have been taken care of. As far as issue #8, I don't think we will be able to do this. Even though JRuby is a standard ruby interpreter there are enough differences between it and MRI (the main / official ruby interpreter) that each gem and ruby library/application needs to explicitly support one or the other or both. I don't think we can just use the stock ruby libraries shipped for MRI with JRuby.
Comment 9 Mo Morsi 2011-01-26 11:45:48 EST
Sorry for the delay folks. I have updated the JRuby package (it is now running the test suite, required quite a few fixes) and it is just about ready to go save on somewhat major blocker. I added a comment an upstream bug (related, with a fix slated for the JRuby 1.6 release) describing the issue

http://jira.codehaus.org/browse/JRUBY-5352

Essentially right now in the yecht dependency, we only build the yecht library, not the JRuby extension for it. To build the extension we need a build time dependency on JRuby, but JRuby itself needs a runtime dependency on yecht to work properly.

Will see if I can get some upstream developers to comment on this issue and possibly a fix via the bug, email, or irc.
Comment 10 Mo Morsi 2011-03-15 12:59:31 EDT
OK upstream got back to me and I think I integrated their fix in in a way that is acceptable for Fedora.

Yecht is still a separate project / rpm, but the jruby / yecht bindings used in jruby internally have been separated into their own package. No pre-built jars are shipped, everything is built from source and shipped separately.


Updated SPEC and SRPM:
SPEC URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.5.6-2.fc13.src.rpm


I started adding the bits to get the test suite working. I was able to get it working locally end to end a little while back, but this required alot of modifications which will take more time to integrate into the rpm (alot of tests around pre-built jars which we remove for example). Until then I commented out the 'ant test' in the spec, though I did a surface functionality verification of the jruby/jirb utilities, so this shouldn't be a blocker.
Comment 11 Alexander Kurtakov 2011-03-18 10:40:10 EDT
Incidently JRuby 1.6.0 was released a few days ago. Would you be able to update to it?
Comment 12 Alexander Kurtakov 2011-04-20 08:55:41 EDT
FWIW, JRuby 1.6.1 is out
Comment 13 Alexander Kurtakov 2011-05-10 14:51:30 EDT
Ping, are we moving here?
Comment 14 Mo Morsi 2011-05-20 14:16:30 EDT
I'll get back to this (hopefully for the last time :-p) next week
Comment 15 Mo Morsi 2011-06-02 11:20:57 EDT
OK here is the latest JRuby SPEC/SRPM updated to the latest upstream release 1.6.2

SPEC URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.6.2-1.fc15.src.rpm

This is dependent on the snameyaml package which has already been submitted to Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=705106

Additionally several of the JRuby subcomponents in Fedora need updating, including
bytelist, jcodings, jaffl, jffi, jnr-posix

Fortunately I own all these components and will be updating them in F15 and in rawhide momentarily.

For the time being, to build JRuby, feel free to use these updated SPRMS:

http://mo.morsi.org/files/jruby/bytelist-1.0.8-1.fc15.src.rpm
http://mo.morsi.org/files/jruby/jaffl-0.5.9-1.fc15.src.rpm
http://mo.morsi.org/files/jruby/jcodings-1.0.5-1.fc15.src.rpm
http://mo.morsi.org/files/jruby/jffi-1.0.9-1.fc15.src.rpm
http://mo.morsi.org/files/jruby/jnr-posix-1.1.7-1.fc15.src.rpm
Comment 16 Alexander Kurtakov 2011-06-04 09:04:41 EDT
Can we get all these builds pushed to rawhide so I can test the build without doing a number of local rebuilds?
Comment 17 Mo Morsi 2011-06-06 17:31:12 EDT
OK the aforementioned JRuby dependency updates have been pushed to rawhide and successfully built.
Comment 18 Alexander Kurtakov 2011-07-06 05:41:16 EDT
=== Issues ===
1. Install in /usr/share instead of /usr/lib
Fixed.
2. Don't install bat files.
Fixed.

3. Remove buildroot
Fixed.
4. Remove clean section
Fixed.
5. Install javadoc in unversioned directory
Fixed.
6. Install poms and depmaps
Fixed.
7. Update to 1.5.6
1.6.2 - Even better :)
8. There are a bunch of gem files like columnize, rake and etc. system rake,
rubygem-columnize and etc. should be used
Fixed.

Remaining issues:
* Please install jruby into %{_datadir}/jruby instead of %{_javadir}/jruby but keep a symlink to jruby.jar into  %{_javadir}. In short  %{_javadir} is supposed to contain only jar files.
* Please do not install jruby.exe and jrubyw.exe and jruby.dll
Comment 19 Mo Morsi 2011-07-06 20:50:06 EDT
(In reply to comment #18)

> Remaining issues:
> * Please install jruby into %{_datadir}/jruby instead of %{_javadir}/jruby but
> keep a symlink to jruby.jar into  %{_javadir}. In short  %{_javadir} is
> supposed to contain only jar files.

Done.

> * Please do not install jruby.exe and jrubyw.exe and jruby.dll

Done

Updated sources:

SPEC URL: http://mo.morsi.org/files/jruby/jruby.spec
SRPM URL: http://mo.morsi.org/files/jruby/jruby-1.6.2-2.fc15.src.rpm
Comment 20 Alexander Kurtakov 2011-07-07 02:24:19 EDT
Thanks,
This package is APPROVED.
Comment 21 Vít Ondruch 2011-07-07 03:24:01 EDT
Is JRuby really ready to use system gems, such as rubygem-rake?
Comment 22 Alexander Kurtakov 2011-07-07 03:34:42 EDT
I have never checked this at runtime. But it surely uses them at build/install time. I think that this is enough for the review because there are a lot of use cases for jruby even without using system gems but it will surely rock if it can use them.
Comment 23 Vít Ondruch 2011-07-07 04:00:36 EDT
I am afraid that installing single system gem will fetch also MRI onto the system and I don't think this is desirable.
Comment 24 Mo Morsi 2011-07-15 08:39:25 EDT
Actually thinking about it, it might be possible to use the builtin gems to build jruby, and then remove them before jruby is installed, so that we are not depending on any external gems which still not shipping anything vendored.

That being said, as Alexander mentioned the gems are just a build time dependency to build jruby itself, and do not get pulled in at runtime. Thus this can move forward and we can tidy up the build process as we go along.


Thanks for the package review and approval Alexander!


New Package SCM Request
=======================
Package Name: jruby
Short Description: Pure Java implementation of the Ruby interpreter
Owners: mmorsi
Branches:
InitialCC:
Comment 25 Jon Ciesla 2011-07-15 10:14:48 EDT
Already in Fedora, will require a rel-eng trac.  Thank you!
Comment 26 Mo Morsi 2011-07-15 10:28:20 EDT
rel-eng trac ticket:  https://fedorahosted.org/rel-eng/ticket/4822

Though according to this

https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package

We still go through BZ to assign ownership of the JRuby package. Is this not correct?
Comment 27 Jon Ciesla 2011-07-15 10:42:31 EDT
Actually you may just be able to go into pkgdb and unretire now, I know there have been changes of late.
Comment 28 Mo Morsi 2011-07-15 10:51:44 EDT
Hrm I'm not seeing the option to do so via the pkgdb web interface, could you elaborate on the process I need to take to get JRuby into Fedora. Thanks.
Comment 29 Jon Ciesla 2011-07-15 11:03:54 EDT
When logged into pkgdb via my FAS account, and I'm at:

https://admin.fedoraproject.org/pkgdb/acls/name/jruby

I see Unretire Package for the devel branch, and Take Ownership for EL-5 and EL-6.  Once you have ownership, you can submit a Package Change for any additional branches you need, presumably f15 and possibly f14.
Comment 30 Mo Morsi 2011-07-15 11:36:11 EDT
I do not see an unretire button, perhaps because you have admin rights to the pkgdb?

I'm not looking to take ownership of either the EL branches, and just will be pushing JRuby into rawhide as F15 and before doesn't have the necessary dependencies.

Thanks alot.
Comment 31 Jon Ciesla 2011-07-15 11:42:59 EDT
If I do, it's news to me. :)  I am a ProvenPackager, but I doubt that's it.

Toshio, any insight?  Shouldn't Mo see Unretire?
Comment 32 Toshio Ernie Kuratomi 2011-07-15 15:55:27 EDT
Nope.  de facto policy from a long time ago is that cvsadmins control retiring and unretiring packages.  So that's why you (John) see the unretire button but Mo does not.

If you unretire the package, Mo will be able to assume ownership.
Comment 33 Jon Ciesla 2011-07-15 16:00:00 EDT
Ah.  Learn something new every day.  Unretired, go ahead and take it, import, etc, and you should be set.

Thanks Toshio!
Comment 34 Mo Morsi 2011-07-18 15:04:52 EDT
JRuby has been pushed into and built against rawhide

http://koji.fedoraproject.org/koji/buildinfo?buildID=253399

Thank you everyone for your help.

Note, the package is in but more work needs to be done on it including fixing various things and getting the test suite working again (I had it passing at one point but that was a few versions ago). 

I will do this incrementally but if anyone wants to help, perhaps we can coordinate via BZ or via the ruby-sig email list.
Comment 35 Don Hoover 2012-02-08 14:56:04 EST
Is it possible to get this in the EL6 EPEL?
Comment 36 Mo Morsi 2012-02-13 12:53:09 EST
(In reply to comment #35)
> Is it possible to get this in the EL6 EPEL?

Yes, though more work than I have time for ATM.

If you would like to go through the process yourself, feel free to start claiming the dependencies on Fedora EPEL and start importing the rawhide packages into that.

I imagine most will work just fine as is, though perhaps some may need updating due to differences in dependencies, etc

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