Tag: RubyNG

Gentoo’s fake gems and RSpec

It was last month that I ranted about the lack of verbosity in Ruby ebuilds. While I haven’t had chance to work on the documentation building side of the fence just yet (simply because I really don’t know how documentation is usually built for Ruby packages) we have the RSpec 2-baed “recipe” implemented, which makes it dead easy to run tests with it from a fakegem ebuild.

Unfortunately, this does not apply to Test::Unit, either version 1 or 2, or MiniTest. For Test::Unit 2, I added a helper to ruby-ng.eclass that still makes it easier to deal with those tests, but it’s not possible to automate it as it requires quite a bit of work to be usable, as most of the software out there is not really tested with that framework but rather with standard Test::Unit or MiniTest. But you can’t have everything, can you?

On the other hand, today I’ve started porting packages using RSpec 1.x (dependency on dev-ruby/rspec:0) to RSpec 2 — for most, but not all, of them it’s straightforward. Features like shared example groups changed syntax, and require more hands-on porting, but for the most part I’ve seen them working just fine by calling rspec instead of spec and eventually removing the requirement of the old spec library. I’ll write a page in the Gentoo Wiki about porting to the new RSpec later on today.

What does this bring us? Well, first of all, during testing we no longer have to go through Rake, and eventual helper libraries such as Jeweler, Hoe, Echoe, Bones, etc. This saves us dependencies, which does not only mean that we have fewer packages to install, but also that we have fewer packages whose behaviour can modify the results of the tests. This is a huge difference.

Furthermore, both the RSpec and the Test::Unit 2 helpers respect TEST_VERBOSE and NOCOLOR which means that they don’t cause extra processing on my script on the Tinderbox (which has NOCOLOR set) and I have verbose output to see where Ruby is aborting when it is (it still seems to be random to me, but the memory is OK, memtested and everything).

So anyway, if you happen to rely on some gem and want to see it packaged in Gentoo… please consider making sure it uses RSpec 2 for testing!

On test verbosity (A Ruby Rant, but not only)

Testing of Ruby packages is nowadays mostly a recurring joke to the point I didn’t feel I could add much more to my last post — but there is something I can write about, which is not limited to Ruby at all!

Let’s take a step back and see what’s going on. In Ruby you have multiple test harnesses available, although the most commonly used are Test::Unit (which was part of Ruby 1.8 and is available as a gem in 1.9) and RSpec (version 1 before, version 2 now). The two of them have two very different defaults for test output: the former uses, by default, a quiet “progress” style output (one dot per test passed), the latter uses a verbose “documentation” style. But both of them can use the other style as well.

Now, we used to just run tests through rake, using the Rakefile coming with the gem, or the tarball, or the git snapshot, to run tests and build documentation, since both harnesses have very tight integrations with it — but since the introduction of Bundler, this starts to get more troublesome than just writing the test commands out in the ebuild explicitly.

Today I went to bump a package (origin, required for the new Mongoid), and since I didn’t wire in the tests last time (I was waiting for a last minute fix), I decided to do so this time. It should be of note that while, when using rake to run the tests, you’re almost entirely left to the upstream’s preference on what style to use for the tests, it’s tremendously easy to override that in the ebuild itself.

The obvious question is then “which of the two styles should ebuild use for packaged gems?” — The answer is a bit complex, which is why this post came up. Please also note that this does not only apply to Ruby packages, it should be considered for all packages where the tests can be silent or verbose.

On a default usage, you only care about whether the tests fail or pass — if they fail, they’ll give you as much detail as you need, most of the times at least, so the quiet (progress) style is a very good choice: it’s less output, which means smaller logs, less context, and it’s a win-win. For the tinderbox, though, I found out that having more verbose output is useful: to make sure that other tests are not being skipped, to make sure that the build does not get stuck, and if it does, where it got stuck.

Reconciling these two requirements is actually easier than one might think at first because it’s an already solved problem: both perl.eclass and, lately, cmake-utils.eclass support one variable, TEST_VERBOSE which can be set to make the tests output more details while running. So right now origin is the first Ruby ebuild supporting that variable, but talking about this with Hans we came to the conclusion we need a wrapper to take care of that.

