fedora

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!

Quick Fedora tip (thanks to nirik on #fedora-devel). If you are unorphaning a package and you've made it all the way to 'make build' each CVS branch you want into import into Fedora, just to get the following error from Koji:

2030661 build (dist-f13-updates-candidate, /cvs/pkgs:rpms/joni/F-13:joni-1_1_3-4_fc13): open (x86-01.phx2.fedoraproject.org) -> FAILED: BuildError: package joni is blocked for tag dist-f13-updates-candidate

You need to file a bug w/ the release engineering trac system to get your package unblocked. Here is my joni ticket for example

After it is unblocked, 'make build' should work, and you can submit any updates via bodhi.

Happy hacking!

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 got back from the Fedora Users and Developers Conference (FUDCon) in Toronto ON this past weekend. There I gave an introductory talk on the field of Cloud Computing and discussed the current project I'm hacking on @RH, deltacloud. The presentation went well and I got alot of great feedback / garnered some more interest in the project. I uploaded the slides here for anyone that's interested.

The weekend flew by, I drove up on Friday and back tonight (4hr each way). I attended alot of great talks and there were many that I wanted to go to but couldn't due to presentation overlaps. Regardless the ones I attended were all excellent and included

• J5's talk on AMQP. As it was an introduction to the topic and since I've done a bit of work using qpid in oVirt and Simrpc, I was familiar w/ a some of the material and but it still was very interesting and I picked alot of stuff up, such as the semantics of the different message transfer/event protocols, queue security / access control, and thoughts on the direction of AMQP/QPID and integrating it w/ community projects.
• An excellent talk on some of the new features in the GNU Debugger (GDB) including thread support, pretty printing (huzzah!), and C++ expression and namespace handling. When working on Romic and Manic and various other C++ projects I used the GDB debugger extensively and ran into many of the issues fixed with this versions. :-)
• Mairin Duffy's talk on UI mockups for developers using Inkscape. A great presentation on the Inkscape application, geared towards making a wireframe / simple UI mocks for review very quickly so that you can easily spot design problems before you write your first line of code, and so reviews are not as apprehensive about giving you honest feedback (as they would be if you invested a ton of time implementing the UI of your application before asking for a review)
• Luke Macken's presentation of his project, Moksha a real time webapp platform. Luke and I have discussed Moksha in the past, but usually from a high level "what does it do" point of view, and it was nice to see a detailed analysis of the framework and all the components, and see some live examples in action pertaining to using it. Its really powerful stuff, I recommend everyone check it out.
• A round table discussion about the future of Ruby in Fedora. Ruby's a great language but there are some problems in the current affairs of Ruby such as the incompatibilities between 1.8.6 / 1.8.7 point releases, which might to break alot of software if not handled properly (and thats just forgetting about Ruby 1.9 which is now the 'main' Ruby version). I understand major API changes between main versions (eg 1.8 -> 1.9) but a point release should _never_ have any major core API changes except in the most extreme / rare cases (eg security fixes, but those usually don't entail API changes). This is going to be somewhat problematic for Fedora/Ruby as we now need to support those different versions. Regardless the problem has come up before w/ other interpreted languages that have their own package management systems. Thanks go out to Jeroen van Meeuwen for maintaining the Ruby rpm and holding the discussion today / leading the effort to resolve this problem. I'm going to be joining the effort to assist that process in the near future.
• An introduction to Puppet the automated data center configuration tool. I have played around w/ puppet via thincrust (which oVirt depends on) in the past, but it was good to learn the various components of the puppet framework and how to setup an installation from scratch, using it to configure whatever systems to meet your needs

Overall the conference was great, and I am definitely looking forward to attending more FUDCons and other related events in the future.

Until next time, keep hacking!