Ruby

For those that are interested, I managed to cobble the Ruby 1.8.6 and 1.9.1 spec files together to form a Ruby 1.8.7 rpm (srpm here) built against Fedora 11 (yes I really need to update to F13, just haven't had the cycles yet). It's not 100% perfect, I tried to simplify the package as much as possible, removing any unneeded cruft, but in the process may have remove a couple things we wanted to keep (namely pulling the upstream ruby-tk branch for the ruby-tcltk package). But what is there is working as evident by the attached screenshot, and anything missing can easily be readded by using the 1.8.6 specfile as a reference.

Next I'm going to be working towards Rails 3.0.0 rpms and a Ruby 1.8.7 / Fedora appliance that pulls all of this in. After this we should have a base platform to try some widespread integration testing for multiple versions of Ruby on Fedora.

Enjoy!

I am pleased to release a Fedora 12 based appliance complete w/ a stack of rpms built against and related to Ruby 1.9.1.

This was built using Polisher, which I improved extensively and configured to generate various RPMs and yum repos. There are now many more rpms being generated/hosted since my last announcement, and after alot of work I finally got ruby-shadow to compile against Ruby 1.9.1. The packages themselves were built in mock, and made use of Polisher's project dependency support, so that projects built against the 'devel' repo were being built against the Ruby 1.9 package that resided there.

To make use of the appliance, download and extract the tarball, and run 'virt-image' on the polisher-devel.xml file (you will need the appliance tools installed). This will take care of all the work for you, you can then just open virt-manager, virt-viewer, or any other virt client and use a Ruby 1.9.1 build for Fedora!

Many thanks go out to those on ruby-sig for all the work to support Ruby on Fedora, especially Jeroen for the Ruby 1.9.1 spec file (and all the other work/research) which I initially based this of off. There were several other changes that went into it as issues were discovered, particularily some patches from Ruby 1.8.6 had to be readded to fix issues, and care had to be taken due to the fact that rubygems and rake were both merged into the official Ruby project stating in Ruby 1.9 (right now I figured the easiest way to handle this was to change those packages to be empty and just depend on / pull in the Ruby rpm).

There is still alot more work to do, eg nits w/ a few of the specific scripts, support for more projects, and a working Ruby 1.8.7 appliance (the maintenance repo and 1.8.7 specfile are still a work in progress). But what is there is a very easy way to run Ruby 1.9 natively on Fedora, and to start testing various software stacks. Until the next update, I leave you with this, a screenshot of Fedora 12 running a ruby-gnome app built/running against Ruby 1.9 (source code is attached to this post). Enjoy!

Alot of changes have gone into Polisher since my last update (eg the initial release). Most notably, the focus of Polisher has been changed and expanded, it now serves as a generic upstream project post-release processing tool, which can be used to configure any number of upstream projects w/ many various sources, and associate events with them to be triggered on releases. Polisher still works w/ the gemcutter API (namely the subscriptions / webhooks) as well as with gem2rpm, but now they are special cases in the generic upstream project management framework.

In the backend, Polisher is now based on Sinatra, which is far more lightweight and flexible than the previous solution, Rails. Rails is a powerful framework in itself, but I was looking for something small to help me establish the primary REST interface to the webapp.

Polisher also provides a nice DSL interface which can be used to define and run mass project / source registrations and trigger events in order to automate many various releases at the same time. I went through and picked several popular ruby-related packages from the current Fedora Repos, and wrote Polisher scripts for all of them, establishing several yum repositories for various Ruby related stacks.

Currently I have setup:

* stable - same packages that are currently in Fedora updates
* maintenance - later releases in the same major version branch of the packages currently in stable
* devel - packages that work w/ Ruby 1.9 (great resource)
* rawhide - all latest project versions

By tweaking the Polisher scripts and rpm spec file templates, the contents of these repos can be changed and new ones can be setup for any target software stack.

Any Fedora / yum user can simply point a yum repo entry towards any of those before running a yum update to get all the latest Ruby packages provided by that repo. Warning no functionality is guaranteed, there may currently be major breakage as Polisher and the scripts themselves are a work in progress. Furthermore, I'm in the process of setting up various Fedora based appliances, each pointing at a different Polisher generated repo by default. Any user can easily startup a VM on their local machine based off any of those appliances and instantly have Fedora w/ a complete Ruby stack for whichever version of Ruby they want to use. It's a work in progress, and I will have a link up soon to the downloadable images.

It would be awesome to get some help from anyone in the community that's interested in Ruby on Fedora (or any upstream project post-release processing on any flavor of Linux in general, as it's trivial to expand Polisher to handle any input/output package or repository format). It is a bit of effort to get Polisher scripts written for every Ruby related package, but if this thing starts rolling, I can see this as being a useful tool in the "upstream project to Fedora repo" process as mass parallel source releases can be triggered and handled easily in a committable / reproducible / reliable fashion.

