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.
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.
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.
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.
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.
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
I'll do this one.
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
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.
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.
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.
Incidently JRuby 1.6.0 was released a few days ago. Would you be able to update to it?
FWIW, JRuby 1.6.1 is out
Ping, are we moving here?
I'll get back to this (hopefully for the last time :-p) next week
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
Can we get all these builds pushed to rawhide so I can test the build without doing a number of local rebuilds?
OK the aforementioned JRuby dependency updates have been pushed to rawhide and successfully built.
=== 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
(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
Thanks, This package is APPROVED.
Is JRuby really ready to use system gems, such as rubygem-rake?
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.
I am afraid that installing single system gem will fetch also MRI onto the system and I don't think this is desirable.
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:
Already in Fedora, will require a rel-eng trac. Thank you!
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?
Actually you may just be able to go into pkgdb and unretire now, I know there have been changes of late.
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.
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.
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.
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?
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.
Ah. Learn something new every day. Unretired, go ahead and take it, import, etc, and you should be set. Thanks Toshio!
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.
Is it possible to get this in the EL6 EPEL?
(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