ruby-sig June 2010

ruby-sig@lists.fedoraproject.org

13 participants
10 discussions

Removing ruby-activerecord
by Mo Morsi 25 Aug '10

25 Aug '10

Hey, so I spent far too long over the last few days trying to get activerecord v2.3.8 to compile against Fedora before I realized that I was basing my attempt off the wrong package. Specifically, we have two activerecord rpms in Fedora, ruby-activerecord and rubygem-activerecord http://cvs.fedoraproject.org/viewvc/rpms/ruby-activerecord/ http://cvs.fedoraproject.org/viewvc/rpms/rubygem-activerecord/ https://admin.fedoraproject.org/pkgdb/acls/name/ruby-activerecord https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-activerecord Obviously, conforming to standards, rubygem-activerecord is the way to go, and I can't figure out why we are keeping ruby-activerecord around, especially since its horribly out of date (pulling version 2.0.1, the package itself has not been updated since 2007). Can we orphan / remove ruby-activerecord all together? -Mo

2 3

RPM and GEMS - Unholy marriage
by Bert Meerman 02 Jul '10

02 Jul '10

Hi everyone, I've been following the discussion on RPM and GEMS conflict of interest. I found it quite interesting, and I would like to discuss some packaging options already present within ruby and rails. There are three things I would like to add to Jeroen's page: 1) A valid Rails RPM package *explicit* links to gems required. Strictly speaking, you can lazy load the gems an application needs. This might work, especially if you use gems that are very common (like Rails). Problem is, that a critical dependency is missing. You can add this info in the RPM spec, but I think it is better to make it mandatory more downstream. For RPM packaging, all you need to do is ask for the dependent gems. My question: what are your thoughts on this? 2) A valid Rails RPM package must contain the version when specifying gems and the version must be limited. Example: # require 'aws/s3' config.gem 'aws-s3', :lib => 'aws/s3', :version => '0.4.0', # :source => "http://code.whytheluckystiff.net" (see also http://api.rubyonrails.org/classes/Rails/Configuration.html#M002064) This means that the module will use any version greater than 0.4.0. You can also specify smaller, a range or a specific number. The trick is this: if you do this correctly, you can use multiple gem versions on the same system. In theory, this must work. This is what was causing the issue with Lighthouse. I think you should fix the version or make it a range, never a 'greater than' (as in the example and with Lighthouse). My question: what are your thoughts on this, especially the mandatory 'limit the version number'? 3) Gems can be vendorized. OK, this is the moment where a lot of people are going to be amazed, mouth open and staring at the screen for the next five minutes: you can make a Rails application and include the gems in it, as it where local code. This is called vendorization. A vendorized gem is only available to the application using it: it is part of the source code of that application and located in the /vendor directory of the application root (not in the normal gem directory). In fact, you can vendorize a gem and then even modify the code. On one hand, if you say all gems should be vendorized, you don't have any version conflicts. On the other hand, I heard someone complain about static linking... Personally, I disagree with the vendorization of gems. It obfuscates version management. Question: does Fedore prefer (or mandatorize) a specific approach? Why? Thanks in advance, Bert

3 4

Current ruby 187 srpm status?
by Mamoru Tasaka 28 Jun '10

28 Jun '10

( For this contents, I post also to ruby-sig) Mamoru Tasaka wrote, at 06/29/2010 02:24 AM +9:00: > Jim Meyering wrote, at 06/29/2010 01:49 AM +9:00: >> http://meyering.net/private/ruby-1.8.7.299-3.el6.src.rpm By the way, currently whose srpm are we planing to use for rawhide now? http://meyering.net/private/ruby-1.8.7.299-3.el6.src.rpm or http://mo.morsi.org/files/ruby-1.8.7.299-1.fc13.src.rpm ? Unifying these is much preferable for maintenance. And, comments to both srpm: - Please don't define %ruby_sitelib and %ruby_sitearch as below: ---------------------------------------------------------------------------- %{!?ruby_sitelib: %global ruby_sitelib %{ruby_vendorlib}/site_ruby} %{!?ruby_sitearch: %global ruby_sitearch %{ruby_vendorarch}/site_ruby} ---------------------------------------------------------------------------- These definitions are confusing compared to this: https://fedoraproject.org/wiki/Packaging/Ruby In ruby related spec file, we always define %ruby_sitelib, %ruby_sitearch as: ---------------------------------------------------------------------------- %{!?ruby_sitelib: %global ruby_sitelib %(ruby -rrbconfig -e 'puts Config::CONFIG["sitelibdir"] ')} %{!?ruby_sitearch: %global ruby_sitearch %(ruby -rrbconfig -e 'puts Config::CONFIG["sitearchdir"] ')} ---------------------------------------------------------------------------- On i686 these are expanded as /usr/lib/ruby/site_ruby/1.8 and /usr/lib/ruby/site_ruby/1.8/i386-linux . Please rename these macros in ruby.spec (like %sitelibbase %sitearchbase or so) Regards, Mamoru