Well that's it for now, be sure to note the many updates to deltacloud and many to my own projects, more on all of those in the near future.

Until next time, take it easy.

Just finished unorphaning, packaging, and submitting JRuby for Fedora. There were 13 Java packages (JRuby and 12 dependencies) that had to be updated and submitted, and getting them all in might take some time, but what's there is working, most packages build on Koji fine and the rest depend on other packages in the set that have to make it into the repos first. I've done quite a bit of Java work in the past (RIP Mr. Logistics!) but wouldn't say I'm a guru so if something is amiss feel free to comment in Bugzilla.

During this process I also looked into packaging Maglev, a cool new ruby interpreter that runs as a persistent server, which an end user's Ruby processes / vms running on any machine can connect to in order to manage objects and run code. No database backend is required, all persistence is done in the server and thus it scales very nicely and is highly optimized/fast (see this good article for more info). Unfortunately Maglev is still alpha and the build / install system is somewhat unconventional (neither of which is a problem for packaging for Fedora) but additionally the licensing situation is currently fairly messy and I'm not fully sure how compliant it is w/ the Fedora Licensing Guidelines. I'm going to keep track of this and potentially see what can be done if things change.

So for today, only one Ruby interpreter :-D All in all the following are the packages which need to be approved (those w/ a * next to them depend on other packages in the set). Fedora/Jython should also be able to benefit from these packages, as the newer versions of jython depend on some of these as well.

jffi nailgun yydebug yecht jnr-x86asm jgrapht jaffl* jcodings jnr-constants (formerly constantine) bytelist* jnr-posix (formerly jna-posix)* joni* jruby*

If anyone is interested in helping out w/ any aspect of the Fedora/Ruby integration feel free to join the discussion on the ruby-sig mailing list (particularly regarding supporting the various versions of Ruby and gems). Enjoy!

For anyone that missed it Pavol Rusnak had an excellent blog post on Fedora Planet regarding the current state of rubygems, specifically with gemcutter becoming the official rubygems source and the introduction of the new gemcutter webhook API to register callbacks to be invoked on gem updates. Also discussed is gem2rpm, which automatically converts a gem to a rpm specfile / srpm, and the need of a tool to bind those two components together.

Introducing Polisher which does just that, a rails based webapp that allows a user to add any number of gem sources, customize the packages they want to track, and register handlers to be invoked on certain gem events. Currently I have handlers to simply send an email, and/or generate a rpm artifact from the gem, and the interface is extensible enough so that anyone can add any event handler easily. I am currently working on a module that will automatically submit a bugzilla request for the gem/rpm. This will entail a feature akin to the 'dirty bit' discussed in Pavol's blogpost, for packages that need extra maintenance before submission, but polisher will still assist in the process in any case (and its possible we can develop a maintenance automation system which runs a maintainer's scripts to make changes to the package before bugzilla submission).

It is still early in development, the current state is the result of only a few days of coding, but I think it's already useful for the Ruby -> Fedora process. Lots of things still need to be added, there is no-multiuser support currently for example, but I'm already able to register callbacks for gemcutter gems, which upon being updated, get invoked.

Polisher is a webapp since the gemcutter webhook API takes a http url which to invoke w/ POST params on a gem update. Whoever will want to run this will need a public-facing domain to do so. I put a copy up on my personal domain, feel free to give it a try, just please don't try to stress test it ;-) (and forgive the simplistic interface, was going for functional/quick). polisher demo

