ruby-sig December 2011

ruby-sig@lists.fedoraproject.org

8 participants
9 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

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

Ruby 1.9.3 testing repository
by Vít Ondruch 17 Jan '12

17 Jan '12

Hello, I have prepared testing repository with Ruby 1.9.3 rev 33347 (i.e. bit newer version then RC1). You can enable it by downloading repo file [1] into your /etc/yum.repos.d directory. You can later install the Ruby package by issuing: # sudo yum install ruby rubygems-1.8.10-rc1.1.fc17 Please note that installation of fully versioned rubygems is *mandatory* ATM and you have to *uninstall rubygems* package prior installing this test release to avoid version conflicts. This will be fixes as soon as final release of Ruby will be available. Vit [1] http://vondruch.fedorapeople.org/ruby_1.9.3.repo

7 29

New Ruby Guidelines Draft
by Bohuslav Kabrda 03 Jan '12

03 Jan '12

Hi guys, I promise that this is my last mail today :) Together with Vit, we have created a new Ruby packaging guidelines draft [1] and we would very much like you to go through it, so that we can discuss it here and change it for the best. Regards, Bohuslav. [1] https://fedoraproject.org/wiki/PackagingDrafts/Ruby

4 12

Prep, build and install
by Steve Traylen 22 Dec '11

22 Dec '11

Hi, I noticed the link to the new ruby packaging draft and had a comment. Currently the guidelines suggest to do everything basically within prep with build and install empty. Can it be considered to break this up into the prep build and install sections. The gem can unpacked in prep and im hoping its possible to build and then install from that unpack...( i dont know how to do this or if is possiblE?) In the current situation it is not obvious how you would apply a patch in the rpm and probably more importly the "rpmbuild -bp", "rpmbuild -bc" or "rpmbuild -bi" do not have there normal meaning. -- Steve Traylen

4 6

Ruby 1.9.3 test rebuild
by Bohuslav Kabrda 22 Dec '11

22 Dec '11

Hi everyone, I just uploaded all the packages rebuilt for Ruby 1.9.3. - At [1], you will find *.tar.gz files. Each file contains a directory with git repo cloned from fedpkg. To see the changes that I have made with your gem, you can run "git diff master" in the corresponding directory. - At [2], you will find the SRPMS built in mock for fedora-rawhide-x86_64. A few notes: - I didn't bump any versions/releases/changelogs, even when I was switching to newer versions from upstreams, these you're gonna have to do by yourselves. - As I mentioned in one of my previous mails, the gem binary extensions are not yet placed into the target directory, because this haven't been sorted out completely, yet. Again, this you're gonna have to do by yourselves when it's done in Ruby 1.9.3 spec (resp. the corresponding Rubygems). - The Ruby package I used is not completely up to date with Vit's testing repo, but the changes that Vit made shouldn't change anything from this point of view. So this is for you to see how the packages will look like. And when the time comes, you can actually use these when switching to Ruby 1.9.3 :) Regards, Bohuslav. [1] http://bkabrda.fedorapeople.org/ruby-git-repos/ [2] http://bkabrda.fedorapeople.org/ruby-srpms/

1 0

Ruby 1.9.3 - Problematic Packages
by Bohuslav Kabrda 21 Dec '11

21 Dec '11