So what I’m working on right now is a few changes to the Ruby eclasses so that we support TEST_VERBOSE and NOCOLOR (while the new analysis actually strips out most of the escape codes it’s easier if it doesn’t have to do that!) with something such as ruby-ng-rspec call (which can also check whether rspec is properly in the dependencies!). Furthermore I plan on changing ruby-fakegem.eclass so that it also allows to switch between the current default test function (which uses rake), one that uses RSpec (adding the dependency!), and one that uses Test::Unit. Possibly, after this, we might want to do the same thing with the API documentation building, although that might be trickier — in general though having the same style of API docs installed, instead of using each project’s own, might be a good idea.

So if your package runs tests, please try supporting TEST_VERBOSE, and if it can optionally use colors, make sure it supports NOCOLOR as well, thanks!

Ruby pains, May 2012 edition

While I’m still trying to figure out how to get the logs analysed for the tinderbox, I’ve been spending some time to work on Gentoo’s Ruby packaging again, which is something that happens from time to time as you know.

In this case the spark is the fact that I want to make sure that my systems work with Ruby 1.9. Mostly, this is because the blog engine I’m using (Typo) is no longer supported on Ruby 1.8, and while I did spend some time to get it to work, I’m not interested in keeping it that way forever.

I started by converting my box database so that it would run on Ruby 1.9. This was also particularly important because Mongoid 3 is also not going to support Ruby 1.8. This was helped by the fact that finally bson-1.6 and mongo-1.6 are working correctly with Ruby 1.9 (the previous minor, 1.5, was failing tests). Next step of course will be to get them working on JRuby.

Unfortunately, while now my application is working fine with Ruby 1.9, Typo is still a no-go… reason? It still relies on Rails 3.0, which is not supported on 1.9 in Gentoo, mostly due to its dependencies. For instance it still wants i18n-0.5, which doesn’t work on 1.9, and it tries to get ruby-debug in (which is handled in different gems altogether for Ruby 1.9, don’t ask). The end result is that I’ve still not migrated my blog to the server running 1.9, and I’m not sure when and if that will happen, at this point.. but things seem to fall into place, at least a bit.

Hopefully, before end of the summer, Ruby 1.9 will be the default Ruby interpreter for Gentoo, and next year we’ll probably move off Ruby 1.8 altogether. At some later point, I’d also like to try using JRuby for Rails, since that seems to have its own advantages — my only main problem is that I have to use JDBC to reach PostgreSQL, as the pg gem does not work (and that’s upsetting as that is what my symbol collision analysis script is using).

So, these are my Ruby 1.9 pains for now, I hope to have better news in a while.

Working outside the bubble

One of the most common mistakes a developer can make is never look or work outside their usual environment. By never looking outside their own little sandbox, they risk losing sight of which improvements happen outside of their world, which they could easily factor in. This is why I always look at what Fedora, Debian and Ubuntu do, for instance.

Given my involvement with Ruby packaging, one of the things I should try to avoid covering myself with is Ruby itself; unfortunately trying to look at Python packaging is not something I’d be keen on doing anytime soon, given the state of python.eclass (please guys, rewrite it, sooner rather than later!). But at least tonight I spent some time looking at Perl modules’ ebuilds.

The main reason why I went to look for those is because an user (Grant) asked me to add Google’s AdWords library for Perl to the main tree, but Perl is something I wanted to look at for a while, since I wanted to set up RT for my customers and the new versions require a few more dependencies.

At any rate, looking at Perl ebuilds for me is not too unnatural: while the fact that there is a single Perl implementation makes it much easier on them to implement the phases, the rest of the set up is not too different from what we have in Ruby land.

What seems to be more common there is that they also set HOMEPAGE by default if none is set, since it seems like a lot of modules only have an homepage as part of CPAN, which is only different in the Ruby world due to the fact that most of the projects are managed on GitHub, which makes that their default homepage.

Having finally to take a good look at the g-cpan tool, I have to say that I think that all the trials for a g-gem tool or similar are quite out of target: instead of creating a tool that creates and install ebuilds for the pre-packaged extensions, we should have coordinated with RubyGems upstream to provide a few more details — such as a way to explicit the license the extension is released under, which CPAN does and RubyGems doesn’t, you can also see Mandriva struggling with the same issue in the final questions on my FOSDEM talk — and at that point we could have just created a tool that prepared a skeleton for our own ebuilds, rather than something fully automated like it has been tried before.

Anyway, I really like the idea of trying to package something you’re not usually used to, makes it easy to find what is different and what is similar, in approaches.

Gems using hydra development model

