Ruby 2.0
by Vít Ondruch
Hi,
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.
Vit
[1]
http://pkgs.fedoraproject.org/gitweb/?p=ruby.git;a=tree;h=refs/heads/ruby...
10 years, 9 months
Ruby-SIG meeting at FUDCon Paris 2012?
by Vít Ondruch
Hi Rubyists,
Since me and bkabrda are coming to FUDCon Paris, it would be nice
opportunity to meet you, other Rubyists, and discuss some topics and
future directions of Ruby in Fedora. Please let us know who would be
interested to come and share your topics, which should be discussed. I
can throw in several right now:
* JRuby and Rubinius in Fedora and their integration with RubyGems.
* Bundler?
* Rails 3(4) in Fedora.
* Redmine, Passenger?
* Parallel installation of several gem versions.
* gem2rpm improvements
Vit
11 years
Rails 3.2 in Fedora 18
by Bohuslav Kabrda
Hi all,
I just created a feature page for Rails 3.2 in Fedora 18 [1] - I figured we will need to update, as the current 3.0 is getting quite old (I'm assuming nobody is against this, right?). I'd be glad if you could give me some comments and suggestions before submitting the feature to FESCo.
Thanks.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://fedoraproject.org/wiki/Features/Rails_3.2
11 years, 2 months
Ruby and Fedora 17
by Bohuslav Kabrda
Hi all,
since Ruby/Fedora integration had some significant changes from F16 to F17, I thought it might be a good idea to write a summary of new features and send it out for all - see [1].
All comments and suggestions for further development are welcome.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://bkabrda.fedorapeople.org/fedora17-ruby-eng-v2.pdf
11 years, 2 months
ABRT for Ruby
by Vít Ondruch
Hello,
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 [1], but if
went without response, so it seems that I will have to come with some
proposal.
I'd love to here your comments and of course your patches :)
Thank you
Vit
[1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/42236
11 years, 2 months
Status on a BZ? (830234)
by Darryl L. Pierce
https://bugzilla.redhat.com/show_bug.cgi?id=830234
This bug is a blocker for my main upstream project (Qpid, and also our
upcoming Proton codebase). It's also blocking our ability to move from
automake tools to Cmake for our packaging as well. The problem is
consistently:
Scanning dependencies of target cqpid_ruby
[ 89%] Building CXX object
bindings/qpid/ruby/CMakeFiles/cqpid_ruby.dir/rubyRUBY_wrap.o
In file included from /usr/include/ruby.h:32:0,
from
/home/mcpierce/temp/cmake/bindings/qpid/ruby/rubyRUBY_wrap.cxx:856:
/usr/include/ruby/ruby.h:24:25: fatal error: ruby/config.h: No such file or directory
compilation terminated.
make[2]: *** [bindings/qpid/ruby/CMakeFiles/cqpid_ruby.dir/rubyRUBY_wrap.o] Error 1
make[1]: *** [bindings/qpid/ruby/CMakeFiles/cqpid_ruby.dir/all] Error 2
make: *** [all] Error 2
The package config file does not tell the configuration tool about
/usr/include/x86_64-linux, which holds the headers in question.
Is anybody working on this problem? And does anybody have a temporary
workaround for Cmake environments?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
11 years, 2 months
Bigdecimal issues
by Bohuslav Kabrda
Hi guys,
I don't know if any of you have been following the problems that we had with bigdecimal Gem after switch to Ruby 1.9.3 in Fedora 17. Here are some references: [1], [2], [3], [4].
TLDR: The problem is, that when we unbundled bigdecimal from Ruby and made it available only as a Gem (under %{gem_dir} and %{gem_extdir}), a hidden problem showed up - other Gems (like activesupport or arel) just suppose it to be in the stdlib path and do not specify dependency on it in gemspec (or Gemfile generated with new Rails app, for example). Our RPM Gems deal with this, because we adapted them and added bigdecimal to the gemspecs. But Gems installed using "gem install" or "bundle install" cannot draw in bigdecimal, because they don't depend on it. Also, even if it's installed, bundler doesn't load the bigdecimal Gem during runtime. (One of the problems here is, that the Gems cannot add bigdecimal into gemspec, because there exists no JRuby alternative. So the JRuby users wouldn't be able to install such Gems. [5])
As you can see, there are already people complaining about this behaviour ([3], [4]) and I wouldn't like anyone to go away from Fedora after the effort we put into the transition to Ruby 1.9.3.
An ideal solution would of course be a systematic one, solving it with Ruby and JRuby authors, so that bigdecimal is gemified properly and everyone can put it into Gemfile/gemspec. I would very much like to ask you, if you could help me and Vit with this effort, mainly at [1] and [5].
Meanwhile, I would like to propose this solution:
The bigdecimal Gem RPM would contain symlinks that would be placed into Ruby's stdlib path, where the files were originally bundled. By doing this, we can both achieve the intended behaviour and also provide the ability to load newer version of bigdecimal (unless installed by user from rubygems.org), if it comes out (note, that Ruby with unbundled bigdecimal doesn't have this ability, as the bigdecimal in the stdlib always gets into play). Also, bigdecimal would be a dependency of Ruby, so it would get installed alongside with it to solve the issue completely.
If anyone of you comes out with a better solution to this situation, please share it, so that we may resolve this issue in the best manner.
Thanks to all!
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] https://bugs.ruby-lang.org/issues/6124
[2] https://github.com/rails/rails/issues/5355
[3] https://bugzilla.redhat.com/show_bug.cgi?id=829209
[4] http://forums.fedoraforum.org/showthread.php?t=279545
[5] http://jira.codehaus.org/browse/JRUBY-6704
11 years, 3 months
Re: Ruby v1.9.3 installed side by side with v1.8.7 - called by Rails apps with "RUBY_VERSION = x.y.z" ?
by Vít Ondruch
Dne 4.6.2012 20:23, Philip Rhoades napsal(a):
> Vit,
>
> I would prefer to avoid using RVM - is it possible to install (on
> Fedora 16 x86_64 in this case) both versions of Ruby and for the
> individual Rails apps to select which version of Ruby to use by the
> setting of a variable like:
>
> RUBY_VERSION = x.y.z
>
> in the config environment for each app?
>
> Thanks,
>
> Phil.
Hi Phillip,
Unfortunately that is not possible.
We were experimenting with Software Collections [1], but they were more
or less banned from Fedora by FPC. While there are some experimental
collections, such as [2], I am not sure in what condition they are, so I
cannot recommend them.
Vit
BTW Ruby-SIG mailing list would be better place for such questions,
because more people might be interested, or could provide better answer
then me. Lets move the discussion there.
[1] https://fedorahosted.org/SoftwareCollections/
[2] http://bkabrda.fedorapeople.org/scl_1.8.7_01-27/
11 years, 3 months
Gemfile.lock questions
by Ken Dreyer
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
application's runtime...?
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?
- Ken
11 years, 3 months
