Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 27.2.2012 14:43, Bohuslav Kabrda napsal(a):

- Original Message -

- Original Message -

- Original Message -

Dne 20.2.2012 13:31, Mo Morsi napsal(a):

On 02/20/2012 07:20 AM, Vít Ondruch wrote:

Dne 20.2.2012 12:45, Mo Morsi napsal(a):

Thank you. Unfortunately you do not solve how to migrate
from
BR:
rubygem(rspec-core) back to BR: rubygem(rspec). The main
issue
is
that rubygem-rspec-core was patched to carry rspec
executable,
where
now it should be moved where it belongs, i.e. into
rubygem-rspec.
There are several ways:

Huh? In the upstream gem, the 'rspec' executable is provided
by
rspec-core [1]. The upstream rspec gem [2] is merely a
metapackage
for
the three rspec subpackages (core, mock, expectations), and
I'm
not
seeing the aforementioned patch in the rubygem-rspec-core
spec
file
[3] (the 'rspec' binary is just pulled in from the upstream
gem).
Why
would we want to deviate from this?

Ah, sorry, you are right. I was probably confused by the
"lib/rspec.rb"
hack in rubygem-rspec-core which should be removed then. But in
what
point in time?




1) We can let temporarily rubygem-rspec provide also the
rubygem(rspec-core), where rubygem-rspec-core would not
provide
any
rubygem() macro. This is ugly and against guidelines.

2) Temporarily make rubygem-rspec-core dependent on
  rubygem(rspec),
which is circular dependency.

Both of these workarounds would be removed for Fedora>= 18,
but
all
the gems which uses rubygem(rspec-core) needs to be rebuild.
We
can
also fake the rubygem-rspec (e.g. there would be nothing
else
than
R:
rubygem(rspec-core), so new/updated packages could be fixed)
and
do
it properly for F18, including rebuild of packages.

Wouldn't it just work (tm) and be standards compliant w/ my
patch
as
it is? If so why don't we go w/ the simplest route for the
time
being
and then can massage it / tighten it up when the ruby-sig
workload
lightens up.

Now when you made me realize that I was wrong, I think it
should
work,
except the possible collision with the "lib/rspec.rb" mentioned
above. I
need to take a look into this matter once more.



(though one thing I just realized that's missing from the
patch
is
explicit version requirements on the rspec subpackages, can
quickly
fix that before pushing)


Also, if the test suite is executed using rspec command, we
should
think if the guidelines should not recommend usage of BR:
/usr/bin/rspec instead of rubygem(rspec{,-core}). The
reasoning
is
that if we run the spec using rspec command, we really care
just
if
the rspec command is available, whoever it provides. We
don't
care
whether it is provided by rubygem-rspec or
rubygem-rspec-core.
In
contrary, if the spec suite is for some reason executed just
using
ruby, e.g. "ruby spec/my_spec.rb", in this case it should be
enough
to require rubygem(rspec-core) and the rspec executable
would
never
be installed, since it is not needed.

Sad that I did not realized this when I had done review for
mtasaka.
Yeah, hard way to learn something :)

Ah ya this is a good idea. No worries, we can adjust it at
somepoint
going forward.

It is good time before package guidelines gets accepted I
think.
Anybody
against this proposal?


Vit

I agree that BR:/usr/bin/rspec is right - and it will also draw
in
only the necessary dependencies. As for the runtime Requires, I
believe we should stick with what's written in the gemspec (if it
is
rspec, let it be rspec, if rspec-core, then rspec-core). This
way,
we can make sure that requiring gem doesn't break with "Could not
find rspec (= 2.8) amongst [...]" - that should probably be
mentioned in the guidelines too, so that someone doesn't do
Requires: /usr/bin/rspec.
And yes, we should make an explicit note to the guidelines, that
BR:/usr/bin/rspec is the right way to do things before they get
approved (and then slowly change this when updating the packages
that depend on rubygem(rspec-core)).

--
Regards,
Bohuslav "Slavek" Kabrda.

So here is my resume :) :
The /usr/bin/rspec dependency can be used most of the time, as the
rspec-core gem (that contains it) draws all the dependencies
(rspec-mocks, rspec-expectations) in by itself. The only thing that
it doesn't contain is the rspec/rspec.rb file, which is currently
created in our specfile. So, with the upstream version, everything
works fine if the specs don't "require 'rspec'". I'm really not
sure
why there have to be rspec and rspec-core gems, since the rspec gem
doesn't really do anything. I asked upstream, so let's wait what
they'll respond.
As a result, it is not always possible to rely on /usr/bin/rspec
without having it modified the way we do.

--
Regards,
Bohuslav "Slavek" Kabrda.

Yes, and the issue is at
https://github.com/rspec/rspec-core/issues/577.

--
Regards,
Bohuslav "Slavek" Kabrda.

So it seems after all, that /usr/bin/rspec is not a good idea. The explanation 
is given in the issue from my previous email. Basically, the rspec-core gem is 
meant to be able to also work with differe

Re: Migration from RSpec 1.3 to RSpec 2.x

[Bohuslav Kabrda]

> - Original Message -
> > - Original Message -
> > > - Original Message -
> > > > Dne 20.2.2012 13:31, Mo Morsi napsal(a):
> > > > > On 02/20/2012 07:20 AM, Vít Ondruch wrote:
> > > > >> Dne 20.2.2012 12:45, Mo Morsi napsal(a):
> > > > >>
> > > > >> Thank you. Unfortunately you do not solve how to migrate
> > > > >> from
> > > > >> BR:
> > > > >> rubygem(rspec-core) back to BR: rubygem(rspec). The main
> > > > >> issue
> > > > >> is
> > > > >> that rubygem-rspec-core was patched to carry rspec
> > > > >> executable,
> > > > >> where
> > > > >> now it should be moved where it belongs, i.e. into
> > > > >> rubygem-rspec.
> > > > >> There are several ways:
> > > > >
> > > > > Huh? In the upstream gem, the 'rspec' executable is provided
> > > > > by
> > > > > rspec-core [1]. The upstream rspec gem [2] is merely a
> > > > > metapackage
> > > > > for
> > > > > the three rspec subpackages (core, mock, expectations), and
> > > > > I'm
> > > > > not
> > > > > seeing the aforementioned patch in the rubygem-rspec-core
> > > > > spec
> > > > > file
> > > > > [3] (the 'rspec' binary is just pulled in from the upstream
> > > > > gem).
> > > > > Why
> > > > > would we want to deviate from this?
> > > >
> > > > Ah, sorry, you are right. I was probably confused by the
> > > > "lib/rspec.rb"
> > > > hack in rubygem-rspec-core which should be removed then. But in
> > > > what
> > > > point in time?
> > > >
> > > > >
> > > > >
> > > > >>
> > > > >> 1) We can let temporarily rubygem-rspec provide also the
> > > > >> rubygem(rspec-core), where rubygem-rspec-core would not
> > > > >> provide
> > > > >> any
> > > > >> rubygem() macro. This is ugly and against guidelines.
> > > > >>
> > > > >> 2) Temporarily make rubygem-rspec-core dependent on
> > > > >>  rubygem(rspec),
> > > > >> which is circular dependency.
> > > > >>
> > > > >> Both of these workarounds would be removed for Fedora >= 18,
> > > > >> but
> > > > >> all
> > > > >> the gems which uses rubygem(rspec-core) needs to be rebuild.
> > > > >> We
> > > > >> can
> > > > >> also fake the rubygem-rspec (e.g. there would be nothing
> > > > >> else
> > > > >> than
> > > > >> R:
> > > > >> rubygem(rspec-core), so new/updated packages could be fixed)
> > > > >> and
> > > > >> do
> > > > >> it properly for F18, including rebuild of packages.
> > > > >
> > > > > Wouldn't it just work (tm) and be standards compliant w/ my
> > > > > patch
> > > > > as
> > > > > it is? If so why don't we go w/ the simplest route for the
> > > > > time
> > > > > being
> > > > > and then can massage it / tighten it up when the ruby-sig
> > > > > workload
> > > > > lightens up.
> > > >
> > > > Now when you made me realize that I was wrong, I think it
> > > > should
> > > > work,
> > > > except the possible collision with the "lib/rspec.rb" mentioned
> > > > above. I
> > > > need to take a look into this matter once more.
> > > >
> > > > >
> > > > >
> > > > > (though one thing I just realized that's missing from the
> > > > > patch
> > > > > is
> > > > > explicit version requirements on the rspec subpackages, can
> > > > > quickly
> > > > > fix that before pushing)
> > > > >
> > > > >>
> > > > >> Also, if the test suite is executed using rspec command, we
> > > > >> should
> > > > >> think if the guidelines should not recommend usage of BR:
> > > > >> /usr/bin/rspec instead of rubygem(rspec{,-core}). The
> > > > >> reasoning
> > > > >> is
> > > > >> that if we run the spec using rspec command, we really care
> > > > >> just
> > > > >> if
> > > > >> the rspec command is available, whoever it provides. We
> > > > >> don't
> > > > >> care
> > > > >> whether it is provided by rubygem-rspec or
> > > > >> rubygem-rspec-core.
> > > > >> In
> > > > >> contrary, if the spec suite is for some reason executed just
> > > > >> using
> > > > >> ruby, e.g. "ruby spec/my_spec.rb", in this case it should be
> > > > >> enough
> > > > >> to require rubygem(rspec-core) and the rspec executable
> > > > >> would
> > > > >> never
> > > > >> be installed, since it is not needed.
> > > > >>
> > > > >> Sad that I did not realized this when I had done review for
> > > > >> mtasaka.
> > > > >> Yeah, hard way to learn something :)
> > > > >
> > > > > Ah ya this is a good idea. No worries, we can adjust it at
> > > > > somepoint
> > > > > going forward.
> > > >
> > > > It is good time before package guidelines gets accepted I
> > > > think.
> > > > Anybody
> > > > against this proposal?
> > > >
> > > >
> > > > Vit
> > >
> > > I agree that BR:/usr/bin/rspec is right - and it will also draw
> > > in
> > > only the necessary dependencies. As for the runtime Requires, I
> > > believe we should stick with what's written in the gemspec (if it
> > > is
> > > rspec, let it be rspec, if rspec-core, then rspec-core). This
> > > way,
> > > we can make sure that requiring gem doesn't break with "Could not
> > > find rspec (= 2.8) amongst [...]" - that should probably be
> > > mentioned in the guidelines too, so that so