As I said on twitter I think I have a part of me that’s pretty much a masochist, as I’ve had the nice idea of trying out MongoDB for a personal experiment (a webapp to manage clients’ hardware configuration registration, stuff for my usual “day job”), so I started looking into packaging Ruby (and Rails) support for it.

Luckily Rails 3 started abstracting the ORM as well, allowing an almost drop-in replacement of ActiveRecord with a MongoDB adapter instead.. there is a nice guide that actually tells you almost all that is needed in the basic case (of course it could be more automated, but that’s beside the point here). The core of that guide is the mongo_mapper gem which then depends on a thin layer that is further built on top of the driver depending in turn on bson that provides a pure Ruby interface as well as a JRuby version… there is a separate gem for the C-based extension … if your head is spinning or are wondering if I became a linkspammer, I can’t blame you.

The end result is that at the very least I got to package

  • bson
  • mongo
  • plucky
  • mongo_mapper

Not too shabby, but I got in way worse situations before, such as the dependency web of Bones and its extensions. What I didn’t expect was the way these packages are developed rather than packaged.

The gems, as usual, are shallow, and contain no tests, Rakefile, or any other useful files that we need to package them properly as ebuilds. So I had to rely on the GitHub repositories, thankfully we do that mostly transparently in Ruby eclasses (as it’s way too common for us to have to rely on snapshots); unfortunately while for plucky and mongo_mapper the situation was clear (the homepage of the gems points to GitHub, and the two have separate repositories), the situation gets complex for the mongo driver and related gems.

First, let’s ignore the issue with bson and bson_ext (the C-based extension)… that is stuff we would generally can deal with in Gentoo itself (the C extension will be built for all the targets supporting it; JRuby will get its own extension, and all in the same package). The problem is that, after digging through the MongoDB website – finding the list of repositories is definitely not easy – the repository for both mongo and bson (and bson_ext!) is the same … and not in the way that Rails 2.3 was all in the same repositories (with each gem having its own subdirectory), but merging the content of the three gems in the same structure. Saying that it’s messy is not enough.

It is no doubt to me that I’ll handle that just fine at some point in the future, but it really makes me wonder how is it possible for them to consider this a good design and development practice. It’s a mystery. For now I don’t think I’ll spend much more time on this issue as I have other tasks for my job to take care of, which moves this to the back-burner…

And on that topic I’d like to try again an experiment to gauge the interest on packaging these gems; my blog is Flattr] enabled – even though lately AdSense on this and Autotools Mythbuster is getting me more money than Flattr – and this post is as well. If you’ve got an account (or feel like opening one), and you’re interested in seeing ebuilds for the Mongo Ruby driver in Gentoo, give a flattr to this post. If I see that count increasing in the next two days I’ll use the Christmas weekend to work on it.

A worldly opponent

Yes I’m writing again about Ruby after a very long hiatus… it feels like there’s a pattern behind this it seems.

After my recent changes, Hans approached me today with two issues: the first is that I should stop adding virtual/ruby-test-unit dependencies on ebuilds since (finally!) Ruby 1.9 gained a completely compatible test-unit implementation, which means you can rely on packages to behave correctly without adding extra dependencies, and old, stale, and darcs-mantained gems to keep around — hopefully, at least. The other issue is more troublesome, and relates to bug #380409 where users are being forced to get Ruby Enterprise installed in their system.

Why would this happen? Well, as you can see in that bug, once the version of ruby-rdoc that references Ruby Enterprise (this applies to the other virtuals as well, though) was marked stable, Portage wanted to update it, causing the new implementation to be requested by the dependency tree. You can easily guess that we didn’t have in mind this behaviour when we decided to go with the virtuals. So what’s going on?

When a package, such as redmine (which I fixed yesterday to do this) requires the virtual/ruby-ssl ebuild (which relates to a Ruby implementation that includes the ssl extension, an USE flag for the C-based implementations, but a separate package for JRuby), the expanded dependencies appear like this: ruby_targets_ruby18? ( virtual/ruby-ssl[ruby_targets_ruby18] ) … since each one of those virtuals lives in a different slot, and only supports one target, you get requested one ebuild for each target you requested … and the target definition on those is forced on.

Since the dependencies resolve to a straight slot, Portage wouldn’t try to “update” the virtual to get the highest-version one .. which would then bring in a different Ruby implementation altogether. So why is bug #380409 there? As Hans points out the problem has to be that the virtuals are added to the world set: being in the world set (unbound from a slot) means that Portage will try to get the highest-version of the package installed, no matter which slot it belongs to. Incidentally, this is also why you got Python 3 installed on every system even though you didn’t ask for it, unless you mask it explicitly.

