ruby-sig January 2012

ruby-sig@lists.fedoraproject.org

13 participants
20 discussions

Migration from RSpec 1.3 to RSpec 2.x
by Vít Ondruch 27 Feb '12

27 Feb '12

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.

8 42

Unicorn packagin, reviewing needed
by "Guillermo Gómez S." 26 Feb '12

26 Feb '12

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 _

1 1

Re: Migration from RSpec 1.3 to RSpec 2.x
by Shawn Starr 10 Feb '12

10 Feb '12

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

4 19

gem2rpm and Ruby 1.9
by Michael Stahnke 07 Feb '12

07 Feb '12

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.

5 13

rubygems-devel available on f15/16/f17 buildtree
by Mamoru TASAKA 30 Jan '12

30 Jan '12

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

1 0

Coding Ruby using Fedora?
by Frank Murphy 26 Jan '12

26 Jan '12

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

2 1

Re: Heads up: Rebuild for Ruby 1.9.3
by Vít Ondruch 26 Jan '12

26 Jan '12

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

3 3

Ruby 1.9.3 rebuild started!
by Vít Ondruch 26 Jan '12

26 Jan '12

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

4 7

Heads up: Rebuild for Ruby 1.9.3
by Bohuslav Kabrda 24 Jan '12

24 Jan '12

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

2 1

Packaging guidelines - Bundler
by Vít Ondruch 23 Jan '12

23 Jan '12

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

5 13

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig January 2012