Re: Migration from RSpec 1.3 to RSpec 2.x

[Bohuslav Kabrda]

- Original Message -
> - Original Message -
> > - Original Message -
> > > Dne 20.2.2012 13:31, Mo Morsi napsal(a):
> > > > On 02/20/2012 07:20 AM, Vít Ondruch wrote:
> > > >> Dne 20.2.2012 12:45, Mo Morsi napsal(a):
> > > >>
> > > >> Thank you. Unfortunately you do not solve how to migrate from
> > > >> BR:
> > > >> rubygem(rspec-core) back to BR: rubygem(rspec). The main issue
> > > >> is
> > > >> that rubygem-rspec-core was patched to carry rspec executable,
> > > >> where
> > > >> now it should be moved where it belongs, i.e. into
> > > >> rubygem-rspec.
> > > >> There are several ways:
> > > >
> > > > Huh? In the upstream gem, the 'rspec' executable is provided by
> > > > rspec-core [1]. The upstream rspec gem [2] is merely a
> > > > metapackage
> > > > for
> > > > the three rspec subpackages (core, mock, expectations), and I'm
> > > > not
> > > > seeing the aforementioned patch in the rubygem-rspec-core spec
> > > > file
> > > > [3] (the 'rspec' binary is just pulled in from the upstream
> > > > gem).
> > > > Why
> > > > would we want to deviate from this?
> > > 
> > > Ah, sorry, you are right. I was probably confused by the
> > > "lib/rspec.rb"
> > > hack in rubygem-rspec-core which should be removed then. But in
> > > what
> > > point in time?
> > > 
> > > >
> > > >
> > > >>
> > > >> 1) We can let temporarily rubygem-rspec provide also the
> > > >> rubygem(rspec-core), where rubygem-rspec-core would not
> > > >> provide
> > > >> any
> > > >> rubygem() macro. This is ugly and against guidelines.
> > > >>
> > > >> 2) Temporarily make rubygem-rspec-core dependent on
> > > >>  rubygem(rspec),
> > > >> which is circular dependency.
> > > >>
> > > >> Both of these workarounds would be removed for Fedora >= 18,
> > > >> but
> > > >> all
> > > >> the gems which uses rubygem(rspec-core) needs to be rebuild.
> > > >> We
> > > >> can
> > > >> also fake the rubygem-rspec (e.g. there would be nothing else
> > > >> than
> > > >> R:
> > > >> rubygem(rspec-core), so new/updated packages could be fixed)
> > > >> and
> > > >> do
> > > >> it properly for F18, including rebuild of packages.
> > > >
> > > > Wouldn't it just work (tm) and be standards compliant w/ my
> > > > patch
> > > > as
> > > > it is? If so why don't we go w/ the simplest route for the time
> > > > being
> > > > and then can massage it / tighten it up when the ruby-sig
> > > > workload
> > > > lightens up.
> > > 
> > > Now when you made me realize that I was wrong, I think it should
> > > work,
> > > except the possible collision with the "lib/rspec.rb" mentioned
> > > above. I
> > > need to take a look into this matter once more.
> > > 
> > > >
> > > >
> > > > (though one thing I just realized that's missing from the patch
> > > > is
> > > > explicit version requirements on the rspec subpackages, can
> > > > quickly
> > > > fix that before pushing)
> > > >
> > > >>
> > > >> Also, if the test suite is executed using rspec command, we
> > > >> should
> > > >> think if the guidelines should not recommend usage of BR:
> > > >> /usr/bin/rspec instead of rubygem(rspec{,-core}). The
> > > >> reasoning
> > > >> is
> > > >> that if we run the spec using rspec command, we really care
> > > >> just
> > > >> if
> > > >> the rspec command is available, whoever it provides. We don't
> > > >> care
> > > >> whether it is provided by rubygem-rspec or rubygem-rspec-core.
> > > >> In
> > > >> contrary, if the spec suite is for some reason executed just
> > > >> using
> > > >> ruby, e.g. "ruby spec/my_spec.rb", in this case it should be
> > > >> enough
> > > >> to require rubygem(rspec-core) and the rspec executable would
> > > >> never
> > > >> be installed, since it is not needed.
> > > >>
> > > >> Sad that I did not realized this when I had done review for
> > > >> mtasaka.
> > > >> Yeah, hard way to learn something :)
> > > >
> > > > Ah ya this is a good idea. No worries, we can adjust it at
> > > > somepoint
> > > > going forward.
> > > 
> > > It is good time before package guidelines gets accepted I think.
> > > Anybody
> > > against this proposal?
> > > 
> > > 
> > > Vit
> > 
> > I agree that BR:/usr/bin/rspec is right - and it will also draw in
> > only the necessary dependencies. As for the runtime Requires, I
> > believe we should stick with what's written in the gemspec (if it
> > is
> > rspec, let it be rspec, if rspec-core, then rspec-core). This way,
> > we can make sure that requiring gem doesn't break with "Could not
> > find rspec (= 2.8) amongst [...]" - that should probably be
> > mentioned in the guidelines too, so that someone doesn't do
> > Requires: /usr/bin/rspec.
> > And yes, we should make an explicit note to the guidelines, that
> > BR:/usr/bin/rspec is the right way to do things before they get
> > approved (and then slowly change this when updating the packages
> > that depend on rubygem(rspec-core)).
> > 
> > --
> > Regards,
> > Bohuslav "Slavek" Kabrda.
> 
> So here is my resume :) :
> The /usr/bin/rspec dependen

Re: Migration from RSpec 1.3 to RSpec 2.x

[Bohuslav Kabrda]

- Original Message -
> - Original Message -
> > Dne 20.2.2012 13:31, Mo Morsi napsal(a):
> > > On 02/20/2012 07:20 AM, Vít Ondruch wrote:
> > >> Dne 20.2.2012 12:45, Mo Morsi napsal(a):
> > >>
> > >> Thank you. Unfortunately you do not solve how to migrate from
> > >> BR:
> > >> rubygem(rspec-core) back to BR: rubygem(rspec). The main issue
> > >> is
> > >> that rubygem-rspec-core was patched to carry rspec executable,
> > >> where
> > >> now it should be moved where it belongs, i.e. into
> > >> rubygem-rspec.
> > >> There are several ways:
> > >
> > > Huh? In the upstream gem, the 'rspec' executable is provided by
> > > rspec-core [1]. The upstream rspec gem [2] is merely a
> > > metapackage
> > > for
> > > the three rspec subpackages (core, mock, expectations), and I'm
> > > not
> > > seeing the aforementioned patch in the rubygem-rspec-core spec
> > > file
> > > [3] (the 'rspec' binary is just pulled in from the upstream gem).
> > > Why
> > > would we want to deviate from this?
> > 
> > Ah, sorry, you are right. I was probably confused by the
> > "lib/rspec.rb"
> > hack in rubygem-rspec-core which should be removed then. But in
> > what
> > point in time?
> > 
> > >
> > >
> > >>
> > >> 1) We can let temporarily rubygem-rspec provide also the
> > >> rubygem(rspec-core), where rubygem-rspec-core would not provide
> > >> any
> > >> rubygem() macro. This is ugly and against guidelines.
> > >>
> > >> 2) Temporarily make rubygem-rspec-core dependent on
> > >>  rubygem(rspec),
> > >> which is circular dependency.
> > >>
> > >> Both of these workarounds would be removed for Fedora >= 18, but
> > >> all
> > >> the gems which uses rubygem(rspec-core) needs to be rebuild. We
> > >> can
> > >> also fake the rubygem-rspec (e.g. there would be nothing else
> > >> than
> > >> R:
> > >> rubygem(rspec-core), so new/updated packages could be fixed) and
> > >> do
> > >> it properly for F18, including rebuild of packages.
> > >
> > > Wouldn't it just work (tm) and be standards compliant w/ my patch
> > > as
> > > it is? If so why don't we go w/ the simplest route for the time
> > > being
> > > and then can massage it / tighten it up when the ruby-sig
> > > workload
> > > lightens up.
> > 
> > Now when you made me realize that I was wrong, I think it should
> > work,
> > except the possible collision with the "lib/rspec.rb" mentioned
> > above. I
> > need to take a look into this matter once more.
> > 
> > >
> > >
> > > (though one thing I just realized that's missing from the patch
> > > is
> > > explicit version requirements on the rspec subpackages, can
> > > quickly
> > > fix that before pushing)
> > >
> > >>
> > >> Also, if the test suite is executed using rspec command, we
> > >> should
> > >> think if the guidelines should not recommend usage of BR:
> > >> /usr/bin/rspec instead of rubygem(rspec{,-core}). The reasoning
> > >> is
> > >> that if we run the spec using rspec command, we really care just
> > >> if
> > >> the rspec command is available, whoever it provides. We don't
> > >> care
> > >> whether it is provided by rubygem-rspec or rubygem-rspec-core.
> > >> In
> > >> contrary, if the spec suite is for some reason executed just
> > >> using
> > >> ruby, e.g. "ruby spec/my_spec.rb", in this case it should be
> > >> enough
> > >> to require rubygem(rspec-core) and the rspec executable would
> > >> never
> > >> be installed, since it is not needed.
> > >>
> > >> Sad that I did not realized this when I had done review for
> > >> mtasaka.
> > >> Yeah, hard way to learn something :)
> > >
> > > Ah ya this is a good idea. No worries, we can adjust it at
> > > somepoint
> > > going forward.
> > 
> > It is good time before package guidelines gets accepted I think.
> > Anybody
> > against this proposal?
> > 
> > 
> > Vit
> 
> I agree that BR:/usr/bin/rspec is right - and it will also draw in
> only the necessary dependencies. As for the runtime Requires, I
> believe we should stick with what's written in the gemspec (if it is
> rspec, let it be rspec, if rspec-core, then rspec-core). This way,
> we can make sure that requiring gem doesn't break with "Could not
> find rspec (= 2.8) amongst [...]" - that should probably be
> mentioned in the guidelines too, so that someone doesn't do
> Requires: /usr/bin/rspec.
> And yes, we should make an explicit note to the guidelines, that
> BR:/usr/bin/rspec is the right way to do things before they get
> approved (and then slowly change this when updating the packages
> that depend on rubygem(rspec-core)).
> 
> --
> Regards,
> Bohuslav "Slavek" Kabrda.

