Since February, there are available RSpec 2.x in Fedora repositories.
However, as of now, the main package rubygem-rspec was not migrated to
RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
if we could finish the migration to RSpec 2.x lets say in F17 time
frame. What are your opinions? The list of packages which depends on
RSpec 1.3 is attached bellow.
If you wonder how to use RSpec 2.x for your package, it is usually quite
easy. In you spec just replace
# Use rspec-core until rspec are migrated to RSpec 2.x
and in you %check section, if you are not using Rake, replace call to
'spec' with 'rspec'. As an example, you can take a look on one of mine
rubygems, e.g. rubygem-regin, rubygem-pg.
Once we will migrate all packages into RSpec 2.x, we can migrate also
the rubygem-rspec and change the BR back to rubygem(rspec).
-------- Pu*vodní zpráva --------
Pr(edme(t: Re: aeolus conductor / rails 3 / F16 integration path
Datum: Tue, 12 Jul 2011 10:47:36 -0400
Od: Mo Morsi <mmorsi(a)redhat.com>
Komu: Vít Ondruch <vondruch(a)redhat.com>
> It is currently 24 packages which are using RSpec 1.x:
> ]$ repoquery --repoid=fedora-source --arch=src --whatrequires
> rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
> rubygem-boxgrinder-build-0:0.9.1-1.fc15.src (goldmann)
> rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann)
> rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
> rubygem-cucumber-0:0.10.0-5.fc15.src (mmorsi, clalance, mfojtik)
> rubygem-cucumber-rails-0:0.3.2-5.fc15.src (mmorsi, clalance, mfojtik)
> rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
> rubygem-factory_girl-0:1.3.2-3.fc15.src (mfojtik)
> rubygem-ffi-0:0.6.3-2.fc15.src (bkearney)
> rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
> rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x (vondruch)
> rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x (mmorsi)
> rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to be wrong dependency (vondruch)
> rubygem-rack-test-0:0.5.4-1.fc15.src (mfojtik)
> rubygem-rake-compiler-0:0.7.8-1.fc15.src (mamoru)
> rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x (vondruch)
> rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
> rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
> rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
> rubygem-thin-0:1.2.7-2.fc15.src (mfojtik)
> rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
> rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
> rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x (vondruch)
> rubygem-yard-0:0.5.3-3.fc14.src (mmorsi)
> So from my packages, 2 can be converted into RSpec 2.x right now, 2 are
> using 1.3, so it would need some effort and 1 seems to be just wrong
> dependency. May be we should move this discussion into ruby-sig ML
I appended the package owners onto the list for future reference.
Agree on moving this conversation to ruby-sig.
Im about to submit whole bunch of rubygems to Fedora. Most of them use rspec 1.3.
On Mon Jul 25th, 2011 10:10 AM EDT Mo Morsi wrote:
>Since this list is a lot shorter than the corresponding list in Fedora,
>perhaps we can get these package maintainers to update to RSpec 2.
>Otherwise, perhaps we can leave it in there as there for now, push the
>rspec-core and other subcomponents to EPEL, and update the BoxGrinder
>RPM to depend on those subcomponents instead of rspec itself?
>On 07/22/2011 09:18 AM, Marek Goldmann wrote:
>> For EPEL 6 - exactly 5:
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> For EPEL 5 - also 5:
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> On 22 lip 2011, at 09:48, Vít Ondruch wrote:
>>> RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea
>>> how many packages depends on RSpec in EPEL?
>>> Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
>>>> There is one more thing:
>>>> Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but there is only RSpec 1.3. What would be the approach to bump RSpec there?
>>>> On 18 lip 2011, at 18:49, Mo Morsi wrote:
>>>>> Perhaps we can shoot for doing this w/ F17, and if we are unable to
>>>>> migrate all the dependent packages over, then add a rspec1 compat
>>>>> package to buy us some more time.
>>>>> In any case, would rather push this off to F17 myself as a few of us are
>>>>> going through and updating alot of the rails related plugins to be
>>>>> compatible w/ Rails 3 in Fedora. We're trying to get this done by the
>>>>> F16 deadline next week.
>>>> ruby-sig mailing list
>>> ruby-sig mailing list
>> ruby-sig mailing list
>ruby-sig mailing list
Although Rails 3 was released, there are still rails projects working
with rails 2.3 series. Rails 3 is not backwards compatible and some key
features are not yet working in Rails 3. One notable project still on rails 2.3
is the issue tracker redmine http://www.redmine.org
Since rails 2 and rails 3 are perfectly parallel installable, I would like to
maintain rails 2.3 series in Fedora until it really becomes obsolete.
Therefore I have packaged Ruby 2.3.12 for F15/F16, basing them on the
Rails 2.3.8 packages already in F14.
This is my first package for Fedora and I welcome any feedback.
Thank you for your time.
---------- Forwarded message ----------
From: Mo Morsi <mo(a)morsi.org>
Date: Tue, Aug 2, 2011 at 9:24 PM
Subject: Re: Rails 2 in F16
To: Emanuel Rietveld <codehotter(a)gmail.com>
Hey Emanuel, appreciate the effort. Will look at it if I get the chance,
but time is short nowadays so not sure when that is going to be.
Most likely you will have luck if you email the ruby sig directly.
Since you are a new packager though, you will have to go through the
sponsorship process. Not hard, but it could take longer.
I dont usually like to cross post to multiple DLs but since These are Ruby
specific the Ruby SIG folks want to make sure the packages are following their
In order to get the pre-prerequisites needed for OpenNebula support in Fedora
Cloud, I would like some help in package reviews if you can spare some cycles.
Could the Ruby SIG and or Cloud SIG please review:
(Review Request: rubygem-stringex - Extensions to Rubys String class)
(Review Request: rubygem-idn - Ruby Bindings for the GNU LibIDN library)
(Review Request: rubygem-extlib - Support library for DataMapper and Merb)
(Review Request: rubygem-addressable - Improved URI/URL handling)
3rd party packaging, they need a sponsor:
(Review Request: rubygem-xmlparser-0.6.81-1 - Ruby bindings to the Expat XML
Once these are all approved, I will begin submitting rubygems for:
Rubygem Datamapper and its sub-rubygems (rubygem-dm-*)
Rubygem Dataobjects and its sub-rubygems (rubygem-do-*)
Then finally OpenNebula 3.0 itself.
Thanks for your help,
On Friday, August 12, 2011 10:48:14 AM Steve Traylen wrote:
> On Fri, Aug 12, 2011 at 2:41 AM, Shawn Starr <shawn.starr(a)rogers.com> wrote:
> >> 3rd party packaging, they need a sponsor:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=719854
> >> (Review Request: rubygem-xmlparser-0.6.81-1 - Ruby bindings to the
> >> Expat
> >> XML
> >> parsing library)
> They have a sponser me but I need to see more that just one package, some
> informal reviews of other packages before I can approve.
Hi Steve, that's for xmlparser, but I need help on the ones I've packaged also
I have provenpackager so I just need formal reviews then I'll kick off builds
in rawhide once approved.
we are currently facing issues with bundler, rails3 and RPM packages. We
distribute our project (katello / www.katello.org) and all it's
dependencies as RPM packages.
The problem is how to distribute Gemfile.lock file. We have some
configuration commited in our git repo. I guess the best approach is to
have the "oldest" libraries we have in our oldest distro we support
But when we build RPMs for F14 and F15 these versions has obviously
different rubygems, so the Gemfile.lock can't work for both. Users from
our community are constantly hitting problems like "You have [gemfile]
version XY, but I need version YZ". And we can only recommend to run
bundle install as a workaround.
There are few approaches to solve this issue that comes to my mind I
would like to discuss, or frankly to read better proposals from you guys.
1) Do not distribute Gemfile.lock at all.
It's pretty obvious that if we wont distribute the Gemfile.lock and
issue "bundle install --local" in the RPM %post script, it will create
one. The problem is this generated file is not longer part of the RPM.
It's the quickest (but dirtiest) solution.
When user upgrades a dependency, he or she could get into troubles. We
could re-generate the lock file everytime the app is restarted, but this
sounds more like a hack to me.
2) Generate Gemfile.lock during the build step
This solution is my favorite one. If we run "bundle install --local" in
the %build step and add all required rubygems as BuildRequire, it will
generate the correct lock file that can be distributed.
The disadvantage is obvious - we need to add all the rubygems as
BuildRequires. Isn't there any tool for generating these lock files
without adding many dependencies?
3) Unstitch bundler from the rails3 app
I am not sure if this can be done, but the idea is to get rid of the
bundler. In our case (RPM deployment, dependencies already solved using
yum) the bundler tool is pretty useless. I have no idea how to do it.
Sent a stackoverflow.com question - no aswer yet - http://bit.ly/oL5nNF
4) What you recommend?
Bundler is a great tool for development, or agile deployment
(capistrano, git and that kind of stuff). As a yet unexperienced rubyist
I tend to think when it gets to RPM-based deployment, it's in the way.
We don't need it anymore, more precisely it's an obstruct.
What would you recommend to do? We don't want to bother our users with
bundler errors, we would like to get rid of it, or to distribute always
I am looking forward your recommendations.
Thanks and have a nice weekend
Lukas "lzap" Zapletal