No ebuild exists for Rubinius in either the main repo or in sunrise repo. Reproducible: Always Steps to Reproduce: Look in /usr/portage or /usr/local/portage/sunrise for "rubinius" - nothing found I'm specifically adding this bug because I'm trying to follow the steps listed in http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit I already have an ebuild written for Rubinius that I'd like some advice on how to improve the style on. Likewise, I'd love to see Rubinius get first-class VM treatment in Gentoo - ruby-eselect etc.
Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Thanks, On behalf of the Gentoo Sunrise Team, [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
This soon be in the sunrise overlay. You will be able find it at: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/dev-lang/rubinius
I've played a bit more with the ebuild and found some more things that need fixing. The build system tries to install things via sudo. It shouldn't do that. There are several bundled libraries. At least libffi, libtommath and udis86 are already part of Gentoo and should be used instead of the bundled versions. Longer term we should also unbundle libgdtoa and onig. It also looks like the internal copy of llvm is being compiled regardless of the ebuild settings. In these cases my preference is always to remove the bundled code in src_prepare to make it clear we really don't want that. :-) The specs with bin/mspec seem to fail right away :-(
I can look into unbundling the other libraries - is it reasonable to do that in src_prepare? I suspect upstream will be resistant to modifying their build process "for gentoo" Re: mspec - boy, do I know. I'm working with upstream to reproduce the issues so they can be corrected.
(In reply to comment #4) > I can look into unbundling the other libraries - is it reasonable to do that in > src_prepare? I suspect upstream will be resistant to modifying their build > process "for gentoo" Normally an upstream provides a configuration option to select between the OS version and the bundled one, that would be nice here. Potential problems here are that upstream bundles older versions or perhaps even patched versions. While it's important to fix this in the long run I don't think this should be the main focus now, unless upstream is already willing to help support it. > Re: mspec - boy, do I know. I'm working with upstream to reproduce the issues > so they can be corrected. Ok, sounds good.
Judson, any progress on this? Anything we can help with?
Upstream was able to fix the mspec build fails based on a Gentoo VM. I confirmed at the time that their HEAD build worked for me, and they've since released a new sub-version. I need to bump the ebuild and see if it builds, at which point I'd appreciate your renewed criticism. When I get to that: how would you like me to show you the ebuild?
This bug would be fine, but it might be easier to set you up with access to our ruby-overlay, or you could provide it in your own overlay.
Feel free to contact me directly about working with the ruby overlay
What's the specific reason in not putting this into the main repository instead? We have other ruby VMs as well, so why not rubinius?
(In reply to comment #10) > What's the specific reason in not putting this into the main repository > instead? Adding a new ruby implementation is a bit involved, all the pieces have to fit including supporting code like rubygems, etc. Furthermore, when I last got an update the rubinius ebuild was still work-in-progress. So the idea is to prepare and test everything in the overlay and move to the main repository when ready.
(In reply to comment #11) > Adding a new ruby implementation is a bit involved, all the pieces have to fit > including supporting code like rubygems, etc. Furthermore, when I last got an > update the rubinius ebuild was still work-in-progress. So the idea is to > prepare and test everything in the overlay and move to the main repository when > ready. Nice, but isn't there a reason we have hard masked and ~unstable masked packages for? Nevertheless, I might help testing rbx, especially since I've to walk with ruby quite alot recently :)
dev-lang/rubinius-1.2.4.20110705 is now in the tree, you can use it by adding "rbx" to your RUBY_TARGETS. @Judson: thanks for all the initial work on this!
