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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Could you please try to migrate them to RSpec 2.x? It should not be a big problem (although I understand that it requires more work).
Vit
Dne 25.7.2011 19:01, Shawn Starr napsal(a):
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I'm not sure on that. I'm just packaging them for OpenNebula, I have little ruby development experience. I would need assistance in that effort.
--- On Tue, 7/26/11, Vít Ondruch vondruch@redhat.com wrote:
From: Vít Ondruch vondruch@redhat.com Subject: Re: Migration from RSpec 1.3 to RSpec 2.x To: ruby-sig@lists.fedoraproject.org Date: Tuesday, July 26, 2011, 7:39 AM Could you please try to migrate them to RSpec 2.x? It should not be a big problem (although I understand that it requires more work).
Vit
Dne 25.7.2011 19:01, Shawn Starr napsal(a):
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I will take a look tomorrow on your rubygem-extlib and will see if that can work with RSpec 2
Vit
Dne 26.7.2011 16:43, Shawn Starr napsal(a):
I'm not sure on that. I'm just packaging them for OpenNebula, I have little ruby development experience. I would need assistance in that effort.
--- On Tue, 7/26/11, Vít Ondruchvondruch@redhat.com wrote:
From: Vít Ondruchvondruch@redhat.com Subject: Re: Migration from RSpec 1.3 to RSpec 2.x To: ruby-sig@lists.fedoraproject.org Date: Tuesday, July 26, 2011, 7:39 AM Could you please try to migrate them to RSpec 2.x? It should not be a big problem (although I understand that it requires more work).
Vit
Dne 25.7.2011 19:01, Shawn Starr napsal(a):
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@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
I believe someone owns rubygem-extlib in EPEL but not for Fedora since it was dropped. I bumped it to .15 and enabled Yard documentation in it.
--- On Tue, 7/26/11, Vít Ondruch vondruch@redhat.com wrote:
From: Vít Ondruch vondruch@redhat.com Subject: Re: Migration from RSpec 1.3 to RSpec 2.x To: ruby-sig@lists.fedoraproject.org Date: Tuesday, July 26, 2011, 3:35 PM I will take a look tomorrow on your rubygem-extlib and will see if that can work with RSpec 2
Vit
Dne 26.7.2011 16:43, Shawn Starr napsal(a):
I'm not sure on that. I'm just packaging them for
OpenNebula, I have little ruby development experience. I would need assistance in that effort.
--- On Tue, 7/26/11, Vít Ondruchvondruch@redhat.com
wrote:
From: Vít Ondruchvondruch@redhat.com Subject: Re: Migration from RSpec 1.3 to RSpec
2.x
To: ruby-sig@lists.fedoraproject.org Date: Tuesday, July 26, 2011, 7:39 AM Could you please try to migrate them to RSpec 2.x? It should not be a big problem (although I understand that it
requires more
work).
Vit
Dne 25.7.2011 19:01, Shawn Starr napsal(a):
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@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
> ruby-sig mailing list > ruby-sig@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starr shawn.starr@rogers.com wrote:
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
I believe someone owns rubygem-extlib in EPEL but not for Fedora since it was dropped. I bumped it to .15 and enabled Yard documentation in it.
I own extlib in EPEL, but welcome any co-maintainers. I haven't had a chance to dig into it's rspec requirements.
On Tuesday, July 26, 2011 05:17:54 PM Michael Stahnke wrote:
On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starr shawn.starr@rogers.com wrote:
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
I believe someone owns rubygem-extlib in EPEL but not for Fedora since it was dropped. I bumped it to .15 and enabled Yard documentation in it.
I own extlib in EPEL, but welcome any co-maintainers. I haven't had a chance to dig into it's rspec requirements.
Any reason not to jump to .15? I don't really mind eithey way, sure I can co- maintain it also. Since Fedora (rawhide) usually has newer that EPEL, I thought I'd just go to the latest version.
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
On Tuesday, July 26, 2011 08:21:16 PM Shawn Starr wrote:
On Tuesday, July 26, 2011 05:17:54 PM Michael Stahnke wrote:
On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starr shawn.starr@rogers.com
wrote:
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Some updates,
- I will remove all of my ruby- subpackage dependencies if what Vít Ondruch is saying was a bad design. - Im going to attempt to port the other rubygems I'm working on to use RSpec 2.x, for the ones that fail I will list them in this thread.
If anyone would like to help me, please let me now :)
Shawn.
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
I believe someone owns rubygem-extlib in EPEL but not for Fedora since it was dropped. I bumped it to .15 and enabled Yard documentation in it.
I own extlib in EPEL, but welcome any co-maintainers. I haven't had a chance to dig into it's rspec requirements.
Any reason not to jump to .15? I don't really mind eithey way, sure I can co- maintain it also. Since Fedora (rawhide) usually has newer that EPEL, I thought I'd just go to the latest version.
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
So it seems extlib can be migrated to the RSpec 2.x quite easily. See the attached patch.
Btw the package build fails later due to YARD documentation build using Rake. I consider using of Rake as bad practice since Rakefiles are usually too tightly integrated with developer setup, therefore causing more problems than benefits during the build process.
Vit
Dne 27.7.2011 02:17, Michael Stahnke napsal(a):
On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starrshawn.starr@rogers.com wrote:
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
I believe someone owns rubygem-extlib in EPEL but not for Fedora since it was dropped. I bumped it to .15 and enabled Yard documentation in it.
I own extlib in EPEL, but welcome any co-maintainers. I haven't had a chance to dig into it's rspec requirements. _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Dne 26.7.2011 18:03, Shawn Starr napsal(a):
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Thank you.
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
Just out of curiosity, why you prefer "data_mapper" over "datamapper"?
Vit
On 27 lip 2011, at 09:04, Vít Ondruch wrote:
Just out of curiosity, why you prefer "data_mapper" over "data mapper"?
Good question, especially when upstream calls it "datamapper":
https://rubygems.org/gems/datamapper
--Marek
Dne 27.7.2011 09:08, Marek Goldmann napsal(a):
On 27 lip 2011, at 09:04, Vít Ondruch wrote:
Just out of curiosity, why you prefer "data_mapper" over "data mapper"?
Good question, especially when upstream calls it "datamapper":
https://rubygems.org/gems/datamapper
--Marek
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Actually there are available both gems, datamapper as well as data_mapper ...
Vit
Fun, I was looking at the release notes for latest datamapper and it seems they highlight "datamapper" over "data_mapper":
http://datamapper.org/articles/datamapper-110-released.html
It looks like they used the "dash version" earlier:
http://datamapper.org/articles/datamapper-102-released.html http://datamapper.org/articles/datamapper-100-released.html ...
IMHO the dash version is published for compatibility reasons.
--Marek
On 27 lip 2011, at 09:25, Vít Ondruch wrote:
Actually there are available both gems, datamapper as well as data_mapper ...
Probably, but its wrong anyway. For example sqlite3-ruby was renamed to sqlite3. Nevertheless if you try to install sqlite3-ruby, it installs sqlite3 anyway. Not sure how is that done, but it should be probably reported upstream.
Vit
Dne 27.7.2011 09:53, Marek Goldmann napsal(a):
Fun, I was looking at the release notes for latest datamapper and it seems they highlight "datamapper" over "data_mapper":
http://datamapper.org/articles/datamapper-110-released.html
It looks like they used the "dash version" earlier:
http://datamapper.org/articles/datamapper-102-released.html http://datamapper.org/articles/datamapper-100-released.html ...
IMHO the dash version is published for compatibility reasons.
--Marek
On 27 lip 2011, at 09:25, Vít Ondruch wrote:
Actually there are available both gems, datamapper as well as data_mapper ...
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
I have created upstream ticket for this: http://datamapper.lighthouseapp.com/projects/20609-datamapper/tickets/1520
Vit
Dne 27.7.2011 10:05, Vít Ondruch napsal(a):
Probably, but its wrong anyway. For example sqlite3-ruby was renamed to sqlite3. Nevertheless if you try to install sqlite3-ruby, it installs sqlite3 anyway. Not sure how is that done, but it should be probably reported upstream.
Vit
Dne 27.7.2011 09:53, Marek Goldmann napsal(a):
Fun, I was looking at the release notes for latest datamapper and it seems they highlight "datamapper" over "data_mapper":
http://datamapper.org/articles/datamapper-110-released.html
It looks like they used the "dash version" earlier:
http://datamapper.org/articles/datamapper-102-released.html http://datamapper.org/articles/datamapper-100-released.html ...
IMHO the dash version is published for compatibility reasons.
--Marek
On 27 lip 2011, at 09:25, Vít Ondruch wrote:
Actually there are available both gems, datamapper as well as data_mapper ...
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
then I am getting conflicting views since OpenNebula folks said they asked upstream and they were told to use data_mapper?
if anything we would just patch OpenNebula to use 'datamapper' if we have to No big deal.
----- Original Message ----- From: Marek Goldmann mgoldman@redhat.com To: Ruby SIG mailing list ruby-sig@lists.fedoraproject.org Cc: Sent: Wednesday, July 27, 2011 3:53:07 AM Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
Fun, I was looking at the release notes for latest datamapper and it seems they highlight "datamapper" over "data_mapper":
http://datamapper.org/articles/datamapper-110-released.html
It looks like they used the "dash version" earlier:
http://datamapper.org/articles/datamapper-102-released.html http://datamapper.org/articles/datamapper-100-released.html ...
IMHO the dash version is published for compatibility reasons.
--Marek
On 27 lip 2011, at 09:25, Vít Ondruch wrote:
Actually there are available both gems, datamapper as well as data_mapper ...
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
If it's preferable, can someone take a look at all my proposed rubygem packages? Although I managed to get most of them to build using the developer's testing methods. If it's easy to switch them to use RSpec 2.x, by just adjusting dependency and using rspec instead of rake for test validation I can switch all of mine.
Otherwise, I'm not sure how to proceed.
----- Original Message ----- From: Shawn Starr shawn.starr@rogers.com To: Ruby SIG mailing list ruby-sig@lists.fedoraproject.org Cc: Sent: Wednesday, July 27, 2011 11:24:34 AM Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
then I am getting conflicting views since OpenNebula folks said they asked upstream and they were told to use data_mapper?
if anything we would just patch OpenNebula to use 'datamapper' if we have to No big deal.
----- Original Message ----- From: Marek Goldmann mgoldman@redhat.com To: Ruby SIG mailing list ruby-sig@lists.fedoraproject.org Cc: Sent: Wednesday, July 27, 2011 3:53:07 AM Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
Fun, I was looking at the release notes for latest datamapper and it seems they highlight "datamapper" over "data_mapper":
http://datamapper.org/articles/datamapper-110-released.html
It looks like they used the "dash version" earlier:
http://datamapper.org/articles/datamapper-102-released.html http://datamapper.org/articles/datamapper-100-released.html ...
IMHO the dash version is published for compatibility reasons.
--Marek
On 27 lip 2011, at 09:25, Vít Ondruch wrote:
Actually there are available both gems, datamapper as well as data_mapper ...
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
_______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Upstream has confirmed to me that data_mapper is the preferred name, as there is also rubygem-data_objects.
----- Original Message ----- From: Vít Ondruch vondruch@redhat.com To: ruby-sig@lists.fedoraproject.org Cc: Sent: Wednesday, July 27, 2011 3:04:32 AM Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
Dne 26.7.2011 18:03, Shawn Starr napsal(a):
Thanks, all my current SRPMs are here at http://www.sh0n.net/spstarr/fedora-work
Thank you.
Note rubygem-datamapper is now rubygem-data_mapper so ignore the latter SRPM.
Just out of curiosity, why you prefer "data_mapper" over "datamapper"?
Vit _______________________________________________ ruby-sig mailing list ruby-sig@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Hello everyone,
Continuing on this topic..
I am having severe trouble migrating this (and likely all of its other sub rubygem packages)
Here is SRPM: http://fedorapeople.org/~spstarr/packages/rubygem-dm- core-1.1.0-1.fc17.src.rpm
- I renamed all the _spec.rb files accordingly - i attempted to fix spec_helper.rb that helped a bit also
It then started to run with 'rspec spec' but still reported more deprecated
[spstarr@segfault dm-core-1.1.0]$ rspec spec/ ........***************************************************************** DEPRECATION WARNING: you are using a deprecated constant that will be removed from a future version of RSpec.
/usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example_group.rb:435:in `instance_eval'
* Spec is deprecated. * RSpec is the new top-level module in RSpec-2 *****************************************************************
.....
.**.........*..*...................*....*.......***************************************************************** DEPRECATION WARNING: you are using a deprecated constant that will be removed from a future version of RSpec.
/usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example_group.rb:435:in `instance_eval'
* Spec is deprecated. * RSpec is the new top-level module in RSpec-2 *****************************************************************
Pending: DataMapper::Query#intersection with default adapter with other matching everything should factor out the operation matching everything # TODO: compress Query#conditions for proper comparison # DataMapper::Query#& with default adapter with other matching everything should factor out the operation matching everything # TODO: compress Query#conditions for proper comparison # DataMapper::Query#slice with a negative offset should update the offset to be relative to the original offset # TODO: update Query#slice handle negative offset
.....
Failures:
1) DataMapper::Resource::State::Dirty#delete with default adapter it should behave like It resets resource state should reset the dirty m:1 relationship Failure/Error: method(:subject).should change(@resource, :parent).from(@resource).to(nil) parent should have been changed to nil, but is now #<Author @id=1 @name="Jane Doe" @active=true @coding=true @parent_id=nil> Shared Example Group: "It resets resource state" called from # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/fail_with.rb:32:in `fail_with' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/handler.rb:21:in `handle_matcher' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/extensions/kernel.rb:12:in `should' # /home/spstarr/rpmbuild/BUILD/rubygem-dm- core-1.1.0/usr/share/gems/gems/dm- core-1.1.0/spec/semipublic/shared/resource_state_shared.rb:27:in `block (2 levels) in <top (required)>' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `instance_eval' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:173:in `with_around_hooks' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:77:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:355:in `block in run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:337:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/reporter.rb:34:in `report' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:25:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:80:in `run_in_process' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:69:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:10:in `block in autorun'
2) DataMapper::Resource::State::Dirty#rollback with default adapter it should behave like It resets resource state should reset the dirty m:1 relationship Failure/Error: method(:subject).should change(@resource, :parent).from(@resource).to(nil) parent should have been changed to nil, but is now #<Author @id=1 @name="Jane Doe" @active=true @coding=true @parent_id=nil> Shared Example Group: "It resets resource state" called from # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/fail_with.rb:32:in `fail_with' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/handler.rb:21:in `handle_matcher' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/extensions/kernel.rb:12:in `should' # /home/spstarr/rpmbuild/BUILD/rubygem-dm- core-1.1.0/usr/share/gems/gems/dm- core-1.1.0/spec/semipublic/shared/resource_state_shared.rb:27:in `block (2 levels) in <top (required)>' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `instance_eval' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:173:in `with_around_hooks' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:77:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:355:in `block in run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:337:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/reporter.rb:34:in `report' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:25:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:80:in `run_in_process' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:69:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:10:in `block in autorun'
.......
This one is over my head, if someone can help that would be great, then i can replicate this knowledge to the other rubygems im working on also.
Thanks,
Shawn.
Dne 10.2.2012 07:55, Shawn Starr napsal(a):
Hello everyone,
Continuing on this topic..
I am having severe trouble migrating this (and likely all of its other sub rubygem packages)
Here is SRPM: http://fedorapeople.org/~spstarr/packages/rubygem-dm- core-1.1.0-1.fc17.src.rpm
- I renamed all the _spec.rb files accordingly
- i attempted to fix spec_helper.rb that helped a bit also
It then started to run with 'rspec spec' but still reported more deprecated
[spstarr@segfault dm-core-1.1.0]$ rspec spec/ ........***************************************************************** DEPRECATION WARNING: you are using a deprecated constant that will be removed from a future version of RSpec.
/usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example_group.rb:435:in `instance_eval'
- Spec is deprecated.
- RSpec is the new top-level module in RSpec-2
.....
.**.........*..*...................*....*.......***************************************************************** DEPRECATION WARNING: you are using a deprecated constant that will be removed from a future version of RSpec.
/usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example_group.rb:435:in `instance_eval'
- Spec is deprecated.
- RSpec is the new top-level module in RSpec-2
Pending: DataMapper::Query#intersection with default adapter with other matching everything should factor out the operation matching everything # TODO: compress Query#conditions for proper comparison # DataMapper::Query#& with default adapter with other matching everything should factor out the operation matching everything # TODO: compress Query#conditions for proper comparison # DataMapper::Query#slice with a negative offset should update the offset to be relative to the original offset # TODO: update Query#slice handle negative offset
.....
Failures:
- DataMapper::Resource::State::Dirty#delete with default adapter it should
behave like It resets resource state should reset the dirty m:1 relationship Failure/Error: method(:subject).should change(@resource, :parent).from(@resource).to(nil) parent should have been changed to nil, but is now #<Author @id=1 @name="Jane Doe" @active=true @coding=true @parent_id=nil> Shared Example Group: "It resets resource state" called from # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/fail_with.rb:32:in `fail_with' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/handler.rb:21:in `handle_matcher' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/extensions/kernel.rb:12:in `should' # /home/spstarr/rpmbuild/BUILD/rubygem-dm- core-1.1.0/usr/share/gems/gems/dm- core-1.1.0/spec/semipublic/shared/resource_state_shared.rb:27:in `block (2 levels) in<top (required)>' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `instance_eval' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:173:in `with_around_hooks' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:77:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:355:in `block in run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:337:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/reporter.rb:34:in `report' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:25:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:80:in `run_in_process' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:69:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:10:in `block in autorun'
- DataMapper::Resource::State::Dirty#rollback with default adapter it
should behave like It resets resource state should reset the dirty m:1 relationship Failure/Error: method(:subject).should change(@resource, :parent).from(@resource).to(nil) parent should have been changed to nil, but is now #<Author @id=1 @name="Jane Doe" @active=true @coding=true @parent_id=nil> Shared Example Group: "It resets resource state" called from # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/fail_with.rb:32:in `fail_with' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/handler.rb:21:in `handle_matcher' # /usr/share/gems/gems/rspec- expectations-2.8.0/lib/rspec/expectations/extensions/kernel.rb:12:in `should' # /home/spstarr/rpmbuild/BUILD/rubygem-dm- core-1.1.0/usr/share/gems/gems/dm- core-1.1.0/spec/semipublic/shared/resource_state_shared.rb:27:in `block (2 levels) in<top (required)>' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `instance_eval' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:80:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:173:in `with_around_hooks' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/example.rb:77:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:355:in `block in run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:351:in `run_examples' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:337:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `block in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/example_group.rb:338:in `run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block (2 levels) in run' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `map' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:28:in `block in run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/reporter.rb:34:in `report' # /usr/share/gems/gems/rspec- core-2.8.0/lib/rspec/core/command_line.rb:25:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:80:in `run_in_process' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:69:in `run' # /usr/share/gems/gems/rspec-core-2.8.0/lib/rspec/core/runner.rb:10:in `block in autorun'
.......
This one is over my head, if someone can help that would be great, then i can replicate this knowledge to the other rubygems im working on also.
Thanks,
Shawn.
Have you tried newer version of dm-core? Although I don't believe it will help :/
This shared examples feature was substantially reworked between RSpec 1 and 2. I consider it the biggest change and unfortunately hard to migrate, unless you are really familiar with the code and test suite.
I'm still not sure if we should not introduce some rspec compat package because of packages like this.
Anyway, I opened upstream issue regarding the RSpec 2.x support [1].
Vit
ruby-sig@lists.fedoraproject.org