At some point, if this takes off, it would be awesome to get some hosting space for the Fedora community, and to setup an automated Ruby->Fedora workflow engine, w/ maintainer intervention at the appropriate points.

The polisher source is licensed under the GPL and can be downloaded from github. I also pushed the polisher gem to the gemcutter repo and you can install it w/ gem install polisher provided you have a recent enough version of rubygems (w/ gemcutter officially part of the repo list).

Speaking of rubygems I've also pushed gems for several of my other projects including rxsd, simrpc, and motel, all of which are now available via gem install. Enjoy!

I spent a little while looking into the current state of JRuby in Fedora. It turns out it's not so good, the JRuby package itself has been orphaned and is no longer available starting in F12, as well as several of its Java dependencies, not to mention recent versions of JRuby have added several more dependencies which have yet to be packaged. All in all the following software needs to be packaged and accepted into Fedora before JRuby can be:

• jffi
• nailgun
• jruby-embed
• yydebug
• yecht
• bytelist (orphaned)
• constantine (orphaned)
• jcodings (orphaned)
• joni (orphaned)
• emma (already in Fedora, a dependency just needs to be added to the JRuby rpm spec)
• jvyamlb (is no longer a JRuby dependency and can be removed from the jRuby rpm spec)

Of course JRuby itself ships w/ these jar's included, but due to the Fedora Java Packaging Guidelines concerning this matter, jars cannot ship in any Fedora packages and must be standalone / included in the RPM dependencies

So it seems that a JRuby package in Fedora will be tricky for the time being until these dependencies are resolved, I would like to devote some cycles to this at some point, but given the current state of things, it'll take alot longer than I currently have. Its a great project for anyone thats interested, even those w/ no Fedora packaging experience as there is alot of work already done that you can leverage. At some point I might just package the latest jRuby release up (jars included) and push it to my yum.morsi.org yum repository for convenience sake, but obviously this would be suboptimal to getting JRuby in Fedora.

Just released RXSD (via github), a XSD <-> Ruby classes translator that makes use of Ruby's runtime introspection / reflection mechanisms to convert XML Schema Definitions to Ruby classes on the fly. Also supported is generating string Ruby class definitions (to be subsequently written to the filesystem) as well as a XSD metadata library / extendable builder interface to add output support for whatever language you need (python, c++, java, xml and other various formats, etc).

It's still pretty rough around the edges, I whipped it up in a little under a month (licensed under the LGPLv3+, so feel free to use it in proprietary apps, just make sure to publish the changes to RXSD itself back upstream), but most of whats there should be working. I'm going to keep hacking at it, mainly in part of a couple other things I'm doing, but also to improve features / support all around. This is my first project I'm hosting on github, so we'll see how that goes, from what I've seen it's pretty cool though (makes it very easy to share changes back / forth between projects).

As always, have at it!

In the department of things I've spent far too much time working on, I just wrote a vim script that allows you to automatically insert a random number into the file you're editing. It probably could use a little work, but does what I need it to do (easily generate random numbers for test fixtures). To use it yourself, add the following to your ~/.vimrc:

" generate random number at end of current line 
function! s:Rand(max)
y a         
redir @b    
ruby << EOF
  rmax = VIM::evaluate("a:max")
  rmax = nil if rmax == ""
  printf rand(rmax).to_s
EOF
redir END 
let @a = strpart(@a, 0, strlen(@a) - 1)
let @b = strpart(@b, 1, strlen(@b) - 1)
let @c = @a . @b
.s/.*/\=@c/g
endfunction
command! -nargs=? Rand :call <SID>Rand(<q-args>)
nmap <F6> :Rand <CR>
nmap <F7> :Rand 100<CR>
nmap <F8> :Rand 100000<CR>

When using vim, simply enter command mode and type :Genrand <maxnumber> to generate a random number and insert it at the end of the line. Alternatively, simply hit <F7> to generate and insert a random number between 1 and 100.

Here are some useful links pertaining to scripting in vim.