Handling of world set’s content is fishy at its best; when you install a package with a straight emerge command, you’re “selecting” the package, and that adds it to the world set; if you want to avoid that, you have to do so with emerge -1 .. and most people forget about that. This is probably why the bug entered on users’ systems.

So how do you clean up the situation so that it behaves as expected instead? Well, it’s actually easier than you’d expect:

qlist -IC virtual/ruby | xargs emerge --deselect

This removes the packages from the world file, but keeps them installed, so that you won’t be asked to merge them again later. And it handles all the Ruby virtuals at once, so even if in your case the problem was with rubygems, this will fix it.

Gentoo Ruby: less is more

Yesterday, after a mostly unrelated bug report, Alex and me noticed that Ruby 1.9.2_rc2 was still bundling a few gems. Bundling, as I have written too many times to link properly, is a bad habit, but an unfortunately common one in the Ruby landscape; luckily the use of more modern methods, such as bundler, can make it more manageable (bundler will reuse the installed copies, and is designed not to let the gems be versioned with the rest of the code in the same repository; but this is getting off topic so let’s stop here).

The problem with the Ruby interpreter bundling code is mostly tied to two problems: with a few exceptions, the bundled libraries are still developed standalone, causing some extension to require a standalone copy of the libraries (because they added functions or fixed bugs); when that happens, we also risk that the code does not mix too well. Funnily enough, Ruby 1.9 stopped bundling Test::Unit, and now that it’s developed standalone, it’s causing enough headaches (not all software works fine with Test::Unit 2; we’ve had to resuscitate version 1.2.3 for Ruby 1.9 only, and we block version 2 from those packages who fail to build when it’s installed).

Doing this unbundling also caused two changes to the handling of virtuals: removing RDoc (version 2.5.8) from Ruby 1.9.2_rc2 means that Ruby 1.9 is no longer providing rdoc (but 1.8, EE and JRuby do), so we need a new virtual/ruby-rdoc; removing minitest instead means the only provider of that interface is dev-ruby/minitest, and thus we no longer need the standalone virtual. This simplifies a lot because there are a number of packages that really need the 1.7.0 version of minitest, while Ruby 1.9 still bundles 1.6.0.

But looking at it, also shown that there are two further packages that were bundled before (and are no longer, thankfully): racc and json. The latter is quite unexpected to me, given that a lot of gems needed it separated anyway, and it’s not registered as a gem at all.

And finally, while I was at it, I also removed the remaining code of RubyGems from the interpreter-installed libraries (given that way too many packages needed a full-blown copy of rubygems with Rake tasks and all the shizzle).

The end of the story is that now we got a slimmer, smaller Ruby 1.9 install, and the declaration of dependencies should be all correctly set. Having unbundled RDoc also means that we might have less work to do to make API doc generation to work on Ruby 1.9.

The Road to Ruby 1.9: Re-keywording

For those still pressing to have Ruby 1.9 available out of the box in Gentoo, the Ruby team is happy to announce that we’ve reached now the first step to get this done: re-keywording.

I’ve opened bug #332593 to ask arch teams to re-keyword Ruby 1.9, so that we don’t have to mass-drop keywords on the Ruby packages themselves. This is the first step toward the unmasking and thus the general availability of Ruby 1.9 for the masses. Now, while I have covered some questions before I’d like to answer a few more now, just to be on the safe side.

Why is package $foo asking me to downgrade rubygems? Your package is not ported to the new eclasses — in particular it’s still using the old gems.eclass that is now deprecated and should not be used at all. The way that old eclass works, it needs a hacked Rubygems that can work from within Portage; I’ve recently unhacked it so that it does not have that trick anymore, and rather follows upstream. We don’t use rubygems directly with the new eclasses so there is no need for it to have such hacks. If you’re on a stable system with some unstable packages, make sure to use the unstable version of the package requesting the old rubygems; if that doesn’t solve it, the package itself needs to get ported. In theory there shouldn’t be many more packages like that around. I’ll try to write soon on how to do that porting.

