12:01 p.m.
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
2:39 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(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
_______________________________________________
ruby-sig mailing list
ruby-sig(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
9:43 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)redhat.com> wrote:
From: Vít Ondruch <vondruch(a)redhat.com>
Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
To: ruby-sig(a)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(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
> _______________________________________________
> 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
10:35 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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 Ondruch<vondruch(a)redhat.com> wrote:
> From: Vít Ondruch<vondruch(a)redhat.com>
> Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
> To: ruby-sig(a)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(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
>> _______________________________________________
>> 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:03 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)redhat.com> wrote:
From: Vít Ondruch <vondruch(a)redhat.com>
Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
To: ruby-sig(a)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 Ondruch<vondruch(a)redhat.com>
wrote:
>
>> From: Vít Ondruch<vondruch(a)redhat.com>
>> Subject: Re: Migration from RSpec 1.3 to RSpec
2.x
>> To: ruby-sig(a)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(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
>>>
_______________________________________________
>>> 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
7:17 p.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starr <shawn.starr(a)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.
7:21 p.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
1:15 p.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)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(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
3:48 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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
Starr<shawn.starr(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
2:04 a.m.
New subject: 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
2:08 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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
2:25 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
Actually there are available both gems, datamapper as well as
data_mapper ...
Vit
2:53 a.m.
New subject: 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 ...
3:05 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
3:15 a.m.
New subject: datamapper vs data_mapper
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(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
10:24 a.m.
New subject: 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(a)redhat.com>
To: Ruby SIG mailing list <ruby-sig(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
10:31 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)rogers.com>
To: Ruby SIG mailing list <ruby-sig(a)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(a)redhat.com>
To: Ruby SIG mailing list <ruby-sig(a)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(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
10:18 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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(a)redhat.com>
To: ruby-sig(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
12:55 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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.
3:25 a.m.
New subject: Migration from RSpec 1.3 to RSpec 2.x
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:
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.
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
[1] https://github.com/datamapper/dm-core/issues/181
4458
days inactive
4658
days old
ruby-sig@lists.fedoraproject.org
19 comments
4 participants
participants (4)
-
Marek Goldmann -
Michael Stahnke -
Shawn Starr -
Vít Ondruch