So here is my resume :) :
The /usr/bin/rspec dependency can be used most of the time, as the rspec-core 
gem (that contains it) draws all the dependencies (rspec-mocks, 
rspec-expectations) in by itself. The only thing that it doesn't contain is the 
rspec/rspec.rb file, which is currently created in our specfile. So, with the 
upstream version, everything works fine if the specs don't "require 'rspec'". 
I'm really no

Re: Migration from RSpec 1.3 to RSpec 2.x

[Bohuslav Kabrda]

- Original Message -
> Dne 20.2.2012 13:31, Mo Morsi napsal(a):
> > On 02/20/2012 07:20 AM, Vít Ondruch wrote:
> >> Dne 20.2.2012 12:45, Mo Morsi napsal(a):
> >>
> >> Thank you. Unfortunately you do not solve how to migrate from BR:
> >> rubygem(rspec-core) back to BR: rubygem(rspec). The main issue is
> >> that rubygem-rspec-core was patched to carry rspec executable,
> >> where
> >> now it should be moved where it belongs, i.e. into rubygem-rspec.
> >> There are several ways:
> >
> > Huh? In the upstream gem, the 'rspec' executable is provided by
> > rspec-core [1]. The upstream rspec gem [2] is merely a metapackage
> > for
> > the three rspec subpackages (core, mock, expectations), and I'm not
> > seeing the aforementioned patch in the rubygem-rspec-core spec file
> > [3] (the 'rspec' binary is just pulled in from the upstream gem).
> > Why
> > would we want to deviate from this?
> 
> Ah, sorry, you are right. I was probably confused by the
> "lib/rspec.rb"
> hack in rubygem-rspec-core which should be removed then. But in what
> point in time?
> 
> >
> >
> >>
> >> 1) We can let temporarily rubygem-rspec provide also the
> >> rubygem(rspec-core), where rubygem-rspec-core would not provide
> >> any
> >> rubygem() macro. This is ugly and against guidelines.
> >>
> >> 2) Temporarily make rubygem-rspec-core dependent on
> >>  rubygem(rspec),
> >> which is circular dependency.
> >>
> >> Both of these workarounds would be removed for Fedora >= 18, but
> >> all
> >> the gems which uses rubygem(rspec-core) needs to be rebuild. We
> >> can
> >> also fake the rubygem-rspec (e.g. there would be nothing else than
> >> R:
> >> rubygem(rspec-core), so new/updated packages could be fixed) and
> >> do
> >> it properly for F18, including rebuild of packages.
> >
> > Wouldn't it just work (tm) and be standards compliant w/ my patch
> > as
> > it is? If so why don't we go w/ the simplest route for the time
> > being
> > and then can massage it / tighten it up when the ruby-sig workload
> > lightens up.
> 
> Now when you made me realize that I was wrong, I think it should
> work,
> except the possible collision with the "lib/rspec.rb" mentioned
> above. I
> need to take a look into this matter once more.
> 
> >
> >
> > (though one thing I just realized that's missing from the patch is
> > explicit version requirements on the rspec subpackages, can quickly
> > fix that before pushing)
> >
> >>
> >> Also, if the test suite is executed using rspec command, we should
> >> think if the guidelines should not recommend usage of BR:
> >> /usr/bin/rspec instead of rubygem(rspec{,-core}). The reasoning is
> >> that if we run the spec using rspec command, we really care just
> >> if
> >> the rspec command is available, whoever it provides. We don't care
> >> whether it is provided by rubygem-rspec or rubygem-rspec-core. In
> >> contrary, if the spec suite is for some reason executed just using
> >> ruby, e.g. "ruby spec/my_spec.rb", in this case it should be
> >> enough
> >> to require rubygem(rspec-core) and the rspec executable would
> >> never
> >> be installed, since it is not needed.
> >>
> >> Sad that I did not realized this when I had done review for
> >> mtasaka.
> >> Yeah, hard way to learn something :)
> >
> > Ah ya this is a good idea. No worries, we can adjust it at
> > somepoint
> > going forward.
> 
> It is good time before package guidelines gets accepted I think.
> Anybody
> against this proposal?
> 
> 
> Vit

I agree that BR:/usr/bin/rspec is right - and it will also draw in only the 
necessary dependencies. As for the runtime Requires, I believe we should stick 
with what's written in the gemspec (if it is rspec, let it be rspec, if 
rspec-core, then rspec-core). This way, we can make sure that requiring gem 
doesn't break with "Could not find rspec (= 2.8) amongst [...]" - that should 
probably be mentioned in the guidelines too, so that someone doesn't do 
Requires: /usr/bin/rspec.
And yes, we should make an explicit note to the guidelines, that 
BR:/usr/bin/rspec is the right way to do things before they get approved (and 
then slowly change this when updating the packages that depend on 
rubygem(rspec-core)).

-- 
Regards,
Bohuslav "Slavek" Kabrda.
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 20.2.2012 13:31, Mo Morsi napsal(a):

On 02/20/2012 07:20 AM, Vít Ondruch wrote:

Dne 20.2.2012 12:45, Mo Morsi napsal(a):

Thank you. Unfortunately you do not solve how to migrate from BR: 
rubygem(rspec-core) back to BR: rubygem(rspec). The main issue is 
that rubygem-rspec-core was patched to carry rspec executable, where 
now it should be moved where it belongs, i.e. into rubygem-rspec. 
There are several ways:


Huh? In the upstream gem, the 'rspec' executable is provided by 
rspec-core [1]. The upstream rspec gem [2] is merely a metapackage for 
the three rspec subpackages (core, mock, expectations), and I'm not 
seeing the aforementioned patch in the rubygem-rspec-core spec file 
[3] (the 'rspec' binary is just pulled in from the upstream gem). Why 
would we want to deviate from this?


Ah, sorry, you are right. I was probably confused by the "lib/rspec.rb" 
hack in rubygem-rspec-core which should be removed then. But in what 
point in time?







1) We can let temporarily rubygem-rspec provide also the 
rubygem(rspec-core), where rubygem-rspec-core would not provide any 
rubygem() macro. This is ugly and against guidelines.


2) Temporarily make rubygem-rspec-core dependent on  rubygem(rspec), 
which is circular dependency.


Both of these workarounds would be removed for Fedora >= 18, but all 
the gems which uses rubygem(rspec-core) needs to be rebuild. We can 
also fake the rubygem-rspec (e.g. there would be nothing else than R: 
rubygem(rspec-core), so new/updated packages could be fixed) and do 
it properly for F18, including rebuild of packages.


Wouldn't it just work (tm) and be standards compliant w/ my patch as 
it is? If so why don't we go w/ the simplest route for the time being 
and then can massage it / tighten it up when the ruby-sig workload 
lightens up.


Now when you made me realize that I was wrong, I think it should work, 
except the possible collision with the "lib/rspec.rb" mentioned above. I 
need to take a look into this matter once more.





(though one thing I just realized that's missing from the patch is 
explicit version requirements on the rspec subpackages, can quickly 
fix that before pushing)




Also, if the test suite is executed using rspec command, we should 
think if the guidelines should not recommend usage of BR: 
/usr/bin/rspec instead of rubygem(rspec{,-core}). The reasoning is 
that if we run the spec using rspec command, we really care just if 
the rspec command is available, whoever it provides. We don't care 
whether it is provided by rubygem-rspec or rubygem-rspec-core. In 
contrary, if the spec suite is for some reason executed just using 
ruby, e.g. "ruby spec/my_spec.rb", in this case it should be enough 
to require rubygem(rspec-core) and the rspec executable would never 
be installed, since it is not needed.


Sad that I did not realized this when I had done review for mtasaka. 
Yeah, hard way to learn something :)


Ah ya this is a good idea. No worries, we can adjust it at somepoint 
going forward.


It is good time before package guidelines gets accepted I think. Anybody 
against this proposal?



Vit





  -Mo

[1] http://rubygems.org/downloads/rspec-core-2.8.0.gem
[2] http://rubygems.org/downloads/rspec-2.8.0.gem
[3] http://pkgs.fedoraproject.org/gitweb/?p=rubygem-rspec-core.git



___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

On 02/20/2012 07:20 AM, Vít Ondruch wrote:

Dne 20.2.2012 12:45, Mo Morsi napsal(a):

On 02/20/2012 04:33 AM, Vít Ondruch wrote:

Dne 13.2.2012 20:40, Mo Morsi napsal(a):

On 01/25/2012 04:46 AM, Vít Ondruch wrote:

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x 
compatible, it is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be 
issue running with RSpec 2.x, although I did not tested it.



Could we move forward and let the rubygem-rspec to follow the 
upstream RSpec version and Require: rubygem(rspec-core)?