Why is 1.9.1 gone? Well, turns out that most of the code out there targeting 1.9 is mostly working with 1.9.2 as well as the previous 1.9.1; the porting is generally trivial and can even be worked around, and usually just hits tests, documentation building and – much more rarely – the build of the extension itself. For the rest, they are compatible enough that the trouble with the new version is bearable. And since it also solves a number of problems for us (with the layout it uses for installing on the filesystem), it’s a definitely better target.

When will Ruby 1.9 be unmasked? It’s not yet defined, but it still shouldn’t take too long; as I said before we haven’t covered yet all the problems, such as bundled bindings, Ruby-as-interpreter and other things like that. I’m not sure if we’ll cover all of them before the unmask to be honest, but we’ll have a plan before unmasking at least.

Can I set Ruby 1.9 as default interpreter? Can I simply use Ruby 1.9 without 1.8? Right now, Ruby 1.8 is still the officially supported default interpreter. That means that quite a bit of code will fail if you don’t have 1.8 installed, and some other will fail if ruby defaults to 1.9. As it happens, right now as well as once it’ll be unmasked, we’ll be accepting reports for packages failing with Ruby 1.9 installed, but not if it’s the sole installed or the one selected. You can report bugs with patches to fix problems with Ruby 1.9 selected (as long as the patch is clean and not a hack), and you’re asked to not report bugs if you don’t have 1.8 installed at all, unless you have a very good patch to solve the issue.

I know already that it’s a tricky situation, as all of us would prefer not to have to rely on using ruby19 for our scripts; this is why I have already talked about the need for making the ruby command be a smart wrapper, akin to the Python one, rather than a symlink. This way we can change the selected interpreted on the fly, and have a different one on a per-user basis. Doing so safely, though, is a bit tricky; nothing that can’t be done, but might require a bit more work than you’d expect. And right now, I’m swamped enough with job tasks that I cannot spend another unpaid day working on it. You know the drill.

Why does it want to install the same virtual package many times? I’ve started today implementing Ruby virtuals (virtual/ruby-*) slotted per implementation. This is a neat trick that allows keywords to be handled more easily, as each version keeps the most-stable keywords from the implementation it tracks, without use.mask and other tricks in the middle of it. As of today this only concerns ruby-ssl (which are the OpenSSL bindings for Ruby, provided by the ssl USE flags on MRI and REE, and by jruby-openssl for JRuby as the name states), but I’ll probably move the other virtuals to use the same idea in the next weeks.

With all the fuss about LDFLAGS why most compiled Ruby extensions ignore them? Actually, they aren’t ignoring LDFLAGS as much as respecting what Ruby itself tells them to use. For a long and boring story, the default for them is to use whatever Ruby was built with. It’s tricky to get around that as not all extensions use just those and there isn’t a very good way to solve it that I know. I’ll be working on finding a decent workaround, but it’s lower priority for now for me.

Why do you single out against Funtoo, rather than all the Gentoo-derivatives? Okay this I actually got asked only once and I’d like to point out what the problem is with Funtoo better. It really involves Ruby alone in this case; since Daniel not only wanted to have Ruby 1.9 available, but decided to change the Ruby naming scheme used by Gentoo; while we had ruby16, ruby18 and now ruby19, Funtoo uses ruby1.9.

That wouldn’t be a problem, if it wasn’t that the RUBY_TARGETS was designed to make use of the base name of the ruby interpreter – yes Ruby Enterprise has a different name, it wasn’t my call, but ree18 sounds better than rubyee18 when you have to actually use it, and mri18 wasn’t very easy to understand for most users – and expects Ruby 1.9 to be… ruby19.

So unless the Funtoo guys decide to go back to our naming scheme, they’ll have to patch our eclasses to add support for their non-standard installation. Good luck to them and their for keeping that up. For sure I’m not going to spend my free time to debug their issues as they called it up on themselves.

As usual, I have to remind you all that I’m working on Ruby mostly on my personal free time, so unless you do like Zeno and pay me to look into what you’re interested in, just complaining that we’re not good enough for your liking is not going to get you anywhere. On the other hand feel free to report problems if you find something that does not work as intended.

And as I noted, I’m happy to be paid for working on particular gems you’d like to see available in Portage under the quality assured by the Gentoo Ruby team (with Ruby 1.9 and Ruby Enterprise support if applicable).

Rubygems… UNHACKED!