1 0

RPM and GEMS conflict of interest
by Gilles Dubreuil 27 Jun '10

27 Jun '10

Hello, I've been asking myself why there bother with rubygem packages? Gems have a different life cycle and are completely managed through the gem interface: Basically if one can do a # yum install rubygem-rails then one can do a # gem install rails-2.3.8 But with gem one can also do # gem install rails-2.3.3 Up to the rails application to specify which version (or library) to use. So gems of different versions can coexist where rubygems rpms of different versions cannot be installed the same way and is redundant. Assuming they can be installed in parallel then there is an issue with the package name not showing the gem version i.e rubygem-rails.noarch. So I ended wondering why maintain rubygems rpms at all, once ruby is installed along with rubygems package then gem handles the rest. I'm sorry if this discussion has been brought earlier but it doesn't make sense for me. Thanks for thoughts. Gil

5 14

need some clear explain for current ruby package
by tommy xiao 27 Jun '10

27 Jun '10

FYI, where to easy get rpm list for current fedora 13.because if i first need get this rpm,i use google cant find this path or way. 2. if i want to contribute this ruby packge, if any guide can find? in ruby-sig wiki,i cant find more interest topic. i am rubyist,so i have no more fedora experience.so i need enhance this ability.any tutorial welcome best regards -- tommy xiao E-mail: xiaods(AT)gmail.com

2 2

Fwd: Re: ruby 1.8.7.x for rawhide
by Mo Morsi 24 Jun '10

24 Jun '10

Sorry, it doesn't seem like my original response made it through (at least not according to the ruby-sig archive http://lists.fedoraproject.org/pipermail/ruby-sig/2010-June/thread.html) Resending. -Mo -------- Original Message -------- Subject: Re: ruby 1.8.7.x for rawhide Date: Fri, 18 Jun 2010 12:44:56 -0400 From: Mohammed Morsi <mmorsi(a)redhat.com> To: Ruby SIG mailing list <ruby-sig(a)lists.fedoraproject.org> CC: Mamoru Tasaka <mtasaka(a)ioa.s.u-tokyo.ac.jp>, ruby-owner(a)fedoraproject.org Hey Mamoru, Appreciate the efforts. I am also working towards Ruby 1.8.7 on Fedora, just released a SRPM/SPEC a few days ago that I was working on http://mo.morsi.org/blog/node/318 Just fyi, we're also going to need this patch http://redmine.ruby-lang.org/repositories/diff/ruby-187?rev=27408 To get rails 3.0.0 working against Ruby 1.8.7p149 http://redmine.ruby-lang.org/issues/show/2557 I'm currently working on bundling Rails 3 into rpms and creating a Fedora based virtual appliance w/ Ruby 1.8.7 on it, similar to the one I released w/ Ruby 1.9, to make testing software against multiple versions of Ruby on Fedora as simple as possible. After that I'm planning on setting up an automated test system to test the various Ruby packages we have in Fedora against each appliance. Stay tuned for updtes. -Mo

4 40

ruby 1.8.7.x for rawhide
by Mamoru Tasaka 18 Jun '10

18 Jun '10

