Moving innovations

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 RUBY_TARGETS in /etc/make.conf.

  RUBY_TARGETS="ruby18 ruby19"

Note that this will only work in the testing tree for the moment. If you find bugs, please report them or drop by in #gentoo-ruby.

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.

I really needed an excuse to try out my new backpack. Actually I have the AC Lite 15 but that is no longer present on the site and I guess that explains the discount I got on it. It’s not that I’m not happy with my other backpack, but I found the Osprey a bit too big for simple daytrips. Hiking along the Oosterschelde yesterday confirmed to me that it’s also very nice to have a small backpack. I still expect to use the Osprey on multi-day hikes which I’m planning for spring and summer, but for single-day trips I think the Deuter will win out.

Yesterday’s route took me along the Grenslandpad from Biezelinge to Krabbendijke in Zeeland. Since I left a bit in a hurry to catch the once-an-hour train in Krabbendijke I took the wrong guidebook with me so I was left to navigate only based on the markings. Not a big deal normally, but here the markings where either faded by the salt water to the point that you could hardly see them, or they were put in such awkward places that it was unclear what way to go. With some educated guessing I did find most of the route, but in the end things were a bit unclear again and I just used the GPS to find back my car. The weather was great, with a strong wind blowing in the general direction I was walking in and splendid sunshine all afternoon.