Migration from RSpec 1.3 to RSpec 2.x
by Vít Ondruch
Hi guys,
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
BuildRequires: rubygem(rspec)
with
# Use rspec-core until rspec are migrated to RSpec 2.x
BuildRequires: rubygem(rspec-core)
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).
Vit
-------- 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(rspec)'
> 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.
11 years, 9 months
Re: Migration from RSpec 1.3 to RSpec 2.x
by Shawn Starr
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?
>
> -Mo
>
>On 07/22/2011 09:18 AM, Marek Goldmann wrote:
>> For EPEL 6 - exactly 5:
>>
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> rubygem-extlib-0:0.9.13-5.el6.src
>> rubygem-facon-0:0.4.1-2.el6.src
>> rubygem-rack-test-0:0.5.4-1.el6.src
>> rubygem-thin-0:1.2.8-4.el6.src
>> rubygem-uuidtools-0:2.1.1-1.el6.src
>>
>> For EPEL 5 - also 5:
>>
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> rubygem-extlib-0:0.9.13-5.el5.src
>> rubygem-facon-0:0.4.1-2.el5.src
>> rubygem-linode-0:0.6.2-1.el5.src
>> rubygem-thin-0:1.2.8-2.el5.src
>> rubygem-uuidtools-0:2.1.1-2.el5.src
>>
>> --Marek
>>
>> 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?
>>>
>>>
>>> Vit
>>>
>>>
>>>
>>> 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?
>>>>
>>>> --Marek
>>>>
>>>> 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.
>>>> --Marek
>>>>
>>>> _______________________________________________
>>>> ruby-sig mailing list
>>>> ruby-sig(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>>>
>>> _______________________________________________
>>> ruby-sig mailing list
>>> ruby-sig(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>>
>> _______________________________________________
>> ruby-sig mailing list
>> ruby-sig(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
>_______________________________________________
>ruby-sig mailing list
>ruby-sig(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
11 years, 9 months
unicorn
by "Guillermo Gómez S."
Ive been using mongrel as my main deployment webapp server for ruby in
combination with apache + haproxy but im interested on testing unicorn
now.
Of course i want to know my fellow rubyists here their opinion about
its actual use case and potentially packaging it in Fedora.
Should i go for it? Is it well maintained?
unicorn 4.0.1 - regression bugfixes / 2011-06-29 18:59 UTC is the last
news from them so it seems pretty a live.
quote: Rails 2.3.5 is not compatible with Rack 1.1.x. Unicorn is
compatible with both Rack 1.1.x and Rack 1.0.x, and RubyGems will load
the latest version of Rack installed on the system. Uninstalling the
Rack 1.1.x gem should solve gem loading issues with Rails 2.3.5. Rails
2.3.6 and later correctly support Rack 1.1.x.
I had to remove some rack (gems) newest versions in order to make it
work and i Im afraid my efforts could be lost if we include certain
rack version in f16... any thoughts?
--
Ing.Guillermo Gomez S.
Fedora Board Member A4 - Fedora Rubyist by heart
http://gomix.fedora-ve.org
http://www.neotechgw.com
12 years, 4 months
Parallel installable ruby stacks
by Sergio Rubio
Hey all,
I've been working lately in ruby packages for 1.8, 1.9,REE and
Rubinius that install in parallel and a ruby-base package that
basically pulls upstream ruby package (standard fedora/RHEL ruby) and
provides a script to switch between different ruby implementations
when available.
I've also been researching the fedora project wiki but haven't found
anything related to something like this in the roadmap.
So, what do you guys think about this? is this totally insane?
There's definitely the need out there to have different ruby
implementations available (lots of ppl using RVM for this reason) or
at least give the user the choice to install any of them without
scarifying the benefits that native packages provides.
I'd love to hear what do you guys think about this stuff and I'd love
to contribute with some sort of proposal if you guys think we can
waste some cycles investigating this path.
Rgds.
12 years, 4 months
Re: Rubygem packaging issues - Packaging OpenNebula rubygem dependencies
by Shawn Starr
Will let you know today.
Thanks,
Shawn
Chris Lalancette <clalance(a)redhat.com> wrote:
>On 07/23/11 - 12:27:40AM, Shawn Starr wrote:
>>
>> --- On Sat, 7/23/11, TASAKA Mamoru <mtasaka(a)fedoraproject.org> wrote:
>> <snip>
>>
>> > From: TASAKA Mamoru <mtasaka(a)fedoraproject.org>
>> >
>> > rubygem-thin needs fixing. Please file a bug.
>> >
>> > [tasaka1@localhost ~]$ ruby -e 'require "rubygems" ;
>> > require "thin"'
>> > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in
>> > `gem_original_require': no such file to load --
>> > /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin_parser
>> > (LoadError)
>> > from
>> > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in
>> > `require'
>> > from
>> > /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin.rb:47
>> > from
>> > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:59:in
>> > `gem_original_require'
>> > from
>> > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:59:in
>> > `require'
>> > from -e:1
>> >
>> >
>> > Regards,
>> > Mamoru
>> >
>> >
>> >
>>
>> I will file a bug, in the meantime, I'll fix it locally so I can continue testing my packages.
>
>I actually fixed this last Friday in rawhide, but I forgot to push/build the
>package. I've just done so now, so the package that is in rawhide (1.2.11-2)
>should work. Let me know if it doesn't.
>
>--
>Chris Lalancette
>_______________________________________________
>ruby-sig mailing list
>ruby-sig(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
12 years, 4 months
Re: Rubygem packaging issues - Packaging OpenNebula rubygem dependencies
by Shawn Starr
--- On Sat, 7/23/11, TASAKA Mamoru <mtasaka(a)fedoraproject.org> wrote:
<snip>
> From: TASAKA Mamoru <mtasaka(a)fedoraproject.org>
>
> rubygem-thin needs fixing. Please file a bug.
>
> [tasaka1@localhost ~]$ ruby -e 'require "rubygems" ;
> require "thin"'
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in
> `gem_original_require': no such file to load --
> /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin_parser
> (LoadError)
> from
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in
> `require'
> from
> /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin.rb:47
> from
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:59:in
> `gem_original_require'
> from
> /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:59:in
> `require'
> from -e:1
>
>
> Regards,
> Mamoru
>
>
>
I will file a bug, in the meantime, I'll fix it locally so I can continue testing my packages.
Is anyone able to review my rubygem packages also? I think I have the %check stuff done right, to a point (within reason)
Thanks,
Shawn.
12 years, 4 months
Rubygem packaging issues - Packaging OpenNebula rubygem dependencies
by Shawn Starr
Hello Folks,
I am currently packaging multiple rubygems, you can find my work here: http://www.sh0n.net/spstarr/fedora-work
I think i am doing it correctly as per the Ruby/Rubygem package specifications.
However, I am seeing a problem with OpenNebula which I am packaging for the Fedora Cloud SIG team. In that the rubygem loader is looking for different path? For example, with rubygem-thin:
It wants to find it here:
/usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin_parser.so
Vs
where the Fedora package specification says here:
/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/thin_parser.so
As in this error from OpenNebula on startup:
/usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `gem_original_require': no such file to load -- /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin_parser (LoadError)
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require'
from /usr/lib/ruby/gems/1.8/gems/thin-1.2.11/lib/thin.rb:47
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:59:in `gem_original_require'
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:59:in `require'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/handler/thin.rb:1
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/handler.rb:20:in `const_get'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/handler.rb:20:in `get'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:269:in `inject'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/handler.rb:20:in `each'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/handler.rb:20:in `inject'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/handler.rb:20:in `get'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:269:in `server'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:208:in `logging_middleware'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:292:in `call'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:292:in `build_app'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:291:in `reverse_each'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:291:in `build_app'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:301:in `wrapped_app'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:252:in `start'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/lib/rack/server.rb:137:in `start'
from /usr/lib/ruby/gems/1.8/gems/rack-1.3.0/bin/rackup:4
from /usr/bin/rackup:19:in `load'
from /usr/bin/rackup:19
Anyone able to help me understand why this is happening? Please feel free to help out reviewing those SRPMs. Please ignore the opennebula SRPM as it it is not ready for review.
Thanks,
Shawn.
12 years, 4 months
Heads up - Rails 3.0.9 hits Rawhide
by Vít Ondruch
Hi guys,
The Rails 3.0.9 are available in Rawhide as of now. Please test it and
report any issues you will find.
Regards
Vit
12 years, 4 months
