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, 7 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, 7 months
Ruby 1.9.3 testing repository
by Vít Ondruch
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
11 years, 8 months
Prep, build and install
by Steve Traylen
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
11 years, 9 months
Ruby 1.9.3 test rebuild
by Bohuslav Kabrda
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/
11 years, 9 months
Ruby 1.9.3 - Problematic Packages
by Bohuslav Kabrda
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&...
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
11 years, 9 months
Ruby 1.9.3 rebuild
by Bohuslav Kabrda
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.
11 years, 9 months
