ruby-sig June 2012

ruby-sig@lists.fedoraproject.org

7 participants
9 discussions

Ruby 2.0
by Vít Ondruch 05 Dec '12

05 Dec '12

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-2…

1 3

Ruby-SIG meeting at FUDCon Paris 2012?
by Vít Ondruch 21 Sep '12

21 Sep '12

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

3 4

Rails 3.2 in Fedora 18
by Bohuslav Kabrda 18 Jul '12

18 Jul '12

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

4 9

Ruby and Fedora 17
by Bohuslav Kabrda 16 Jul '12

16 Jul '12

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

2 4

ABRT for Ruby
by Vít Ondruch 13 Jul '12

13 Jul '12

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

3 17

Status on a BZ? (830234)
by Darryl L. Pierce 02 Jul '12

02 Jul '12

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/

2 1

Bigdecimal issues
by Bohuslav Kabrda 07 Jun '12

07 Jun '12

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

1 0

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 05 Jun '12

05 Jun '12

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/

2 1

Gemfile.lock questions
by Ken Dreyer 04 Jun '12

04 Jun '12

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

8 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig June 2012