+1, lets move forward with this. I'm in the process of updating the 
aeolus-conductor codebase to work against ruby 1.9.3 and will look 
into incorporating an update to rspec 2 into this.


Since linode, ffi, and daemon_controller have been taken care of 
and we've long announced the update to rspec2 in F17, lets perform 
the final cutover. If there are issues going forward, we can easily 
introduce a rspec1 compat package.


  -Mo



Mo,

You mentioned in the packaging discussion that you have prepared 
patches for rubygem-rspec to migrate them to RSpec 2.x, is that 
right? Could you share them with us?


Vit

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


Attached. All the packages which depend on rspec 1 have been taken 
care of except for rubygem-linode and aeolus-conductor (still in 
progress but should be finished soon).


Patch updates the package to ruby 1.9 and removes the majority of the 
contents, adding the dependencies on the 
rspec-{core|mock|expectations}, bringing it inline w/ the upstream gem.


  -Mo


Thank you. Unfortunately you do not solve how to migrate from BR: 
rubygem(rspec-core) back to BR: rubygem(rspec). The main issue is that 
rubygem-rspec-core was patched to carry rspec executable, where now it 
should be moved where it belongs, i.e. into rubygem-rspec. There are 
several ways:


Huh? In the upstream gem, the 'rspec' executable is provided by 
rspec-core [1]. The upstream rspec gem [2] is merely a metapackage for 
the three rspec subpackages (core, mock, expectations), and I'm not 
seeing the aforementioned patch in the rubygem-rspec-core spec file [3] 
(the 'rspec' binary is just pulled in from the upstream gem). Why would 
we want to deviate from this?





1) We can let temporarily rubygem-rspec provide also the 
rubygem(rspec-core), where rubygem-rspec-core would not provide any 
rubygem() macro. This is ugly and against guidelines.


2) Temporarily make rubygem-rspec-core dependent on  rubygem(rspec), 
which is circular dependency.


Both of these workarounds would be removed for Fedora >= 18, but all 
the gems which uses rubygem(rspec-core) needs to be rebuild. We can 
also fake the rubygem-rspec (e.g. there would be nothing else than R: 
rubygem(rspec-core), so new/updated packages could be fixed) and do it 
properly for F18, including rebuild of packages.


Wouldn't it just work (tm) and be standards compliant w/ my patch as it 
is? If so why don't we go w/ the simplest route for the time being and 
then can massage it / tighten it up when the ruby-sig workload lightens up.


(though one thing I just realized that's missing from the patch is 
explicit version requirements on the rspec subpackages, can quickly fix 
that before pushing)




Also, if the test suite is executed using rspec command, we should 
think if the guidelines should not recommend usage of BR: 
/usr/bin/rspec instead of rubygem(rspec{,-core}). The reasoning is 
that if we run the spec using rspec command, we really care just if 
the rspec command is available, whoever it provides. We don't care 
whether it is provided by rubygem-rspec or rubygem-rspec-core. In 
contrary, if the spec suite is for some reason executed just using 
ruby, e.g. "ruby spec/my_spec.rb", in this case it should be enough to 
require rubygem(rspec-core) and the rspec executable would never be 
installed, since it is not needed.


Sad that I did not realized this when I had done review for mtasaka. 
Yeah, hard way to learn something :)


Ah ya this is a 

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 20.2.2012 12:45, Mo Morsi napsal(a):

On 02/20/2012 04:33 AM, Vít Ondruch wrote:

Dne 13.2.2012 20:40, Mo Morsi napsal(a):

On 01/25/2012 04:46 AM, Vít Ondruch wrote:

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x 
compatible, it is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be 
issue running with RSpec 2.x, although I did not tested it.



Could we move forward and let the rubygem-rspec to follow the 
upstream RSpec version and Require: rubygem(rspec-core)?





+1, lets move forward with this. I'm in the process of updating the 
aeolus-conductor codebase to work against ruby 1.9.3 and will look 
into incorporating an update to rspec 2 into this.


Since linode, ffi, and daemon_controller have been taken care of and 
we've long announced the update to rspec2 in F17, lets perform the 
final cutover. If there are issues going forward, we can easily 
introduce a rspec1 compat package.


  -Mo



Mo,

You mentioned in the packaging discussion that you have prepared 
patches for rubygem-rspec to migrate them to RSpec 2.x, is that 
right? Could you share them with us?


Vit

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


Attached. All the packages which depend on rspec 1 have been taken 
care of except for rubygem-linode and aeolus-conductor (still in 
progress but should be finished soon).


Patch updates the package to ruby 1.9 and removes the majority of the 
contents, adding the dependencies on the 
rspec-{core|mock|expectations}, bringing it inline w/ the upstream gem.


  -Mo


Thank you. Unfortunately you do not solve how to migrate from BR: 
rubygem(rspec-core) back to BR: rubygem(rspec). The main issue is that 
rubygem-rspec-core was patched to carry rspec executable, where now it 
should be moved where it belongs, i.e. into rubygem-rspec. There are 
several ways:


1) We can let temporarily rubygem-rspec provide also the 
rubygem(rspec-core), where rubygem-rspec-core would not provide any 
rubygem() macro. This is ugly and against guidelines.


2) Temporarily make rubygem-rspec-core dependent on  rubygem(rspec), 
which is circular dependency.


Both of these workarounds would be removed for Fedora >= 18, but all the 
gems which uses rubygem(rspec-core) needs to be rebuild. We can also 
fake the rubygem-rspec (e.g. there would be nothing else than R: 
rubygem(rspec-core), so new/updated packages could be fixed) and do it 
properly for F18, including rebuild of packages.


Also, if the test suite is executed using rspec command, we should think 
if the guidelines should not recommend usage of BR: /usr/bin/rspec 
instead of rubygem(rspec{,-core}). The reasoning is that if we run the 
spec using rspec command, we really care just if the rspec command is 
available, whoever it provides. We don't care whether it is provided by 
rubygem-rspec or rubygem-rspec-core. In contrary, if the spec suite is 
for some reason executed just using ruby, e.g. "ruby spec/my_spec.rb", 
in this case it should be enough to require rubygem(rspec-core) and the 
rspec executable would never be installed, since it is not needed.


Sad that I did not realized this when I had done review for mtasaka. 
Yeah, hard way to learn something :)



Vit


Vit
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

On 02/20/2012 04:33 AM, Vít Ondruch wrote:

Dne 13.2.2012 20:40, Mo Morsi napsal(a):

On 01/25/2012 04:46 AM, Vít Ondruch wrote:

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, 
it is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be issue 
running with RSpec 2.x, although I did not tested it.



Could we move forward and let the rubygem-rspec to follow the 
upstream RSpec version and Require: rubygem(rspec-core)?





+1, lets move forward with this. I'm in the process of updating the 
aeolus-conductor codebase to work against ruby 1.9.3 and will look 
into incorporating an update to rspec 2 into this.


Since linode, ffi, and daemon_controller have been taken care of and 
we've long announced the update to rspec2 in F17, lets perform the 
final cutover. If there are issues going forward, we can easily 
introduce a rspec1 compat package.


  -Mo



Mo,

You mentioned in the packaging discussion that you have prepared 
patches for rubygem-rspec to migrate them to RSpec 2.x, is that right? 
Could you share them with us?


Vit

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


Attached. All the packages which depend on rspec 1 have been taken care 
of except for rubygem-linode and aeolus-conductor (still in progress but 
should be finished soon).


Patch updates the package to ruby 1.9 and removes the majority of the 
contents, adding the dependencies on the rspec-{core|mock|expectations}, 
bringing it inline w/ the upstream gem.


  -Mo

From 9caabf94987b12a11130525706f648117ddf95a3 Mon Sep 17 00:00:00 2001
From: Mo Morsi 
Date: Tue, 14 Feb 2012 12:37:00 -0500
Subject: [PATCH] update to rspec2 (2.8.0), build against ruby 1.9

---
 .gitignore |1 +
 rubygem-rspec.spec |   60 ---
 sources|1 +
 3 files changed, 26 insertions(+), 36 deletions(-)

diff --git a/.gitignore b/.gitignore
index 1cfe10a..bcd3939 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 rspec-1.3.0.gem
 /rspec-1.3.1.gem
+/rspec-2.8.0.gem
diff --git a/rubygem-rspec.spec b/rubygem-rspec.spec
index e98bda1..b70575c 100644
--- a/rubygem-rspec.spec
+++ b/rubygem-rspec.spec
@@ -1,22 +1,22 @@
-%global ruby_sitelib %(ruby -rrbconfig -e "puts Config::CONFIG['sitelibdir']")
-%global gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null)
-%global gemname rspec
-%global geminstdir %{gemdir}/gems/%{gemname}-%{version}
+%global gem_name rspec
+%global rubyabi 1.9.1
 
 Summary: Behaviour driven development (BDD) framework for Ruby
-Name: rubygem-%{gemname}
-Version: 1.3.1
-Release: 2%{?dist}
+Name: rubygem-%{gem_name}
+Version: 2.8.0
+Release: 1%{?dist}
 Group: Development/Languages
 License: GPLv2+ or Ruby
 URL: http://rspec.info
-Source0: http://gems.rubyforge.org/gems/%{gemname}-%{version}.gem
-Patch0:  rubygem-rspec-1.3.1-RakeFileUtils_renamed_to_FileUtilsExt.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: rubygems, ruby(abi)  = 1.8
+Source0: http://rubygems.org/gems/%{gem_name}-%{version}.gem
+Requires: rubygems, ruby(abi)  = %{rubyabi}
+Requires: rubygem(rspec-core)
+Requires: rubygem(rspec-mocks)
+Requires: rubygem(rspec-expectations)
 BuildRequires: rubygems, ruby
+BuildRequires: rubygems-devel
 BuildArch: noarch
-Provides: rubygem(%{gemname}) = %{version}
+Provides: rubygem(%{gem_name}) = %{version}
 
 %description
 RSpec is a behaviour driven development (BDD) framework for Ruby.  