Hello, all: Currently kanarip is working on ruby 1.9.x, trying to import ruby 1.9.x packages into Fedora rawhide, and I fully appreciate his work. However - still many softwares (including packages I maintain like alexandria) don't support ruby 1.9.x - when importing ruby 1.9.x into Fedora, writing packaging guidelines when using ruby 1.9.x is needed. - and maybe ruby 1.9.x is enough stable, however I don't know well (kanarip?) - and I guess currently many users 1.8.x So I guess still ruby 1.8.x should be the main branch for F-14 (anyway kanarip is trying to make ruby 1.9.x parallel-installable). On the other hand, now ruby 1.8.6.x became rather old and some packages (like rubygem-nokogiri) decided to stop supporting ruby 1.8.6.x. So I want to update ruby to 1.8.7.x first, at least on rawhide. Test rpms of ruby 1.8.7.x for rawhide (and for F-13) are under: http://mtasaka.fedorapeople.org/ruby187/ (repodata also available) I appreciate it if you would test these packages. It is expected that people using ruby 1.8.6.x can upgrade ruby (and its subpackages) to ruby 1.8.7.x without problems, and without compiling anything against new ruby rpms. If these packages seem good, I would like to update rawhide ruby to 1.8.7.x in 10 days or so. ( I think upgrading ruby in F-13 to 1.8.7.x is quite debatable, however it seems ruby 1.8.7.x is enough stable and our 1.8.6.x srpm has many backports from 1.8.7 or 1.8.x branches and updating ruby to 1.8.7.x even on F-13 makes it easier to maintain ) ( By the way the ruby 1.8.7.x srpm I used for rawhide/F-13 also compiles on F-12 ) Regards, Mamoru

2 3

Me and my efforts on packaging sup
by shreyankg＠gmail.com 16 Jun '10

16 Jun '10

Hi, I am Shreyank Gupta and I want to package sup[0] for Fedora. I have done a few review requests ([1], [2], [3]) in order to package some of the remaining dependencies which have not been packaged for Fedora. Mamoru Tasaka has been reviewing most of it and has recently sponsored me into the Fedora Packagers group. Many thanks to him. Although there is another review request for rubygem-net-ssh[4] which needs to be processed so that all dependencies of sup are met. It would be great if someone could take it up. I am now writing and testing the spec for sup. Will keep you guys posted. [0] http://sup.rubyforge.org/ [1] https://bugzilla.redhat.com/show_bug.cgi?id=598138 [2] https://bugzilla.redhat.com/show_bug.cgi?id=597709 [3] https://bugzilla.redhat.com/show_bug.cgi?id=598980 [4] https://bugzilla.redhat.com/show_bug.cgi?id=588461 -- Peace and Love, Shreyank Gupta Blog: http://allsortsofshrink.blogspot.com

2 3

Building 1.9.1 on CentOS 5.5
by Robin Bowes 13 Jun '10

13 Jun '10

Hi, I just tried to rebuild ruby-1.9.1.378-16.el5.fr191.src.rpm on CentOS 5.5 and get this error: + autoconf configure.in:4: error: Autoconf version 2.60 or higher is required configure.in:4: the top level autom4te: /usr/bin/m4 failed with exit status: 63 error: Bad exit status from /var/tmp/rpm-tmp.92052 (%build) Note that this is the el5 package. Can that requirement be relaxed, ie. will it work with autoconf-2.59-12 that is available on RHEL/CentOS 5.5 ? R.

4 7

Fedora / Ruby 1.9 appliance
by Mo Morsi 03 Jun '10

03 Jun '10

Just figured I'd share this here incase anyone is interested but not subscribed to Fedora Planet. http://mo.morsi.org/blog/node/316 I just released a Fedora based virtual appliance w/ a Ruby 1.9.1 based rpm stack. To get there I managed to get ruby-shadow to compile against Ruby 1.9.1, released updated rubygems and rubygem-rake packages compatible w/ Ruby 1.9 (they are just empty packages now which depend on Ruby, as Ruby 1.9 ships w/ gem & rake), and pushed alot of updates to my polisher and polisher-scripts projects. http://github.com/movitto/polisher http://github.com/movitto/polisher-scripts All updated rpms were built in mock against the Ruby 1.9 rpm, so when you run a ruby-gnome app for example, your running against the latest gnome2 lib that ships w/ Fedora as well as the Ruby 1.9 libraries. To start the appliance, simply extract the tarball and run "sudo virt-image polisher-devel.xml". Then simply bring up virt-manager for graphical access to the vm. Many thanks to all on this list for all the work so far which I leveraged to build this appliance. There is alot more todo, I want to eventually get every Ruby project in Fedora built against 1.9.1, and try to get a Ruby 1.8.7 appliance up and running, but this should help anyone looking to start running software against a native Fedora/Ruby 1.9.1 stack. Enjoy. -Mo

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig June 2010