Moving innovations

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.

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.

Flameeyes mentions some possible eselect project for SoC. I’d like to add a project idea to that: rework eselect so that it has an interface at a higher level. Please explain to me why I have to write 195 lines of code (rails.eselect) just to manage a symlink to a binary. It seems to me that this is what most eselect modules are doing, so this case should be really easy, and just a matter of configuration. I’m sure some of the eselect modules are doing more complicated things, but that can be solved by providing hooks.

I’d rather specifiy something like this (and not make silly mistakes in the bash code like in the current eselect modules):

TITLE="Ruby on Rails"
DESCRIPTION="Some more verbose, multiline, stuff"
TARGET="/usr/bin/rails"
PROVIDERS="/usr/bin/rails-2.0* /usr/bin/rails-1.2* /usr/bin/rails-1.1*"

This is a bit of a simplistic example. I’m sure a slightly more complicated format would be needed to handle some of the common cases, including additional binaries, man pages, etc. Determining that would require taking inventory on the current eselect modules and seeing the common patterns, which makes it, uhm, a project.

If your buddies are using Mac OS you may have seen Quicksilver in action. Now there’s a recreation of the same concept for GNOME called GNOME Do. I’ve created an ebuild for Gentoo which is in my git overlay (you can get it as graaff through layman).

Note that it doesn’t yet work properly with the brand-new metacity compositor due to the (fixed) GNOME bug 504876.

For some time now there have been an emacs and xemacs overlay available through layman. Both of them pointed to the same overlay of the Emacs project. While this worked fine and also seemed easy for the Emacs project people from a maintenance perspective, we’ve now decided to split up things more clearly to avoid confusion. The emacs overlay now contains all experimental things related to GNU Emacs, and the xemacs overlay contains everything related to XEmacs.

For XEmacs users nothing changes if you were already using the xemacs overlay, but if you used the emacs overlay up to now then you will need to add or change to the xemacs overlay to continue using the latest xemacs ebuilds and eclasses, most prominently the xemacs 21.5 ebuild.

The premise of Giver is something that appeals to me: it will allow you to easily give files to others. It uses avahi to determine other Giver users out there and allows you to easily share files with them without messing with any configuration. Having this up an running would be useful for me in several situations, especially if someone would create a MacOS X port.

So I naively thought I’d just whip together an ebuild for it so that I could play around with it. That was before I knew that Giver is written in C# and uses some not-yet-released bindings for libnotify and dbus. Uhm, wait, does it depend on notify-sharp or notify-sharp. Trying them out in order I found out it’s actually the latter, but NDesk’s version depends on NDesk’s not-yet-released DBusSharp bindings.

At this point I thought that someone in Gentoo must have already worked on this, but Google was of no help in part because the now unmaintained .NET bindings in D-Bus GIT are also called dbus-sharp in many cases. If only I could easily search the overlays on overlays.g.o… But wait, that’s possible! Thanks to the people in #gentoo-dev I was pointed to eix, which can also use a remote index consisting of most of the stuff covered by layman and overlays.g.o. Just run update-eix-remote and all those overlays are at your disposal without having to install them first.

ecatmur’s overlay contains an ebuild for dbus-sharp, but it was for an older version and has some issues. To make a long story short I’ve created ebuilds for dbus-sharp, notify-sharp, and giver. They can be found in my personal GIT overlay.

Oh, and Giver? It works as advertised. You get an icon in the notification area which opens into a window showing all Giver users on the local network. Dragging a file or a folder onto a user offers the files to that user, who can then accept or decline. Simple, no fuss.

Update: Andreas Proschofsky also wrote ebuilds for giver and its dependencies during GUADEC. Since his ebuilds were a bit nicer than mine he has folded my improvements into his versions, and I recommended to use the ebuilds from his overlay for now.

Yesterday I ran into Steev’s email about the removal of virtual/x11 and checked the dev-ruby packages for any occurances. After fixing those I noticed that several people where fixing packages all over the tree and I decided to join in and have a bit of fun poking around ebuilds I’d normally never see. As a nice side effect I learned a few new things about Gentoo as well.

Although I had heard about keychain I never really looked in to this, but with the amount of commits we were doing yesterday entering my GPG passphrase quickly became tiresome. While configuring gpg-agent to deal with this keychain was pointed out to me as a way to manage both ssh-agent and gpg-agent. I finally realized the one big benefit that keychain would bring to me: no more passphrase-less keys for stuff like cron-jobs!

One of the things that we noticed as we were removing the virtual/x11 stuff is that there are plenty packages that have a lot of old ebuild versions around. Some people are of the opinion that this doesn’t hurt, but the kind of cleanup we did yesterday shows that it does hurt for such maintenance activity. I’ve fixed a number of packages where only the old versions contained references to virtual/x11. Why are these still in the tree… Sure, it makes sense to keep an older version around while stabilizing a newer version, but only for a couple of months at the most. When I asked whether we have a QA tool that might be showing which versions of a package could/should be deleted, I got pointed to earch and was disappointed to find that this basically shows the same information as packages.g.o, but without the nice layout. So, if this tool exists I’d be happy to hear about it, and otherwise I might have to try writing something myself.

This weekend I’ve committed two experimental ebuilds to the emacs overlay. I’d be happy to get feedback on them, so if you are using XEmacs and feeling adventurous, head on over to the overlay and give things a whirl.

First up is an ebuild for XEmacs 21.5.28, the latest upstream beta version. This version is not ready yet for general consumption but it does have some nice new features that may still be worth it. Personally I’m still fighting the new Xft-based font system, so for real work I’m using 21.4, but otherwise 21.5 appears to be as stable as 21.4 is. Note that 21.5 is not slotted, so it will remove 21.4 from your system. Also note that 21.5 bytecode is not fully backwards compatible with 21.4, so you’ll have to take care in downgrading. I don’t expect this ebuild to be moved to the main tree any time soon.

For those of you doing Gentoo development work with XEmacs I am happy to introduce the app-xemacs/gentoo-syntax package (formerly known as ebuild-mode, but never released for XEmacs). It should work fine with both 21.4 and 21.5, and again I’d love to get feedback on it. Many thanks to the Emacs herd for all their work on this. After I’ve gotten some feedback on this I will move it to the main tree.