@@ -24,43 +24,31 @@ RSpec is a behaviour driven development (BDD) framework for 
Ruby.
 
 %prep
 %setup -q -c -T
-gem install \
-   -V \
-   --install-dir $(pwd)%{gemdir} \
-   --bindir $(pwd)%{_bindir} \
+gem install --local -V \
+   --install-dir .%{gem_dir} \
--force \
--rdoc \
%{SOURCE0}
 
-
-pushd .%{geminstdir}
-%patch0 -p1
-popd
-
-find . -type f | xargs chmod ugo+r
-
 %build
 
 %install
-mkdir -p %{buildroot}%{gemdir}
-cp -a .%{_prefix}/* %{buildroot}%{_prefix}/
-
-find %{buildroot}%{geminstdir}/bin -type f | xargs chmod a+x
-

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 13.2.2012 20:40, Mo Morsi napsal(a):

On 01/25/2012 04:46 AM, Vít Ondruch wrote:

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, 
it is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be issue 
running with RSpec 2.x, although I did not tested it.



Could we move forward and let the rubygem-rspec to follow the 
upstream RSpec version and Require: rubygem(rspec-core)?





+1, lets move forward with this. I'm in the process of updating the 
aeolus-conductor codebase to work against ruby 1.9.3 and will look 
into incorporating an update to rspec 2 into this.


Since linode, ffi, and daemon_controller have been taken care of and 
we've long announced the update to rspec2 in F17, lets perform the 
final cutover. If there are issues going forward, we can easily 
introduce a rspec1 compat package.


  -Mo



Mo,

You mentioned in the packaging discussion that you have prepared patches 
for rubygem-rspec to migrate them to RSpec 2.x, is that right? Could you 
share them with us?


Vit

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

On 01/25/2012 04:46 AM, Vít Ondruch wrote:

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, 
it is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be issue 
running with RSpec 2.x, although I did not tested it.



Could we move forward and let the rubygem-rspec to follow the upstream 
RSpec version and Require: rubygem(rspec-core)?





+1, lets move forward with this. I'm in the process of updating the 
aeolus-conductor codebase to work against ruby 1.9.3 and will look into 
incorporating an update to rspec 2 into this.


Since linode, ffi, and daemon_controller have been taken care of and 
we've long announced the update to rspec2 in F17, lets perform the final 
cutover. If there are issues going forward, we can easily introduce a 
rspec1 compat package.


  -Mo

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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 #
  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'
  # /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/rs

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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 #
 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 '
 # /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'
  

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Hi guys,

It seems that we have almost eliminated usage of RSpec 1.x:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

rubygem-ffi-0:1.0.9-2.fc16.src
rubygem-linode-0:0.6.2-1.fc15.src

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-2.fc17.noarch

$ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
rubygem-daemon_controller-0:0.2.6-2.fc17.src

$ repoquery --repoid=rawhide --arch=src --whatrequires rubygem-rspec


The only remaining packages are:
rubygem-ffi (bkearney) - seems to be just packaging bug: 
https://bugzilla.redhat.com/show_bug.cgi?id=760009
rubygem-linode (stahnma) - upstream is already RSpec 2.x compatible, it 
is FTBFS currently and it would deserve update anyway
aeolus-conductor-devel (mmorsi, clalance, sseago) - Hm, are 
rubygem(rspec-rails) 2.6 compatible with RSpec 1.x? I doubt it ...
rubygem-daemon_controller (pwu) - It seems there should not be issue 
running with RSpec 2.x, although I did not tested it.



Could we move forward and let the rubygem-rspec to follow the upstream 
RSpec version and Require: rubygem(rspec-core)?



Vit

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 20.1.2012 22:55, Mo Morsi napsal(a):

On 01/12/2012 08:56 AM, Vít Ondruch wrote:

Hi guys,

There have been nice progress in this matter, nevertheless, there are 
still some packages which depends on RSpec 1.x:


$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)




Vit


___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


jruby has been updated to rspec 2 as of the following commit

http://pkgs.fedoraproject.org/gitweb/?p=jruby.git;a=commitdiff;h=8d0234eb2c1876c02a5e0fb618bd40fbf18f7e6a 



  -Mo
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


Thank you Mo!

I was afraid that JRuby might be blocker. Good to see that I was wrong.


Vit
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

On 01/12/2012 08:56 AM, Vít Ondruch wrote:

Hi guys,

There have been nice progress in this matter, nevertheless, there are 
still some packages which depends on RSpec 1.x:


$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
rubygem-rspec

rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)




Vit


___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig


jruby has been updated to rspec 2 as of the following commit

http://pkgs.fedoraproject.org/gitweb/?p=jruby.git;a=commitdiff;h=8d0234eb2c1876c02a5e0fb618bd40fbf18f7e6a

  -Mo
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Thank you. It seems that upstream version is using RSpec 2.x anyway, so 
it should be straight forward.


Vit


Dne 12.1.2012 18:53, Michael Stahnke napsal(a):

Linode is in a FTBFS state anyway, due to some httparty changes.

When I am able to fix linode, it will require rspec 2.x.

On Thu, Jan 12, 2012 at 5:56 AM, Vít Ondruch  wrote:

Hi guys,

There have been nice progress in this matter, nevertheless, there are still
some packages which depends on RSpec 1.x:


$ repoquery --repoid=rawhide-source --arch=src --whatrequires
'rubygem(rspec)'
deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)

rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)




Vit



___
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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Michael Stahnke]

Linode is in a FTBFS state anyway, due to some httparty changes.

When I am able to fix linode, it will require rspec 2.x.

On Thu, Jan 12, 2012 at 5:56 AM, Vít Ondruch  wrote:
> Hi guys,
>
> There have been nice progress in this matter, nevertheless, there are still
> some packages which depends on RSpec 1.x:
>
>
> $ repoquery --repoid=rawhide-source --arch=src --whatrequires
> 'rubygem(rspec)'
> deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
> jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
>
> rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
> rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
>
> $ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
> aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)
>
> $ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
> rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)
>
>
>
>
> Vit
>
>
>
> ___
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Hi guys,

There have been nice progress in this matter, nevertheless, there are 
still some packages which depends on RSpec 1.x:


$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'

deltacloud-core-0:0.4.1-6.fc17.src (mfojtik, clalance)
jruby-0:1.6.2-2.fc16.src (mmorsi, vondruch)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)

$ repoquery --repoid=rawhide --whatrequires 'rubygem(rspec)'
aeolus-conductor-devel-0:0.4.0-1.fc17.noarch (mmorsi, clalance, sseago)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires rubygem-rspec
rubygem-daemon_controller-0:0.2.6-1.fc16.src (pwu)




Vit


___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

On Friday, November 18, 2011 10:23:00 AM Vít Ondruch wrote:
> 
> Hi Shawn,
> 
> No we don't, but I can throw a few points here, what I am typically doing.
> 
> 1) Replace the BR: rubygem(rspec) => BR: rubygem(rspec-core). Typically
> I add above some comment like "# Use rspec-core until rspec are not
> migrated to RSpec 2.x" just to remember.
> 2) Use command "rspec spec/" in your check section. This typically
> replaces similar call for RSpec 1.x, which was "spec spec/"
> 3) Now you have to check that the test suite passes. If not, you have to
> make it compatible and submit patch upstream. Usually it is not required
> and it will just work. However sometime it needs more effort. Recent
> example might be rubygem-little-plugger [1]. You can see that the patch
> is very simple and was easily accepted by upstream.
> 
> Thats it. In the future, once all gems are RSpec 2.x ready, the
> rubygem-rspec package should be migrated from RSpec 1.x to RSpec 2.x and
> from that time, it will be possible to use again the rubygem(rspec)
> provider.
> 
> 
> Vit
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=754355

Thanks Vit, 

I'll use this guide for my OpenNebula rubygem dependencies I'll be working on 
this and next month.

Shawn

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 17.11.2011 00:55, Shawn Starr napsal(a):
> On Wednesday, November 16, 2011 10:48:22 AM Vít Ondruch wrote:
>> Hello everybody,
>>
>> Here is updated list of Rawhide packages which still depends on RSpec 1.3:
>>
> 
>
>> Vit
> Do we have a simple howto to convert to 2.0? Would make things easy for me to
> get my rubygems ready.
>
> Thanks,
> Shawn.
> ___
> ruby-sig mailing list
> ruby-sig@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Hi Shawn,

No we don't, but I can throw a few points here, what I am typically doing.

1) Replace the BR: rubygem(rspec) => BR: rubygem(rspec-core). Typically 
I add above some comment like "# Use rspec-core until rspec are not 
migrated to RSpec 2.x" just to remember.
2) Use command "rspec spec/" in your check section. This typically 
replaces similar call for RSpec 1.x, which was "spec spec/"
3) Now you have to check that the test suite passes. If not, you have to 
make it compatible and submit patch upstream. Usually it is not required 
and it will just work. However sometime it needs more effort. Recent 
example might be rubygem-little-plugger [1]. You can see that the patch 
is very simple and was easily accepted by upstream.

Thats it. In the future, once all gems are RSpec 2.x ready, the 
rubygem-rspec package should be migrated from RSpec 1.x to RSpec 2.x and 
from that time, it will be possible to use again the rubygem(rspec) 
provider.


Vit


[1] https://bugzilla.redhat.com/show_bug.cgi?id=754355
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

On Wednesday, November 16, 2011 10:48:22 AM Vít Ondruch wrote:
> Hello everybody,
> 
> Here is updated list of Rawhide packages which still depends on RSpec 1.3:
> 


> Vit

Do we have a simple howto to convert to 2.0? Would make things easy for me to 
get my rubygems ready.

Thanks,
Shawn.
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Hello everybody,

Here is updated list of Rawhide packages which still depends on RSpec 1.3:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires
'rubygem(rspec)'
deltacloud-core-0:0.3.0-11.fc16.src (mfojtik)
jruby-0:1.6.2-2.fc16.src (mmorsi)
rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
rubygem-little-plugger-0:1.1.2-3.fc17.src (bkabrda)
rubygem-multimap-0:1.1.2-3.fc15.src (mmorsi)
rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
rubygem-thin-0:1.2.11-3.fc16.src (mfojtik, clalance)
rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
rubygem-will_paginate-0:3.0-0.1.pre2.fc16.src (mfojtik, clalance, mmorsi)
rubygem-yard-0:0.7.2-1.fc16.src (mmorsi)

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)' | wc -l
17

Vit
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Hello everybody,

Here is updated list of Rawhide packages which still depends on RSpec 1.3:

$ repoquery --repoid=rawhide-source --arch=src --whatrequires 
'rubygem(rspec)'
deltacloud-core-0:0.3.0-11.fc16.src (mfojtik)
jruby-0:1.6.2-2.fc16.src (mmorsi)
rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
rubygem-boxgrinder-build-0:0.9.3-2.fc16.src (goldmann)
rubygem-boxgrinder-core-0:0.3.4-1.fc16.src (goldmann)
rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
rubygem-ffi-0:1.0.9-2.fc16.src (bkearney)
rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
rubygem-multimap-0:1.1.2-3.fc15.src (mmorsi)
rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
rubygem-thin-0:1.2.11-3.fc16.src (mfojtik, clalance)
rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
rubygem-will_paginate-0:3.0-0.1.pre2.fc16.src (mfojtik, clalance, mmorsi)
rubygem-yard-0:0.7.2-1.fc16.src (mmorsi)

Vit
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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  
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
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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 
To: Ruby SIG mailing list 
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 
To: Ruby SIG mailing list 
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

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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 
To: Ruby SIG mailing list 
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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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 
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

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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  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


--- rubygem-extlib.spec.orig2011-07-22 05:47:49.0 +0200
+++ rubygem-extlib.spec 2011-07-27 10:39:12.724799206 +0200
@@ -22,7 +22,8 @@
 Requires: ruby(abi) = %{rubyabi}
 BuildRequires: ruby(rubygems)
 BuildRequires: ruby(abi) = %{rubyabi}
-BuildRequires: rubygem(rake), rubygem(rspec), rubygem(yard), ruby(json)
+# Use rspec-core until rspec are not migrated to RSpec 2.x
+BuildRequires: rubygem(rake), rubygem(rspec-core), rubygem(yard), ruby(json)
 BuildArch: noarch
 Provides: rubygem(%{gemname}) = %{version}
 
@@ -136,7 +137,9 @@
 %check
 pushd .%{geminstdir}
 
-rake spec || true   
+sed -i -e 's|require "spec"|require "rspec"|' spec/spec_helper.rb
+
+rspec spec/
 rake yard -v --trace
 
 # Additional HTML documentation generated by yard
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

On Tuesday, July 26, 2011 05:17:54 PM Michael Stahnke wrote:
> On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starr  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
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Michael Stahnke]

On Tue, Jul 26, 2011 at 9:03 AM, Shawn Starr  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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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  wrote:

> From: Vít Ondruch 
> 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 Ondruch 
> wrote:
> >
> >> From: Vít Ondruch
> >> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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  wrote:
>
>> From: Vít Ondruch
>> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

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  wrote:

> From: Vít Ondruch 
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Shawn Starr]

Im about to submit whole bunch of rubygems to Fedora. Most of them use rspec 
1.3.

On Mon Jul 25th, 2011 10:10 AM EDT Mo Morsi wrote:

>Since this list is a lot shorter than the corresponding list in Fedora, 
>perhaps we can get these package maintainers to update to RSpec 2.
>
>Otherwise, perhaps we can leave it in there as there for now, push the 
>rspec-core and other subcomponents to EPEL, and update the BoxGrinder 
>RPM to depend on those subcomponents instead of rspec itself?
>
>   -Mo
>
>On 07/22/2011 09:18 AM, Marek Goldmann wrote:
>> For EPEL 6 - exactly 5:
>>
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> rubygem-extlib-0:0.9.13-5.el6.src
>> rubygem-facon-0:0.4.1-2.el6.src
>> rubygem-rack-test-0:0.5.4-1.el6.src
>> rubygem-thin-0:1.2.8-4.el6.src
>> rubygem-uuidtools-0:2.1.1-1.el6.src
>>
>> For EPEL 5 - also 5:
>>
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> rubygem-extlib-0:0.9.13-5.el5.src
>> rubygem-facon-0:0.4.1-2.el5.src
>> rubygem-linode-0:0.6.2-1.el5.src
>> rubygem-thin-0:1.2.8-2.el5.src
>> rubygem-uuidtools-0:2.1.1-2.el5.src
>>
>> --Marek
>>
>> On 22 lip 2011, at 09:48, Vít Ondruch wrote:
>>
>>> RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea
>>> how many packages depends on RSpec in EPEL?
>>>
>>>
>>> Vit
>>>
>>>
>>>
>>> Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
 There is one more thing:

 Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 
 6, but there is only RSpec 1.3. What would be the approach to bump RSpec 
 there?

 --Marek

 On 18 lip 2011, at 18:49, Mo Morsi wrote:

> Perhaps we can shoot for doing this w/ F17, and if we are unable to
> migrate all the dependent packages over, then add a rspec1 compat
> package to buy us some more time.
>
> In any case, would rather push this off to F17 myself as a few of us are
> going through and updating alot of the rails related plugins to be
> compatible w/ Rails 3 in Fedora. We're trying to get this done by the
> F16 deadline next week.
 --Marek

 ___
 ruby-sig mailing list
 ruby-sig@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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

> I'm cool with this! This would be same as current Fedora rawhide state. After 
> upgrading above packages we could bump rubygem-rspec to 2.x.
>
> Seems reasonable?
>
> --Marek
>

Sounds good to me.

   -Mo
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

Hiya,

On 25 lip 2011, at 16:10, 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.

We're talking here about:

rubygem-extlib-0:0.9.13-5.el6.src   (stahnma)
rubygem-facon-0:0.4.1-2.el6.src (stahnma)
rubygem-rack-test-0:0.5.4-1.el6.src (mfojtik)
rubygem-thin-0:1.2.8-4.el6.src  (mfojtik)
rubygem-uuidtools-0:2.1.1-1.el6.src (stahnma)

> 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?

I'm cool with this! This would be same as current Fedora rawhide state. After 
upgrading above packages we could bump rubygem-rspec to 2.x.

Seems reasonable?

--Marek

> 
>  -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
> 

--Marek

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

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.

  -Mo

On 07/18/2011 04:44 AM, Vít Ondruch wrote:
> rubygem-rspec1 package is of course one possibility, but I would be 
> happier if we never introduce such package. This package would be 
> introduced only for backward compatibility and people (developers) would 
> be never motivated to move forward. This is against one of Fedora Fs 
> (First).
> 
> The biggest problem with rubygem-rspec1 is that is has not defined its 
> lifespan and even if it has, there always be somebody requesting some 
> compatibility packages for whatever reason. I just tried to propose to 
> deprecate RSpec 1 for F17.
> 
> The time which would be spent on reviewing/maintaining the RSpec 1.x 
> package would be better spent by ensuring that all packages work with 
> RSpec 2.x and submitting patches upstream if necessary.
> 
> 
> Vit
> 
> 
> 
> Dne 18.7.2011 09:59, TASAKA Mamoru napsal(a):
>> Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
>>> Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
 Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>> Hi guys,
>>
>> Since February, there are available RSpec 2.x in Fedora repositories.
>> However, as of now, the main package rubygem-rspec was not migrated to
>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>> if we could finish the migration to RSpec 2.x lets say in F17 time
>> frame. What are your opinions? The list of packages which depends on
>> RSpec 1.3 is attached bellow.
>>
> IMO F17 seems like a reasonable timeline for this. At that point we
> might also want to provide a rubygem-rspec1-compat package for any gems
> whose upstream communities haven't switched over.
>
 Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
 before F-16/17 branch (i.e. 2011-07-26)?
>>> Is it worth of it? We can push the change right now, but it will make
>>> some packages FTBFS. Don't take me wrong, I personally +1 for this
>>> change, I just wanted to give a chance to others to be prepared.
>> With rubygem-rspec1 imported, I will change all packages which currently
>> have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild all those 
>> srpms.
>> If those srpm don't have FTBFS issue right now, they should also succeed on
>> building after this change (if they fail to build after this change, I guess
>> they already had FTBFS issue)
>>
 I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
 http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
 http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
 http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
 http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>>> Is the change in folder structure, i.e. rename from rspec to rspec1
>>> really necessary? The gems don't conflicts, so it seems to me too much
>>> effort for no benefit.
>> Well,
>> - We cannot have two "rubygem-rspec" srpm (on Fedora repository), so anyway
>> one of these should be renamed on srpm name level. With srpm renamed to
>> "rubygem-rspec1", I think reconstructuring directories and especially
>> changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less 
>> confusing
>> as it "matches" currently rubygem based rpms' structure
>> - Anyway I think we can agree with any of the ways.
>>
 With these rpms,
 - people who wants to use rspec 1 has to specify it as
   (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
   "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
 - people who want to use rspec 2 will specify it as
   (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
   /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.

 If we can agree with these changes, I will submit these specs/srpms for
 review requests.
>> Regards,
>> Mamoru
>>
>>
>> ___
>> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

rubygem-rspec1 package is of course one possibility, but I would be 
happier if we never introduce such package. This package would be 
introduced only for backward compatibility and people (developers) would 
be never motivated to move forward. This is against one of Fedora Fs 
(First).

The biggest problem with rubygem-rspec1 is that is has not defined its 
lifespan and even if it has, there always be somebody requesting some 
compatibility packages for whatever reason. I just tried to propose to 
deprecate RSpec 1 for F17.

The time which would be spent on reviewing/maintaining the RSpec 1.x 
package would be better spent by ensuring that all packages work with 
RSpec 2.x and submitting patches upstream if necessary.


Vit



Dne 18.7.2011 09:59, TASAKA Mamoru napsal(a):
> Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
>> Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
>>> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
 On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> Hi guys,
>
> Since February, there are available RSpec 2.x in Fedora repositories.
> However, as of now, the main package rubygem-rspec was not migrated to
> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> if we could finish the migration to RSpec 2.x lets say in F17 time
> frame. What are your opinions? The list of packages which depends on
> RSpec 1.3 is attached bellow.
>
 IMO F17 seems like a reasonable timeline for this. At that point we
 might also want to provide a rubygem-rspec1-compat package for any gems
 whose upstream communities haven't switched over.

>>> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
>>> before F-16/17 branch (i.e. 2011-07-26)?
>> Is it worth of it? We can push the change right now, but it will make
>> some packages FTBFS. Don't take me wrong, I personally +1 for this
>> change, I just wanted to give a chance to others to be prepared.
> With rubygem-rspec1 imported, I will change all packages which currently
> have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild all those 
> srpms.
> If those srpm don't have FTBFS issue right now, they should also succeed on
> building after this change (if they fail to build after this change, I guess
> they already had FTBFS issue)
>
>>> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
>>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>> Is the change in folder structure, i.e. rename from rspec to rspec1
>> really necessary? The gems don't conflicts, so it seems to me too much
>> effort for no benefit.
> Well,
> - We cannot have two "rubygem-rspec" srpm (on Fedora repository), so anyway
> one of these should be renamed on srpm name level. With srpm renamed to
> "rubygem-rspec1", I think reconstructuring directories and especially
> changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less confusing
> as it "matches" currently rubygem based rpms' structure
> - Anyway I think we can agree with any of the ways.
>
>>> With these rpms,
>>> - people who wants to use rspec 1 has to specify it as
>>>   (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>>>   "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
>>> - people who want to use rspec 2 will specify it as
>>>   (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>>>   /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>>>
>>> If we can agree with these changes, I will submit these specs/srpms for
>>> review requests.
> Regards,
> Mamoru
>
>
> ___
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[TASAKA Mamoru]

Vít Ondruch wrote, at 07/18/2011 04:37 PM +9:00:
> Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
>> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
>>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
 Hi guys,

 Since February, there are available RSpec 2.x in Fedora repositories.
 However, as of now, the main package rubygem-rspec was not migrated to
 RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
 if we could finish the migration to RSpec 2.x lets say in F17 time
 frame. What are your opinions? The list of packages which depends on
 RSpec 1.3 is attached bellow.

>>> IMO F17 seems like a reasonable timeline for this. At that point we
>>> might also want to provide a rubygem-rspec1-compat package for any gems
>>> whose upstream communities haven't switched over.
>>>
>> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
>> before F-16/17 branch (i.e. 2011-07-26)?
>
> Is it worth of it? We can push the change right now, but it will make
> some packages FTBFS. Don't take me wrong, I personally +1 for this
> change, I just wanted to give a chance to others to be prepared.

With rubygem-rspec1 imported, I will change all packages which currently
have "BR: rubygem(rspec)" to "BR: rubygem(rspec1)" and rebuild all those srpms.
If those srpm don't have FTBFS issue right now, they should also succeed on
building after this change (if they fail to build after this change, I guess
they already had FTBFS issue)

>
>> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>
> Is the change in folder structure, i.e. rename from rspec to rspec1
> really necessary? The gems don't conflicts, so it seems to me too much
> effort for no benefit.

Well,
- We cannot have two "rubygem-rspec" srpm (on Fedora repository), so anyway
   one of these should be renamed on srpm name level. With srpm renamed to
   "rubygem-rspec1", I think reconstructuring directories and especially
   changing rspec-1.X.gemspec to rspec"1"-1.X.gemspec would be less confusing
   as it "matches" currently rubygem based rpms' structure
- Anyway I think we can agree with any of the ways.

>> With these rpms,
>> - people who wants to use rspec 1 has to specify it as
>>  (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>>  "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
>> - people who want to use rspec 2 will specify it as
>>  (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>>  /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>>
>> If we can agree with these changes, I will submit these specs/srpms for
>> review requests.

Regards,
Mamoru


___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 18.7.2011 01:42, TASAKA Mamoru napsal(a):
> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>>> Hi guys,
>>>
>>> Since February, there are available RSpec 2.x in Fedora repositories.
>>> However, as of now, the main package rubygem-rspec was not migrated to
>>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>>> if we could finish the migration to RSpec 2.x lets say in F17 time
>>> frame. What are your opinions? The list of packages which depends on
>>> RSpec 1.3 is attached bellow.
>>>
>> IMO F17 seems like a reasonable timeline for this. At that point we
>> might also want to provide a rubygem-rspec1-compat package for any gems
>> whose upstream communities haven't switched over.
>>
> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
> before F-16/17 branch (i.e. 2011-07-26)?

Is it worth of it? We can push the change right now, but it will make 
some packages FTBFS. Don't take me wrong, I personally +1 for this 
change, I just wanted to give a chance to others to be prepared.

> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec

Is the change in folder structure, i.e. rename from rspec to rspec1 
really necessary? The gems don't conflicts, so it seems to me too much 
effort for no benefit.

> With these rpms,
> - people who wants to use rspec 1 has to specify it as
> (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
> "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
> - people who want to use rspec 2 will specify it as
> (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
> /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>
> If we can agree with these changes, I will submit these specs/srpms for
> review requests.
>
> Regards,
> Mamoru
>
>
> ___
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

Dne 18.7.2011 03:05, Michael Stahnke napsal(a):
> On Sun, Jul 17, 2011 at 4:42 PM, TASAKA Mamoru
>   wrote:
>> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
>>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
 Hi guys,

 Since February, there are available RSpec 2.x in Fedora repositories.
 However, as of now, the main package rubygem-rspec was not migrated to
 RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
 if we could finish the migration to RSpec 2.x lets say in F17 time
 frame. What are your opinions? The list of packages which depends on
 RSpec 1.3 is attached bellow.

>>> IMO F17 seems like a reasonable timeline for this. At that point we
>>> might also want to provide a rubygem-rspec1-compat package for any gems
>>> whose upstream communities haven't switched over.
>>>
>> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
>> before F-16/17 branch (i.e. 2011-07-26)?
>>
>> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
>> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>>
>> With these rpms,
>> - people who wants to use rspec 1 has to specify it as
>>(Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>>"gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
>> - people who want to use rspec 2 will specify it as
>>(Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>>/usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>>
>> If we can agree with these changes, I will submit these specs/srpms for
>> review requests.
>>
> I assume that would cause rspec to be dead.packaged.  I am ok with that too.

I don't think so. rubygem-rspec will provide rspec 2.x metapackage. See 
attached Mamoru's spec.

> stahnma
>
>> Regards,
>> Mamoru
>>
>>
>> ___
>> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Michael Stahnke]

On Sun, Jul 17, 2011 at 4:42 PM, TASAKA Mamoru
 wrote:
> Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
>> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>>> Hi guys,
>>>
>>> Since February, there are available RSpec 2.x in Fedora repositories.
>>> However, as of now, the main package rubygem-rspec was not migrated to
>>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>>> if we could finish the migration to RSpec 2.x lets say in F17 time
>>> frame. What are your opinions? The list of packages which depends on
>>> RSpec 1.3 is attached bellow.
>>>
>>
>> IMO F17 seems like a reasonable timeline for this. At that point we
>> might also want to provide a rubygem-rspec1-compat package for any gems
>> whose upstream communities haven't switched over.
>>
>
> Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
> before F-16/17 branch (i.e. 2011-07-26)?
>
> I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
> http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec
>
> With these rpms,
> - people who wants to use rspec 1 has to specify it as
>   (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
>   "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
> - people who want to use rspec 2 will specify it as
>   (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
>   /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.
>
> If we can agree with these changes, I will submit these specs/srpms for
> review requests.
>
I assume that would cause rspec to be dead.packaged.  I am ok with that too.

stahnma

> Regards,
> Mamoru
>
>
> ___
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[TASAKA Mamoru]

Mo Morsi wrote, at 07/15/2011 11:15 AM +9:00:
> On 07/13/2011 02:53 AM, Vít Ondruch wrote:
>> Hi guys,
>>
>> Since February, there are available RSpec 2.x in Fedora repositories.
>> However, as of now, the main package rubygem-rspec was not migrated to
>> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
>> if we could finish the migration to RSpec 2.x lets say in F17 time
>> frame. What are your opinions? The list of packages which depends on
>> RSpec 1.3 is attached bellow.
>>
>
> IMO F17 seems like a reasonable timeline for this. At that point we
> might also want to provide a rubygem-rspec1-compat package for any gems
> whose upstream communities haven't switched over.
>

Can't we do this (i.e. rspec 2 by default, rspec 1 move to compat mode)
before F-16/17 branch (i.e. 2011-07-26)?

I prepared rubygem-rspec-2.6.0 and rubygem-"rspec1"-1.3.2:
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec-2.6.0-1.fc.src.rpm
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1-1.3.2-2.fc.src.rpm
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec.spec
http://mtasaka.fedorapeople.org/Trial-rpms/rubygem-rspec1.spec

With these rpms,
- people who wants to use rspec 1 has to specify it as
   (Build)Requires: rubygem(rspec1), rubygem(rspec), and to use
   "gem 'rspec1'", not "gem 'rspec'". /usr/bin/spec remains as before.
- people who want to use rspec 2 will specify it as
   (Build)Requires: rubygem(rspec), and "gem 'rspec'". Note that
   /usr/bin/rspec is (already) in rubygem-rspec-core-2.6.4.

If we can agree with these changes, I will submit these specs/srpms for
review requests.

Regards,
Mamoru


___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

spec_helper.rb doesn't have necessarily anything to do with Rails, 
although Rails can use such file.

Vit



Dne 15.7.2011 14:45, Tyler Smart napsal(a):
> I have to migrate to Rails 3 for that, right :) One step at a time.
>
> =
> Tyler Smart
> Check out the IT.rb group:
> https://docspace.corp.redhat.com/groups/itrb
>
> - Original Message -
> From: "Vít Ondruch"
> To: ruby-sig@lists.fedoraproject.org
> Sent: Friday, July 15, 2011 8:36:08 AM
> Subject: Re: Migration from RSpec 1.3 to RSpec 2.x
>
> The most differences are usually in spec_helper.rb if you are using one,
> otherwise there are usually no issues.
>
> Vit
>
>
>
> Dne 15.7.2011 14:19, Marek Goldmann napsal(a):
>> Tyler,
>>
>> Depending on your code - migration can be pretty easy. It took me about 5 
>> minutes for example:
>>
>>  
>> https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7d0f7b75360dd379cace73
>>
>> So I highly recommend doing that earlier than later :)
>>
>> --Marek
>>
>> On 2011-07-15, at 14:09, Tyler Smart wrote:
>>
>>> Just a question, but who all is using Rspec 1.3.3 like me? I work on the 
>>> rhsm-web team in Raleigh and have implemented all my tests with rspec 
>>> 1.3.3. Is anyone else already on 2.x?
>> ___
>> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Tyler Smart]

I have to migrate to Rails 3 for that, right :) One step at a time.

= 
Tyler Smart 
Check out the IT.rb group: 
https://docspace.corp.redhat.com/groups/itrb 

- Original Message -
From: "Vít Ondruch" 
To: ruby-sig@lists.fedoraproject.org
Sent: Friday, July 15, 2011 8:36:08 AM
Subject: Re: Migration from RSpec 1.3 to RSpec 2.x

The most differences are usually in spec_helper.rb if you are using one, 
otherwise there are usually no issues.

Vit



Dne 15.7.2011 14:19, Marek Goldmann napsal(a):
> Tyler,
>
> Depending on your code - migration can be pretty easy. It took me about 5 
> minutes for example:
>
>   
> https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7d0f7b75360dd379cace73
>
> So I highly recommend doing that earlier than later :)
>
> --Marek
>
> On 2011-07-15, at 14:09, Tyler Smart wrote:
>
>> Just a question, but who all is using Rspec 1.3.3 like me? I work on the 
>> rhsm-web team in Raleigh and have implemented all my tests with rspec 1.3.3. 
>> Is anyone else already on 2.x?
> ___
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Vít Ondruch]

The most differences are usually in spec_helper.rb if you are using one, 
otherwise there are usually no issues.

Vit



Dne 15.7.2011 14:19, Marek Goldmann napsal(a):
> Tyler,
>
> Depending on your code - migration can be pretty easy. It took me about 5 
> minutes for example:
>
>   
> https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7d0f7b75360dd379cace73
>
> So I highly recommend doing that earlier than later :)
>
> --Marek
>
> On 2011-07-15, at 14:09, Tyler Smart wrote:
>
>> Just a question, but who all is using Rspec 1.3.3 like me? I work on the 
>> rhsm-web team in Raleigh and have implemented all my tests with rspec 1.3.3. 
>> Is anyone else already on 2.x?
> ___
> 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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

Tyler,

Depending on your code - migration can be pretty easy. It took me about 5 
minutes for example:


https://github.com/boxgrinder/boxgrinder-build/commit/bbd2083d4cf25d31cb7d0f7b75360dd379cace73

So I highly recommend doing that earlier than later :)

--Marek

On 2011-07-15, at 14:09, Tyler Smart wrote:

> Just a question, but who all is using Rspec 1.3.3 like me? I work on the 
> rhsm-web team in Raleigh and have implemented all my tests with rspec 1.3.3. 
> Is anyone else already on 2.x?

___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Tyler Smart]

Just a question, but who all is using Rspec 1.3.3 like me? I work on the 
rhsm-web team in Raleigh and have implemented all my tests with rspec 1.3.3. Is 
anyone else already on 2.x?

= 
Tyler Smart 
Check out the IT.rb group: 
https://docspace.corp.redhat.com/groups/itrb 

- Original Message -
From: "Mo Morsi" 
To: ruby-sig@lists.fedoraproject.org
Sent: Thursday, July 14, 2011 10:15:22 PM
Subject: Re: Migration from RSpec 1.3 to RSpec 2.x

On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> Hi guys,
> 
> Since February, there are available RSpec 2.x in Fedora repositories.
> However, as of now, the main package rubygem-rspec was not migrated to
> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> if we could finish the migration to RSpec 2.x lets say in F17 time
> frame. What are your opinions? The list of packages which depends on
> RSpec 1.3 is attached bellow.
> 

IMO F17 seems like a reasonable timeline for this. At that point we
might also want to provide a rubygem-rspec1-compat package for any gems
whose upstream communities haven't switched over.

  -Mo
___
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

Re: Migration from RSpec 1.3 to RSpec 2.x

[Mo Morsi]

On 07/13/2011 02:53 AM, Vít Ondruch wrote:
> Hi guys,
> 
> Since February, there are available RSpec 2.x in Fedora repositories.
> However, as of now, the main package rubygem-rspec was not migrated to
> RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
> if we could finish the migration to RSpec 2.x lets say in F17 time
> frame. What are your opinions? The list of packages which depends on
> RSpec 1.3 is attached bellow.
> 

IMO F17 seems like a reasonable timeline for this. At that point we
might also want to provide a rubygem-rspec1-compat package for any gems
whose upstream communities haven't switched over.

  -Mo
___
ruby-sig mailing list
ruby-sig@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Re: Migration from RSpec 1.3 to RSpec 2.x

[Marek Goldmann]

Vit,

Thanks for heads-up, I moved rubygem-boxgrinder* packages upstream to RSpec2. 
Next releases will include the change.

--Marek

On 2011-07-13, at 08:53, Vít Ondruch wrote:

> Hi guys,
> 
> Since February, there are available RSpec 2.x in Fedora repositories. 
> However, as of now, the main package rubygem-rspec was not migrated to RSpec 
> 2.x and still provides RSpec 1.3 functionality. It would be nice, if we could 
> finish the migration to RSpec 2.x lets say in F17 time frame. What are your 
> opinions? The list of packages which depends on RSpec 1.3 is attached bellow.
> 
> If you wonder how to use RSpec 2.x for your package, it is usually quite 
> easy. In you spec just replace
> 
> BuildRequires: rubygem(rspec)
> 
> with
> 
> # Use rspec-core until rspec are migrated to RSpec 2.x
> BuildRequires: rubygem(rspec-core)
> 
> and in you %check section, if you are not using Rake, replace call to 'spec' 
> with 'rspec'. As an example, you can take a look on one of mine rubygems, 
> e.g. rubygem-regin, rubygem-pg.
> 
> Once we will migrate all packages into RSpec 2.x, we can migrate also the 
> rubygem-rspec and change the BR back to rubygem(rspec).
> 
> 
> Vit
> 
> 
>  Původní zpráva 
> Předmět:  Re: aeolus conductor / rails 3 / F16 integration path
> Datum:Tue, 12 Jul 2011 10:47:36 -0400
> Od:   Mo Morsi 
> Komu: Vít Ondruch 
> 
> > It is currently 24 packages which are using RSpec 1.x:
> > 
> > ]$ repoquery --repoid=fedora-source --arch=src --whatrequires
> > 'rubygem(rspec)'
> > rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src(mmorsi)
> > rubygem-boxgrinder-build-0:0.9.1-1.fc15.src  (goldmann)
> > rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann)
> > rubygem-commander-0:4.0.3-4.fc15.src  (mfojtik)
> > rubygem-cucumber-0:0.10.0-5.fc15.src  (mmorsi, clalance, mfojtik)
> > rubygem-cucumber-rails-0:0.3.2-5.fc15.src  (mmorsi, clalance, mfojtik)
> > rubygem-facon-0:0.4.1-2.fc15.src(stahnma)
> > rubygem-factory_girl-0:1.3.2-3.fc15.src(mfojtik)
> > rubygem-ffi-0:0.6.3-2.fc15.src   (bkearney)
> > rubygem-linode-0:0.6.2-1.fc15.src   (stahnma)
> > rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x   (vondruch)
> > rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x  (mmorsi)
> > rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to 
> > be wrong dependency(vondruch)
> > rubygem-rack-test-0:0.5.4-1.fc15.src(mfojtik)
> > rubygem-rake-compiler-0:0.7.8-1.fc15.src(mamoru)
> > rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x   (vondruch)
> > rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
> > rubygem-scruffy-0:0.2.6-2.fc15.src   (mmorsi)
> > rubygem-simple-navigation-0:3.0.0-3.fc15.src   (mfojtik)
> > rubygem-thin-0:1.2.7-2.fc15.src   (mfojtik)
> > rubygem-typhoeus-0:0.2.0-2.fc15.src  (mfojtik)
> > rubygem-uuidtools-0:2.1.1-1.fc14.src  (mmorsi)
> > rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x  (vondruch)
> > rubygem-yard-0:0.5.3-3.fc14.src  (mmorsi)
> > 
> > So from my packages, 2 can be converted into RSpec 2.x right now, 2 are
> > using 1.3, so it would need some effort and 1 seems to be just wrong
> > dependency. May be we should move this discussion into ruby-sig ML
> 
> 
> I appended the package owners onto the list for future reference.
> 
> Agree on moving this conversation to ruby-sig.
> 
> 
> ___
> 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