Just for your information, I have pushed ruby-2.0 branch into the Ruby's
git repo. So if you like test the latest Ruby, you need to get the
latest HEAD tarball, which could be prepared using:
$ cd /path/to/your/ruby/sources
$ ./tool/make-snapshot tmp
Note that you have to have available subversion and bison on your
system. Also note that the content of tarball is needed to be repacked,
that the Ruby sources will be stored in "ruby-2.0.0-p0" folder (I know,
it is annoyance, but you can fix the spec and send me a patch ;). Also
note that I currently keep the ruby_abi at 1.9.1, while the official
release will have 2.0.0 probably. This should allow you to use Fedora's
gems without rebuild. Any comments/patches are appreciated.
I've put together some basic implementation of ABRT support for Ruby. It
means that whenever your application/library fails in Ruby code (note
that this does not catch segfaults), it will be easy to your users to
report such problem into Bugzilla.
Source code: https://github.com/voxik/abrt-ruby
Gem: gem install abrt
ATM, there are several ways how to test the gem:
1) "require 'abrt'" in your code, as soon as possible, but later then
rubygems if you are using Ruby 1.8.
2) If you are already using Ruby 1.9, you can add "RUBYOPT='-rabrt'"
into your environment. This assures that every time Ruby is started, the
abrt gem is activated. Unfortunately, this doesn't work with Ruby 1.8,
since RubyGems are not loaded by default and "RUBYOPT='-rubygems
-rabrt'" does not work for some reason :/
Please note that ABRT reports errors just for Ruby libraries managed by
RPM. If something appears to not work as expected, it is good to observe
/var/log/messages for more details.
In the future, I'd love to see this integrated into Ruby (probably in
F18?). I already asked upstream about possible integration , but if
went without response, so it seems that I will have to come with some
I'd love to here your comments and of course your patches :)
I have two more Ruby newbie questions :)
I see a lot of Gems contain a "Gemfile.lock" file. From looking at the
conventions in Fedora's packages, it's a good idea to not include the
Gemfile.lock in RPMs. I'm trying to understand how Gemfile.lock
relates to packaging.
General question: Is Gemfile.lock only intended to be a convenience
for Ruby Gem developers? I thought Gemfile.lock was only for
development, but it seems like its contents can also affect an
Packaging question: In preparation for packaging up Gitorious, I've
found that I need to delete some entries from Gemfile.lock in order to
use alternate Gem versions. Is it always safe to override the version
numbers in Gemfile.lock like this?
I'm getting ready to start working on Rails 3.2.3 for F18 (maybe) and
EPEL 6 (for sure).
Just wondering if anybody has already tried to package it and found any
gotchas you could make me aware of. Maybe we can share work.
One of the nasty issues related to broken dependency on old ruby is on ruby-debug related packages. For ruby 1.9 ruby-debug related gems are renamed and need new review requests and approval.
Now I have finished packaging and done some basic tests on these gems and these are ready for review. The related bug requests are:
bug 818457 depends on bug 818454 and bug 818458 depends on 818457. With approval of these 3 requests, broken deps report will be less noisy.
I would appreciate if someone will review these requests. Also I can take and review swap reviews.