tl;dr jruby in Gentoo will have to go unless we get volunteers to help us with the jruby 1.7 series.
jruby has been available in Gentoo since 2004 and is currently at version 1.6.8. People following jruby will realize that this is a problem: the latest upstream version is 1.7.12 as of this writing. The 1.6 series is also based on ruby 1.8.7 by default. This is a problem since we have removed ruby 1.8 from the tree altogether, and support for it in ruby packages is disappearing fast. jruby 1.6 has a 1.9 mode, but that is based on ruby 1.9.2 where most packages expect at least 1.9.3. We are currently experimenting with defaulting to 1.9.2 mode to extend the 1.6 series. In short, more and more packages that currently have jruby target will loose it on updates since it simply is no longer compatible with jruby 1.7 and in its current state jruby in Gentoo is ready for a slow and agonizing descent. Or we could just be quick about it and mask it soon.
Why not just update to jruby 1.7, you might wonder? We have bug 442230 to track this update, but unfortunately it turns out that it is not easy to add the 1.7 series of jruby to Gentoo. The biggest stumbling block here is that the 1.7 build system is based on Maven. Using Maven is not well supported in Gentoo, mostly because Maven requires the ability to download code during its build phase and does not play very nice with Gentoo's package structure in general. It may be possible to fix this, but that requires good knowledge of Java and Ruby on Gentoo. Currently we don't have any developers capable of both, and passing the code back and forth isn't very practical and proves to go very slow in practice.
So we are looking for a volunteer who wants to pick up this project, and help us bring the jruby 1.7 series to Gentoo. If you see this as a step to become a Gentoo developer than that's great and we can mentor you. If you see this as an interesting one-off project to help out with, that's great too. Once 1.7 is in the tree it should not be a big deal to keep up with new versions. Feel free to drop by in #gentoo-ruby to discuss this with us if you are interested. Our ruby overlay holds the current work-in-progress on jruby 1.7.
If no-one volunteers, unless a magical break-through suddenly appears, we will most likely be forced to mask jruby and remove it from the tree. Help us to not do that!
I've just updated the text on the Gentoo Wiki page on Ruby 1.9 to indicate that we now support eselecting ruby19 as the default ruby interpreter. This has not been tested extensively, so there may still be some problems with it. Please open bugs if you run into problems.
Most packages are now ready for ruby 1.9. If your favorite packages are not ready yet, please file a bug as well. We expect to make ruby 1.9 the default ruby interpreter in a few months time at the most. Your bug reports can help speed that up.
On a related note, we will be masking Ruby Enterprise Edition (ree18) shortly. With Ruby 1.9 now stable and well-supported we no longer see the need to also provide Ruby Enterprise Edition. This is also upstream's advice. On top of this the last few releases of ree18 never worked properly on Gentoo due to threading issues, and these are currenty already hard-masked.
Since we realize people may depend on ree18 and migration to ruby19 may not be straightforward, we intend to move slowly here. Expect a package mask within a month or so, and instead of the customary month we probably won't remove ree18 until after three months or so. That should give everyone plenty of time to migrate.
Based on questions recieved so far I have added a page to the Gentoo wiki with more details on the ruby 1.9 migration. Let me know if you have more questions or feel things are still unclear, and I can elaborate the article further.
Contrary to my earlier post about ruby 1.9 going stable, we've decided to add ruby19 to the default RUBY_TARGETS now, rather than wait a few weeks. The main reason for this is that some packages correctly depend on dev-lang/ruby, and thus pull in ruby 1.9 now that it is stable, but they also pull in supporting packages that need to be installed for ruby 1.9. Without the ruby19 target portage will complain that it lacks the
ruby_targets_ruby19 USE flag for these packages and it suggests to add them to package.use.
Technically this is correct, since RUBY_TARGETS=ruby19 will be expanded automatically to the ruby_targets_ruby19 USE flag, but it is not a very practical or user-friendly solution. This is why we have decided to add ruby19 to RUBY_TARGETS now, so that things will work out of the box. The ¨downside¨ of this is that more people will get ruby 1.9 pulled in now, and that packages will be installed by default for both ruby 1.8 and ruby 1.9. This was our intention anyway, since it will make switching to ruby 1.9 as the default ruby implementation easier down the line.
Our recommended setup is to not specify anything yourself, so if you already added the USE flags or modified RUBY_TARGETS yourself, we recommend that you remove these again since the default should now work correctly again. By using the defaults you'll make it easier to keep things working out of the box in the future. Obviously, if you care in some way, you can make all these changes!
Our Ruby project page has also been updated to reflect the current status of the different ruby implementations in Gentoo.
I've just added arches to bug 411507, asking for stabilization of ruby 1.9.3p125 and its associated packages. This has been a long time coming but it looks like all the pieces are now in place for this.
Note that this currently only makes a difference for packages that request dev-lang/ruby directly. We don't have many of those, and most should already have been checked for ruby 1.9 compatibility. All other packages use the RUBY_TARGETS mechanism, so unless you have modified this yourself you won't get ruby 1.9 packages for now. If you want to install packages for ruby 1.9 then you can add ruby19 to the RUBY_TARGETS variable in /etc/make.conf.
For now the default for this variable is still "ruby18". We will add ruby19 in a couple of weeks when ruby 1.9 is actually stable and when possible issues have been fixed. Once ruby18 is no longer supported upstream we will also switch our default ruby implementation to ruby 1.9 but currently we don't have a set date for that.
Today I finally closed bug 203706, 4 years after it was initially opened. That means that you can now go and install ruby 1.9.3 without having to unmask the packages and associated use flag. It also means that we'll try to add the ruby19 flag, when possible, to new ebuilds as we add them. With ruby 1.8 no longer in maintenance starting June 2012 we can now work towards making ruby 1.9 the primary stable ruby implementation. At this point in time, though, we don't officially support running your whole system on ruby 1.9 yet.
Unless you take action yourself nothing will change for the moment. If you want to start installing your ruby packages also for ruby 1.9, then you must add
ruby19 to your
Note that this will only work in the testing tree for the moment. If you find bugs, please report them or drop by in
After a hiatus of more than 2 years Rubinius is back with Gentoo. Rubinius 1.2.4 got added this weeked as dev-lang/rubinius, making it the 5th ruby provider natively supported in Gentoo. If you want to install your ruby packages (also) for Rubinius you should add "rbx" to RUBY_TARGETS in /etc/make.conf. That will ensure that all packages that have been marked as ready for rubinius will be installed for it.
Right now that list is quite small still, but this should improve over time. If you would like to see a package marked for Rubinius (or another missing ruby implementation), then please open a bug for it. Please add the output of a successful build with both FEATURES=test and USE=doc to verify that everything works as expected.
Thanks to the people participating in bug 334177 for testing, initial ebuilds, and support.
Yesterday I updated the eclass for XEmacs to support site file based initialization similar to what Emacs on Gentoo offers. When I say similar, I mean identical. A rip-off. Stolen. But without the legacy support. Many thanks to the Emacs team for painfully constructing and debugging a good approach to this problem.
With this support in place XEmacs code that isn't provided as an XEmacs package can now register itself so that you don't need any additional configuration to make use of the package. A simple example is for modes to register themselves automatically for the associated file extensions. The Emacs Gentoo project page has a more verbose explanation. It also includes the mechanism to start using this. Add it to your .xemacs/init.el (after you've installed a package that uses this).
So, which packages already use this? Unfortunately the answer currently is none, but patches are pending for app-admin/puppet. Please feel free to file bugs if you would like to see support for this added to other packages.
Like many other people I've also created a new PGP key. My old key was, well, old, and based on a 1024 bit DSA key, which is no longer considered secure. My new key also contains my name as it appears on my passport, which should make keysigning parties go a bit smoother.
My old key, 0xFB0878BB, will remain valid for some time, but I'll sign my emails and Gentoo commits with my new key, 0xEFDBB3EC. I've signed my new key with my old key, so if you could verify my old key you should be able to verify my new key, although it will take one further step in the web of trust. I expect to be at the keysigning party at FOSDEM so that will integrate the new key more firmly.
Bug 23949 has been around for a long time, but it can finally be closed soon. I will be sending a last rites email for app-xemacs/xemacs-packages-sumo shortly, and after that the package will be moved into package.mask. If you want to easily install all xemacs packages with a single command, just use app-xemacs/xemacs-packages-all instead. You will get the same thing as is currently shipped in the sumo packages, but without all the file collisions that may occur.
I have also updated the XEmacs project documentation to reflect this change.