Moving innovations

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.

The last few weeks have seen a lot of developments for GNU Emacs on Gentoo and luckily XEmacs is also reaping some of the benefits. Emacs and XEmacs now both depend on a new eselect module which finally resolves some file collision bugs between Emacs and XEmacs. The eselect module currently doesn’t support XEmacs very well but this is something that will only be noticed by someone installing both GNU Emacs and XEmacs.

In addition to these changes there is now also a joint project for GNU Emacs and XEmacs as a sub-project from the Lisp project. Hopefully this will make things a bit easier to organize and further the cooperation between the GNU Emacs and XEmacs herds. Since this project space is now available I’ve also moved the XEmacs on Gentoo information page there from my dev space. Hopefully I’ll be able to implement some of the Future Plans mentioned there shortly.

With all of the XEmacs packages up-to-date again in Gentoo CVS, I found less and less need to keep my original SVN overlay online. It used to located at moving-innovations.com/svn/xemacs, but no more. I took it offline today after cleaning out the remainder of the overlay and discovering that there wasn’t anything of interest there anymore. So, if you’ve been using it:it’s gone. Everything that was there is now in Gentoo CVS, except for the patches to move all XEmacs support and lisp files from /usr/lib to /usr/share. I hope to revisit that move some time in the future.

The only other thing that I planned for the repository is to create an ebuild for the XEmacs 21.5.x beta versions. However, that alone really doesn’t warrant an overlay, so I guess we’ll just package.mask that until it is fully ready.

Finally, this may be the right time to point to some documentation on XEmacs on Gentoo. It’s still a work-in-progress, but I hope to document both the development process and tools, and peculiarities relevant to XEmacs users on Gentoo. Please let me know if you have questions or would like to see something particular documented.

Finally I’ve pushed almost all pending patches and fixes for XEmacs into portage. XEmacs 21.4.20-r1 fixes a recently uncovered crash when playing wavs using linux native audio on 64-bit systems by trying to cast an int into a size_t. Even though this stops xemacs from crashing after trying to play a sound, something still isn’t quite right as the sounds sound very funny. Therefore I have also added the esd USE flag so that esound can be used to play the sounds.

In addition to these XEmacs changes a whole set of packages have also been released. Most of these have been in pre-release for several months, so it’s good to see them finally released. All of these have been added as well. Most of the packages only have minor bug fixes, except for app-xemacs/calendar which got a lot of new functionality added.