Hi, as I promised, here is the list of packages that either don't work at all or they need some fixtures/patches (mostly tests): To explain my notes: - The 'struct RString' or 'struct RArray' means, that the package has a binary extension, which is not adapted to changes in Ruby 1.9.3 Ruby C API (see [1] for example). - Tests, reported <url> means, that the package builds/compiles, but some tests fail, and the url is where I reported the failures. - The others are hopefully understandable :) If not, feel free to contact me. elice - sort it out after we replace ruby-racc by rubygem-racc eruby - will probably be made obsolete, see BZ 761518 gdal - currently ftbfs in koji with Ruby 1.8.7 geos - 'struct RArray' - reported http://trac.osgeo.org/geos/ticket/379 kazehakase - 'struct RArray' - reported https://gna.org/bugs/index.php?19211 kross-interpreters - wants env.h, already reported https://bugs.kde.org/show_bug.cgi?id=243565 libcaca - 'struct RString' http://caca.zoy.org/ticket/99 libdmtx - 'struct RString' - in new version, ruby support is separated into dmtx-wrappers libguestft - ftbfs in mock (Cannot retrieve repository metadata (repomd.xml) for local repository: ruby_1.9.3.), this is probably due to testing with a local repo, but it builds locally, so it's probably ok libprelude - 'struct RArray', upstream dead? migemo - tests fail, possible solution mentioned in spec obexftp - 'struct RString' - reported http://dev.zuckschwerdt.org/openobex/ticket/49 openwsman - fails to build, reported https://sourceforge.net/tracker/?func=detail&aid=3460900&group_id=151841&at… qdbm - 'struct RString' and upstream seems dead root - 'struct RString' - reported https://savannah.cern.ch/bugs/?90002 ruby-fam - 'struct RString' and upstream is dead -> reported BZ 769230 ruby-postgres - 'struct RString' and obsoleted by rubygem-pg -> reported BZ 769256 ruby-qpid - 'struct RString' -> reported BZ 769259, should be solved by new version, when it gets to Rawhide ruby-racc - upstram is dead, we should replace it by rubygem-racc ruby-revolution - 'struct RString' and upstream is dead -> reported BZ 769284 ruby-RRDTool - 'struct RArray' and upstream is dead -> reported BZ 769288 rubygem-activeldap - will need update after gettext_i18n_rails gets to Fedora rubygem-boxgrinder-build - investigate test failures rubygem-fastercsv - should be deprecated, ruby 1.9.3 has its own fastercsv rubygem-fastthread - not needed - should be supported in Ruby 1.9.3, dependent packages seem to work without it rubygem-ferret - 'struct RArray' and upstream seems dead - there are some links to possibly working variants on its Github, maybe have a look there: https://github.com/dbalmain/ferret/issues/4 rubygem-gettext-active_record - FTBFS already reported BZ 716214 rubygem-locale_rails - doesn't work with Rails > 3, should be retired rubygem-main - needs update to new version and for that, it needs rubygem-map (will have to be created) rubygem-maruku - tests, reported https://github.com/nex3/maruku/issues/43 rubygem-mkrf - tests, reported https://github.com/xxx/mkrf/issues/1 rubygem-mocha - tests, reported https://github.com/floehopper/mocha/issues/41 rubygem-pam - 'struct RArray' and upstream is dead rubygem-oniguruma - 'struct RString' and it is included in 1.9.3 rubygem-rack - tests, reported https://github.com/rack/rack/issues/274 rubygem-rmail - weird encoding issue, upstream dead rubygem-tilt - tests, reported https://github.com/rtomayko/tilt/issues/120, should be fixed when RedCloth is updated rubygem-whiskey_disk - problems with tests - some facon/bacon issue? (but it should work, we should update both bacon and facon) rubygem-zoom - doesn't work with 1.9.3, but there is a port at https://github.com/bricestacey/ruby-zoom, will probably need a re-review (not a gem) sdljava - some swig problem connected with ruby processing of the source, upstream is dead skf - tests, reported http://sourceforge.jp/ticket/browse.php?group_id=353&tid=26966 subversion - doesn't work with Ruby >= 1.9 at all (up to this moment) tango - currently ftbfs in koji with Ruby 1.8.7 rubygem-{linecache,ruby-debug,ruby-debug-base} - we will need their 1.9 variants: rubygem-{linecache,ruby-debug,ruby-debug-base}19 I will try to upload my testing repo, or at least modified specfiles somewhere public, so that everyone can take a look at it. There is however one little leftover - the binary extensions of gems are currently placed in %{ruby_vendorarchdir}, but will go to %{gem_extdir}, that should be located in %{_libdir}/gems/exts/%{gem_name}-%{version}. This is Vit's work and I believe that everyone can finish the relocation of binary extensions by himself once Vit is done. Regards, Bohuslav. [1] http://www.ruby-forum.com/topic/134350

1 0

Rails 4 will be only Ruby 1.9.3 compatible
by Vít Ondruch 21 Dec '11

21 Dec '11

Hi all, You are probably already aware, but just for your information, Ruby on Rails 4.0 will be compatible only with Ruby 1.9.3 and should be released in the summer 2012 http://weblog.rubyonrails.org/2011/12/20/rails-master-is-now-4-0-0-beta Vit

1 0

Ruby 1.9.3 rebuild
by Bohuslav Kabrda 21 Dec '11

21 Dec '11

Hi guys, as Mamoru noted on one of my bugzillas for build failures with Ruby 1.9.3, I decided I will move all the agenda here for the time being. I have been working past two weeks on rebuild of all the Ruby/Rubygems dependent packages and got some failures. There are basically two types of problematic packages (most of the packages work ok, so we shouldn't run into any serious problems): 1) Packages that work in some way, but some tests fail - I usually reported the failures upstream or proposed the patches/fixes/pull requests. 2) Packages with C extensions/C bindings that even fail to build due to changes in the Ruby 1.9.3 C API. Unluckily, some of these are no longer maintained by upstream and we will have to decide what to do. The still maintained, I also reported upstream. So I'm going to stop reporting this to bugzilla until we (hopefully) get a special tag in Koji, so that we can solve as many problems as we can here. The only thing we need to do here is to decide what to do with packages that don't work and their upstreams are dead/unresponsive. So for each of them, I will write a separate mail to this mailing list, including the detailed info on how it failed and my suggestion what to do with that and we may have a talk about it. For some of the packages I already created Bugzillas, so we can solve those there and not duplicate them on this list. I hope you all like this idea and that you are ok with it. Regards, Bohuslav.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig December 2011