Migration from RSpec 1.3 to RSpec 2.x
by Vít Ondruch
Hi guys,
Since February, there are available RSpec 2.x in Fedora repositories.
However, as of now, the main package rubygem-rspec was not migrated to
RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice,
if we could finish the migration to RSpec 2.x lets say in F17 time
frame. What are your opinions? The list of packages which depends on
RSpec 1.3 is attached bellow.
If you wonder how to use RSpec 2.x for your package, it is usually quite
easy. In you spec just replace
BuildRequires: rubygem(rspec)
with
# Use rspec-core until rspec are migrated to RSpec 2.x
BuildRequires: rubygem(rspec-core)
and in you %check section, if you are not using Rake, replace call to
'spec' with 'rspec'. As an example, you can take a look on one of mine
rubygems, e.g. rubygem-regin, rubygem-pg.
Once we will migrate all packages into RSpec 2.x, we can migrate also
the rubygem-rspec and change the BR back to rubygem(rspec).
Vit
-------- Pu*vodní zpráva --------
Pr(edme(t: Re: aeolus conductor / rails 3 / F16 integration path
Datum: Tue, 12 Jul 2011 10:47:36 -0400
Od: Mo Morsi <mmorsi(a)redhat.com>
Komu: Vít Ondruch <vondruch(a)redhat.com>
> It is currently 24 packages which are using RSpec 1.x:
>
> ]$ repoquery --repoid=fedora-source --arch=src --whatrequires
> 'rubygem(rspec)'
> rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi)
> rubygem-boxgrinder-build-0:0.9.1-1.fc15.src (goldmann)
> rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann)
> rubygem-commander-0:4.0.3-4.fc15.src (mfojtik)
> rubygem-cucumber-0:0.10.0-5.fc15.src (mmorsi, clalance, mfojtik)
> rubygem-cucumber-rails-0:0.3.2-5.fc15.src (mmorsi, clalance, mfojtik)
> rubygem-facon-0:0.4.1-2.fc15.src (stahnma)
> rubygem-factory_girl-0:1.3.2-3.fc15.src (mfojtik)
> rubygem-ffi-0:0.6.3-2.fc15.src (bkearney)
> rubygem-linode-0:0.6.2-1.fc15.src (stahnma)
> rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x (vondruch)
> rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x (mmorsi)
> rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to be wrong dependency (vondruch)
> rubygem-rack-test-0:0.5.4-1.fc15.src (mfojtik)
> rubygem-rake-compiler-0:0.7.8-1.fc15.src (mamoru)
> rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x (vondruch)
> rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik)
> rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi)
> rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik)
> rubygem-thin-0:1.2.7-2.fc15.src (mfojtik)
> rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik)
> rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi)
> rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x (vondruch)
> rubygem-yard-0:0.5.3-3.fc14.src (mmorsi)
>
> So from my packages, 2 can be converted into RSpec 2.x right now, 2 are
> using 1.3, so it would need some effort and 1 seems to be just wrong
> dependency. May be we should move this discussion into ruby-sig ML
I appended the package owners onto the list for future reference.
Agree on moving this conversation to ruby-sig.
11 years, 3 months
Unicorn packagin, reviewing needed
by "Guillermo Gómez S."
On my way to include Unicorn in Fedora, i need reviewers for the
following pending BZ's
1. rubygem-rr: https://bugzilla.redhat.com/show_bug.cgi?id=783791 <<<<<<<<<<
2. rubygem-session: https://bugzilla.redhat.com/show_bug.cgi?id=783771 <<<<<<
3. rubgyem-raindrops (done)
4. rubygem-kdio (done)
5. rubygem-wrongdoc (impossible until nokogiri gets update)
6. rubygem-tidy (pending for one of the previous)
7. rubygem-unicorn (pending for one of the previous)
All those specs/srpms are ready but awaiting for reviewers :) Some
test suites are not being executed until dependencies gets fulfilled.
thanks for your review
rgds
_ Gomix _
11 years, 3 months
Re: Migration from RSpec 1.3 to RSpec 2.x
by Shawn Starr
Im about to submit whole bunch of rubygems to Fedora. Most of them use rspec 1.3.
On Mon Jul 25th, 2011 10:10 AM EDT Mo Morsi wrote:
>Since this list is a lot shorter than the corresponding list in Fedora,
>perhaps we can get these package maintainers to update to RSpec 2.
>
>Otherwise, perhaps we can leave it in there as there for now, push the
>rspec-core and other subcomponents to EPEL, and update the BoxGrinder
>RPM to depend on those subcomponents instead of rspec itself?
>
> -Mo
>
>On 07/22/2011 09:18 AM, Marek Goldmann wrote:
>> For EPEL 6 - exactly 5:
>>
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> rubygem-extlib-0:0.9.13-5.el6.src
>> rubygem-facon-0:0.4.1-2.el6.src
>> rubygem-rack-test-0:0.5.4-1.el6.src
>> rubygem-thin-0:1.2.8-4.el6.src
>> rubygem-uuidtools-0:2.1.1-1.el6.src
>>
>> For EPEL 5 - also 5:
>>
>> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)'
>> rubygem-extlib-0:0.9.13-5.el5.src
>> rubygem-facon-0:0.4.1-2.el5.src
>> rubygem-linode-0:0.6.2-1.el5.src
>> rubygem-thin-0:1.2.8-2.el5.src
>> rubygem-uuidtools-0:2.1.1-2.el5.src
>>
>> --Marek
>>
>> On 22 lip 2011, at 09:48, Vít Ondruch wrote:
>>
>>> RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea
>>> how many packages depends on RSpec in EPEL?
>>>
>>>
>>> Vit
>>>
>>>
>>>
>>> Dne 21.7.2011 20:49, Marek Goldmann napsal(a):
>>>> There is one more thing:
>>>>
>>>> Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but there is only RSpec 1.3. What would be the approach to bump RSpec there?
>>>>
>>>> --Marek
>>>>
>>>> On 18 lip 2011, at 18:49, Mo Morsi wrote:
>>>>
>>>>> Perhaps we can shoot for doing this w/ F17, and if we are unable to
>>>>> migrate all the dependent packages over, then add a rspec1 compat
>>>>> package to buy us some more time.
>>>>>
>>>>> In any case, would rather push this off to F17 myself as a few of us are
>>>>> going through and updating alot of the rails related plugins to be
>>>>> compatible w/ Rails 3 in Fedora. We're trying to get this done by the
>>>>> F16 deadline next week.
>>>> --Marek
>>>>
>>>> _______________________________________________
>>>> ruby-sig mailing list
>>>> ruby-sig(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>>>
>>> _______________________________________________
>>> ruby-sig mailing list
>>> ruby-sig(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>>
>> _______________________________________________
>> ruby-sig mailing list
>> ruby-sig(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
>
>_______________________________________________
>ruby-sig mailing list
>ruby-sig(a)lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/ruby-sig
11 years, 3 months
gem2rpm and Ruby 1.9
by Michael Stahnke
Has gem2rpm been updated for the Ruby 1.9 changes? The guidelines
seem quite a bit different, an the gem2rpm macros in the current state
(at least on EL6) don't map up. Things like
%gemdir rather than %gem_dir.
11 years, 3 months
rubygems-devel available on f15/16/f17 buildtree
by Mamoru TASAKA
Hello, all:
Maybe someone has already noticed this, however I anyway annouce that
now rubygems-devel is also available on f15/f16/f17 buildtree (as
well as f17-ruby buildtree), and macros used for gems-based rpms
can be used. (f15/f16 new rubygems are now tagged as override, and currently
on -testing repository).
The differcence is
* f17-ruby %gem_dir points to /usr/share/gems, while f15/16/17 %gem_dir
points to /usr/lib/ruby/gems/1.8
" %gem_extdir is currently *not available*, because currently
f15/f16/f17 (not f17-ruby) rubygems does not add %gem_extdir to
search path.
So now for noarch gems, the same spec file can be used for
f15/f16/f17/f17-ruby.
For gems creating C module extension, some
difference still appear between f17-ruby spec file and f15/f16/f17
spec files. Maybe just adding %gem_extdir as rubygems' search path
on f15/f16 rubygems (and do nothing else) is one of the ideas -
with this spec files can be the same also for arch-specific gem
files.
Regards,
Mamoru
11 years, 4 months
Coding Ruby using Fedora?
by Frank Murphy
Starting to learn Ruby using LRTHW.
At a minimum what should be installed.
So coding\compiling could be done in a shell
"yum install ruby"
did not seem to pull in anything else.
rpm -qa | grep ruby
ruby-libs-1.8.7.357-1.fc16.x86_64
ruby-1.8.7.357-1.fc16.x86_64
yum search ruby, a prety long list.
But don't know what is needed as yet,
--
Regards,
Frank Murphy
UTF_8 Encoded
11 years, 4 months
Re: Heads up: Rebuild for Ruby 1.9.3
by Vít Ondruch
Dne 25.1.2012 00:52, Rex Dieter napsal(a):
> Mo Morsi wrote:
>
>> On 01/24/2012 04:50 AM, Bohuslav Kabrda wrote:
>>> Hi,
>>> since we finally got our Ruby 1.9.3 feature page [1] approved, we are
>>> starting rebuild for Ruby 1.9.3. Everyone who owns a package that depends
>>> on Ruby or Rubygems should rebuild it in the special Koji target
>>> "f17-ruby". This target will be merged into rawhide just before the
>>> branching, which will occur on 2012-02-07. After this deadline, you will
>>> need to go through the standard Bodhi update process. The detailed
>>> instructions on rebuilding the packages, including our suggested changes
>>> can be found in [2]. Feel free to contact me or Vit Ondruch (vondruch at
>>> redhat dot com) or write to ruby-sig mailing lists, if you run into any
>>> kind of problems.
>>>
>>>
>> I'm somewhat confused. Has the issue w/ sudo gem install been resolved?
> Any citation or bug references for this problem you mention?
>
> -- rex
>
Let me clear the situation. First of all, this is not issue of "sudo gem
install". That command works just fine. That is issue with Bundler.
Unfortunately, Bundler is one big hack above RubyGems based on some
assumptions which are not true. It can be seen on its code where is a
lot of custom logic for specific version o RubyGems and Bundler has a
lot more quirks with regard of its usage on package driven systems. It
can break for example with every upstream change of RubyGems. Now what
is the issue:
Ruby, speaking about upstream as well as 1.8 in Fedora, traditionally
broke the FHS. We tried to remove this breakage with Ruby 1.9. RubyGems
traditionally installs their binary extensions into the same place as
their platform independent code, incompatible with FHS. To be somehow
compatible with FHS, this was changed and for Ruby 1.8, the binary
extensions were installed into ruby_sitedir. That results in conflicting
binary RPMs which conflicts among their versions, although this was
never the case for RubyGems packages. So for Ruby 1.9.3 we tried to work
on this issue and we modified RubyGems to be able to load the libraries,
where the noarch part is placed in share and the binary library in lib,
so RPM packaged gems are installed into /usr/share and their binary
libraries into /usr/lib. Moreover, we changed how RubyGems works, e.g.
by default, "gem install" installs gems into your home directory, so you
don't need sudo to work with gems anymore. However, if your are using
"gem install" with root users, they are installed into /usr/local/share
and their binary libraries are installed into /usr/local/lib.
Now there comes Bundler. Assuming it knows everything about RubyGems,
they put together their custom logic how to populate Ruby's load paths,
which does not work well with changes we made into RubyGems, i.e. it
cannot add the binary extension path to the Ruby's load path, resulting
in failure when loading the gem. Nevertheless, this is going to be
handled in RPM packaged Bundler and it will work properly as long as
user uses RPM packaged Bundler. Once somebody installs upstream version
of Bundler, the Bundler fails naturally.
So there are probably 4 solutions to this issue:
1) Always use Bundler provided by Fedora which will works as it should.
2) Force Ruby and RubyGems upstream to properly support FHS. I already
provided patches [1] but I need your support.
3) Revert the customized behavior of RubyGems and break FHS.
4) Treat root as regular user and install gem also into root's home
directory, but it obviously doesn't make sense.
So obviously I have chosen 1) and trying to move forward with 2). That
works most of the times. It breaks only in situation, when you install
upstream Bundler using "sudo gem install" and later you want to use some
system wide gem with binary extension. If you install gems using "gem
install" into your home dir (preferred, default way), it works every
time. Mixing of RPMs with other package managers has its limits and this
is one of them.
Vit
[1] https://github.com/rubygems/rubygems/issues/210
11 years, 4 months
Ruby 1.9.3 rebuild started!
by Vít Ondruch
Hi rubyists,
yesterday evening, we finally obtained tag/target [1] for our Ruby 1.9.3
rebuild. Following that, I immediately build Ruby 1.9.3 there and
following with gems I own or maintain. I would like to ask you to
support me in this effort. I'd like to see to majority of packages
rebuild in this tag before F17 branch, which is 7th of February
according to Fedora 17 release schedule [2]. We would like to merge the
target into the f17 target right before the branch. After this
milestone, we will need to do the rest, however, Bodhi will slow us down.
So here I'll try to list some tips how to proceed, although they are
probably not exhaustive and we will try to update the how to as we proceed.
=== Build ===
$ fedpkg build --target=f17-ruby
Please note that we are building with special target f17-ruby and that
we are building from master.
=== Updates needed for your package ===
If you wonder what you should change in your package, it is very likely
that you can find updated .srpm in bkabrda's repository [3] as well as
clone of original git repo [4] if you prefer. There is also list of
packages with potential issues [5].
Please note that there was done mass rebuild in mean time, therefore the
packages needs to be updated. Pay special attention to release number. I
am using currently following procedure:
1) $ fedpkg co rubygem-foo
2) $ wget
http://bkabrda.fedorapeople.org/ruby-srpms/rubygem-foo-1.0-1.fc17.src.rpm
3) $ fedpkg import rubygem-foo-1.0-1.fc17.src.rpm
4) $ git reset HEAD rubygem-foo.spec
5) $ git checkout -p -- rubygem-foo.spec
Note that you need this step to resurrect the changelog and revision
changes due to mass rebuild, but you can use also different methods if
you like.
6) $ rpmdev-bumpspec rubygem-foo.spec
7) $ git commit -a
8) $ git push
9) $ fedpkg build --target=f17-ruby
=== MiniTest ===
If you are using MiniTest for testing of your packages (i.e. you are
executing the test suite using "testrb"), you need to add
"BuildRequires: rubygem(minitest)" into your package, since we moved
MiniTest into the separate gem.
=== Gems with binary extensions ===
If you have gem with binary extension (i.e. unless your gem is noarch),
then please note that .srpms available in [3] do not reflect our recent
packaging guidelines draft [6] yet. Therefore, please check the
guidelines and update you package accordingly, e.g. after updates, you
should have in your .spec file lines similar to following:
mkdir -p %{buildroot}%{gem_extdir}/foo
mv %{buildroot}%{gem_instdir}/foo/shared_object.so
%{buildroot}%{gem_extdir}/foo/shared_object.so
and you package must own the %{gem_extdir}.
=== Packages already available in tag ===
If you are interested what packages are built already, you can check it
using following command:
$ koji list-tagged f17-ruby
=== Build dependencies ===
If you build prerequisites for some package, don't forget that you have
to wait for repository update. You can use either
$ fedpkg chain-build
to build whole package dependency chain or
$ koji wait-repo dist-rawhide --build=rubygem-foo-1.0-1.fc17
Once again, please rebuild your package ASAP to allow your fellow
Rubyists rebuild their dependencies. Thank you for your collaboration.
Vit
[1] https://fedorahosted.org/rel-eng/ticket/5016
[2] http://fedoraproject.org/wiki/Schedule
[3] http://bkabrda.fedorapeople.org/ruby-srpms/
[4] http://bkabrda.fedorapeople.org/ruby-git-repos/
[5]
http://lists.fedoraproject.org/pipermail/ruby-sig/2011-December/000729.html
[6]
https://fedoraproject.org/wiki/PackagingDrafts/Ruby#RubyGem_with_extensio...
11 years, 4 months
Heads up: Rebuild for Ruby 1.9.3
by Bohuslav Kabrda
Hi,
since we finally got our Ruby 1.9.3 feature page [1] approved, we are starting rebuild for Ruby 1.9.3. Everyone who owns a package that depends on Ruby or Rubygems should rebuild it in the special Koji target "f17-ruby". This target will be merged into rawhide just before the branching, which will occur on 2012-02-07. After this deadline, you will need to go through the standard Bodhi update process. The detailed instructions on rebuilding the packages, including our suggested changes can be found in [2]. Feel free to contact me or Vit Ondruch (vondruch at redhat dot com) or write to ruby-sig mailing lists, if you run into any kind of problems.
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://fedoraproject.org/wiki/Features/Ruby_1.9.3
[2] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-January/000805.html
11 years, 4 months
Packaging guidelines - Bundler
by Vít Ondruch
Hi everybody,
I am wondering if we should mention Bundler in Ruby's packaging
guidelines and what should be recommendations? Or should we leave it in
gray area of guidelines?
Thinking about it again and again, I believe that we should discourage
usage of Bundler in Fedora. What is your opinion?
Vit
11 years, 4 months
