Moving innovations

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.

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.

After maintaining my XEmacs overlay for a few months I've decided to take the next step and put in my application to become the official maintainer of XEmacs for Gentoo. I've sent a mail to the recruiting team, we'll see how things develop from there.

XEmacs support in Gentoo is currently less than stellar due to lack of a maintainer. Looking at some of the ebuilds this situations has been going on for some time. Some of the XEmacs lisp packages have not been updated since 2003 and there are a bunch of bugs open for XEmacs-related issues.

I’m not sure I would like to become a maintainer for XEmacs in Gentoo. The process of becoming a Gentoo developer seems a bit convoluted and unclear, and I am also not sure that I can bring the commitment to do this for some time. But having a need for some of the updated packages and hating to see my efforts only being useful for myself I set up an overlay for updated XEmacs stuff. It can be accessed at
http://moving-innovations.com/svn/xemacs. So far I have only added the packages that I have installed myself. Maybe, if things work out well, I’ll also include other packages and an updated xemacs itself. Let me know if you think this is useful or if you have specific requests.