~kanarip

Just for fun, I started building ruby-1.8.6 and ruby-1.9.1 packages for Enterprise Linux 5. These would be opt-in repositories, "channels" if you will, fast-tracking an Enterprise Linux 5 box to newer versions of Ruby, and many of the packages that depend on Ruby one way or the other (such as Ruby on Rails packages, and many Ruby Gems).

I started out with the Fedora packages, obviously, and after getting a bunch of packages in said repositories, and testing and patching and rebuilding a bunch of times, it became obvious;

For the type of situation where you want two of these "fast-track" repositories, or even just multiple versions of the same packages built under different conditions, it turns out to be mandatory that a Koji build of a certain package contains a globally unique package NEVRA (Name, Epoch, Version, Release, Architecture), so they can be distinguished between the two (very much different) versions of the package. That is to say, one package NEVRA can only be built once, and can only be duplicated to other destination tags.

Example: The ruby-shadow package (a requirement for Puppet, which makes it very important to me) is binary compiled, either against ruby-1.8.6 or ruby-1.9.1. For one version (e.g. upstream's 0.9.7) to be available through both repositories, one builds ruby-shadow-0.9.7-1.el5.src.rpm.

I build the package against two Koji build targets, each one using a build tag that causes a buildroot to be created with either ruby-1.8.6 or ruby-1.9.1; in my case these build targets are feature-el5-ruby-1.8.6 and feature-el5-ruby-1.9.1.

Koji however will only allow one specific package NEVRA to be built just once. But, ruby-shadow-0.9.7-1.el5.src.rpm has to be built twice; once for ruby-1.8.6, and once for ruby-1.9.1. Since one build with the same NEVRA already exists, another cannot be built.

Ergo, you need some kind of indication of the build-root/build-tag/destionation-tag in the package NEVRA...

And we go off rebuilding everything again... ;-)

Over the last couple of days it seems more and more people are stepping up to get Ruby 1.9.1 in Fedora, along with the packaging changes and all that. From a new list just two months ago, we now have 17 members working on the same problems collaboratively.

Worth noting is that I'm receiving patches from people that understand Ruby way better then I do, so it's one big happy learning experience for me too ;-) (Noted I do not use Ruby myself, nor do I program using Ruby)

Thanks to Ben Shakal, we're now over the issue I posted about earlier on the Ruby SIG mailing list, where gem install would work, but executing or requiring the gem wouldn't. Great work Ben, thanks!

From here on out, I'm going to extend the Ruby repositories for Fedora 12 and Fedora Rawhide to include some of the ruby gems with the new packaging guidelines. I'm still going to need new packaging guidelines to go along with the new packages so I'm probably going to build those packaging guidelines as I go along.

More news on Ruby later this year, hope to have some working stack early next year.

Hope you all have a merry Christmas!

Only a handful people seemed interested in a FUDCon session on Ruby, Ruby-1.9.1, the Enterprise Edition, packaging foo and so forth, so it's not part of the BarCamp ;(

I'm planning to have the session tomorrow though, just after lunch, in one or the other room, so if you are interested please follow around the guy with the bad haircut wairing a Von Dutch hooded sweater ;-)

I can't seem to find a nice, simple, stupid web administration interface for LDAP. I want the users of said web interface to just be able to click "Add User" and fill out givenName, sn. I'll derive from that a uidNumber, uid, homeDirectory, mail, generate a password, send out an email. Or something like that.  Same goes for groups "Add User to Group", or "Remove User from Group". All based on authorization levels or ACLs in LDAP, of course. Reliably enforcing a naming convention and all kinds of standard operating procedures.

So, I started my first Ruby on Rails project, and I called it SLAP (Simple LDAP Administration Panel). Since it's my first Ruby on Rails project, I'm trying to get used to the semantics that is Rails... Enabling the brand new Rails project to simply authenticate and authorize through LDAP for example is being a PITA. I'm looking at ActiveLdap, but I can't seem to figure it out -it is very scarcely documented.