I have written yesterday about the difficulty of removing the Rubygems hacks we’ve been using — well, today I got a good news: I was able to mostly remove them. I say mostly because there are still a couple of things that need to be fixed, with the help of upstream (all my changes are available on my Rubygems fork in the gentoo branch):

  • there is no way in the original sources to change the location of the system configuration file; for Windows it’s found on the register, for everyone else it’s /etc; I’ve had to change the sources to allow for overriding that with the operating system defaults;
  • there is one test that actually only works if there is no alternate default set installed, as it checks that the binary directory of the gems is the same as the one for Ruby; that is no longer the case for us;
  • JRuby … pretty much fails a whole bunch of tests; some it’s not really its fault, for instance it lacks mkmf/@extconf@ since that there are no C-compiled extensions; others are caused by different problems, such as tests’ ordering or the huge difference in handling of threading between the original implementations and JRuby;
  • I had to patch up a bit the Rakefile so that it can be used without Rubyforge support, which was a requirement for Ruby Enterprise (well at least for my system; the problem is that it still does not build with OpenSSL 1.0, so I have a non-OpenSSL Ruby Enterprise install… and that means that Rubyforge can’t load, and even so the Rubyforge plugin for Hoe);
  • documentation fails to build, not sure on why or how, but it does, when using the rake docs command; I’ll have to check out why and see if I can get it fixed.

But now back to the important good news: you can now safely use the gem command as root! Gems installed with sudo gem install foo will install in /usr/local rather than directly in /usr, no longer colliding or clashing with the Portage-installed packages (which are officially supported). Obviously, both are searched, but the local variant would take precedence, and the user’s home gems get even higher priority for search. This also means that if you don’t care about Gentoo support for the Ruby extensions, you can simply use gem and be done with it.

Now moving a bit back to not-too-good news and next steps. The not-too-good news is that since this dropped all the previously-present hacks, including a few needed to get gem from within Portage, this new version is not compatible with the old gems.eclass. Well, it’s relatively not good news, and partially good news; this is one of the final nails in that eclass’s coffin; we have now a very good reason to get rid of all the remaining packages; soon.

*Note: I have said before that we still lack a way to properly build bindings that are part of bigger packages; luckily none of those require gems.eclass, they rather use the old ruby.eclass which does not require rubygems at all. So it’s fine to deprecate and get rid of the uses of that right now even though we might have more work to do before ruby-ng takes over everything.*

Next steps for what concerns the rubygems package itself, if it was up to me, would be to drop the four gem18, gem19, gemee18 and jgem: all the ruby-fakegem.eclass binary wrappers right now install a single script, which by default uses the currently-configured Ruby interpreter, and you simply have to use ruby19 -S command to start it with a different interpreter. But gem itself is not treated this way and we rather have four copies of it with different names, and different shebangs, which sounds a waste. To change this, among other things, we need to change the eselect-ruby module (which I sincerely would avoid touching if possible).

Further step: supporting multiple Ruby implementation with the current system is mostly easy… but we have no way to change the current interpreter on a per-user or per-session basis; this is something that, as far as I can tell, we could actually take out of the Python book (or maybe the Java book, both have something like that, but the Python failures actually teach us one very important thing: we cannot use a script, we have to use a binary to do that job, even if it’s a very stupid one, as older Linux and other non-Linux systems will fail if you chain interpreters). Again, an eselect-ruby task… I would probably wait for Alex, unless there is enough interest for me to work on it.

Then let’s see, we’ve got to fully migrate out of the old-style virtual/ruby dependencies into =dev-lang/ruby-1.8* so that we can actually implement a new-style virtual that proxies the ssl USE flag, and then start using that; we’ve got to implement a general way to handle one-out-of-multiple target handling for packages that use Ruby as an embedded interpreter rather than build libraries for it; then there is again the problem of finding a way to build bindings within larger packages (or move some of them to build the Ruby extensions by themselves — I remember obexftp could use something like that), there is the fake-specification-generation to be fixed so that it works with bundler, and there are some (corner?) cases where Ruby 1.9 complain about missing fields in our generated files. So as you can see there is a long way still, but we’re going up there, step by step.

And before I leave, I’d like to thank Zeno Davatz for funding the un-hacking of rubygems — if that wasn’t the case, I’d probably have had to post this next week, or month. And if there are other people wanting Ruby 1.9 available faster (or improved 1.8 support), I’m still available to be hired, you can contact me and provide me with an idea of what you’re looking for. I’m available both to implement particular feature pieces, porting of the web of dependencies of given gems, or even just on a retainer basis so that you can have “priority” support for what concerns the general extension packaging in Gentoo.