It feels like this is part 7 or 8 in the ruby series, but I hope you're still hanging in there ;-)

Last time I blogged about Ruby 1.9.1 search paths, but after some converstation with Stephan Kasal in private, and some more on the Ruby SIG mailing list, I'm leaning towards the simplest ever search path;

/usr/local/lib{,64}/ruby
/usr/local/share/ruby
/usr/lib{,64}/ruby
/usr/share/ruby

As I also mentioned in this message, this looks very clear and straightforward to me! Regrettably, I have not yet had much response on the mailing list. I hope to be doing some rebuilds of packages depending on ruby later on, see how that goes, and maybe release a 1.9.2 release candidate version somewhere.

Are you a Ruby enthusiast or maybe a Ruby on Rails web application developer? Did you know Fedora has a Special Interest Group (SIG) for Ruby related development and issues?

If you are a Ruby dev, but you didn't know about the SIG, here's our Wiki page (lists SIG members, things to do, and needs a little work), and we now have a mailing list. Whether you are with Fedora already, or just use Fedora, Extra Packages for Enterprise Linux (EPEL) or Enterprise Linux itself (Red Hat, CentOS), this mailing list is your chance to get in touch with the developers and packagers that work on your platform.

I've posted a few things on Ruby before, I know, but this is one thing I really wanted to share with you. I'm thinking of making the search path look like this:

[jmeeuwen@ghandalf ruby-1.9.1-p243]$ ruby-1.9.1 -e 'puts $:'
/usr/local/lib64/ruby/1.9.1
/usr/local/lib64/ruby
/usr/local/share/ruby/1.9.1
/usr/local/share/ruby
/usr/lib64/ruby-1.9.1/site/1.9.1
/usr/lib64/ruby-1.9.1/site/
/usr/share/ruby/site/1.9.1
/usr/share/ruby/site/
/usr/lib64/ruby-1.9.1/vendor/1.9.1
/usr/lib64/ruby-1.9.1/vendor/
/usr/share/ruby/vendor/1.9.1
/usr/share/ruby/vendor/

Ergo;

1. Your local, architecture specific, ruby version specific stuff
2. Your local, architecture specific stuff
3. Your local, architecture independent, ruby version specific stuff
4. Your local, architecture independent stuff

   ^^ This would include results from "gem install"

5. Packaged, architecture dependent, ruby version specific stuff, such as ruby gems from RPM, or ruby libs
6. Packaged, architecture dependent stuff
7. Packaged, architecture independent, ruby version specific stuff
8. Packaged, architecture independent stuff

   ^^ This is where "yum install rubygem-*" would put it's files

9. Architecture dependent ruby vendor, ruby version specific stuff
10. Architecture dependent ruby vendor stuff
11. Architecture independent, ruby version specific, ruby vendor stuff
12. Architecture independent ruby vendor stuff

Did I forget anything? Comments?

I recently blogged about rubygem-passenger-2.2.5-2 being available from my repositories, and there's a few side-notes on this:

1. rubygem-passenger now requires rubygem-hawler, which was not (but is now) available from those same repositories
   rubygem-hawler enables one to perform /usr/bin/passenger-stress-test, which would have failed prior to including rubygem-hawler. I realize this would have better been split to a separate package, which is on my TODO list for the next version of rubygem-passenger
2. The Apache2 module is readily available through the mod_passenger package, a subpackage of rubygem-passenger. There's no need to run passenger-install-apache2-module and in fact that command will fail. I've added to my TODO list to remove that command from the package entirely, or replace it with my own script that lets you know to install the mod_passenger package.

If there is no objections within the next few days, I would like to upgrade rubygem-git to version 1.2.4 (instead of 0.7.0 which is now in Fedora 11). It is a requirement for one of the projects still in development over at my company. I'm not sure how many people use it, so I wanted to let you know ahead of time I'm going to upgrade it (unless there's significant objections).

Drop me a line if you have objections ;-)