Spec URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib.spec SRPM URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib-0.9.13-1.fc16.src.rpm Description: Support library for DataMapper and Merb Please note: This package is marked as expired/blocked in Fedora 15+, It will be needed for me to build OpenNebula which I am also going to be submitting along with some other rubygems to come (see other review requests coming soon). This package is currently in EPEL5/6.
Hi, Shawn, you say you need it for building OpenNebula ? Which version ? Version 2.2.1 seems to run and compile fine without rubygem-extlib. Few comments: 1/ %global ruby_sitelib %(ruby -rrbconfig -e "puts Config::CONFIG['sitelibdir']") should be conditional, eg something like this: %{!?ruby_sitelib: %global ruby_sitearch %(ruby -rrbconfig -e "puts Config::CONFIG['sitearchdir']")} 2/ in %setup, better do %setup -q -c -T cp %{SOURCE0} %{gemname}-%{version}.gem and then in %build use %{gemname}-%{version}.gem instead of %{SOURCE0} (Not an expert myself on this, I was asked myself to do it this way although the twiki states to do it the way you do it. Twiki should be changed I think, as well as many other packages)
Actually, for OpenNebula 3.0, that is coming. I'm working with upstream on their requirements. For #1, conditional? but isn't that explicit with this being a rubygem? so you would have ruby as a BuildRequires anyway? For #2 Can change that sure, this .spec file came from EPEL6 with very minor changes.
I've made all the changes Spec URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib.spec SRPM URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib-0.9.13-1.fc16.src.rpm
gem list -r extlib shows that the latest is 0.9.15.
I can grab .15, need to confirm it builds.. will post update in 30 mins or so
ok, .15 is built, it needed some changes see: SPEC: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib.spec SRPM: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib-0.9.15-1.fc16.src.rpm Since this is a new version build revision is 1.
mock build works fine. Some warnings in the results: -bash-4.1$ rpmlint rubygem-extlib-0.9.15-1.fc16.noarch.rpm rubygem-extlib.noarch: W: spelling-error Summary(en_US) Merb -> Herb, Verb, Serb rubygem-extlib.noarch: W: spelling-error %description -l en_US Merb -> Herb, Verb, Serb $ rpmlint ruby-extlib-0.9.15-1.fc16.noarch.rpm ruby-extlib.noarch: W: no-documentation ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/struct.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/struct.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/logger.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/logger.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/try_dup.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/try_dup.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/blank.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/blank.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/dictionary.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/dictionary.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/hash.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/hash.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/assertions.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/assertions.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/numeric.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/numeric.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/boolean.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/boolean.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/lazy_array.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/lazy_array.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/time.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/time.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/datetime.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/datetime.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/hook.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/hook.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/local_object_space.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/local_object_space.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/string.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/string.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/array.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/array.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/pooling.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/pooling.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/module.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/module.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib.rb ../../gems/1.8/gems/extlib-0.9.15/lib/extlib.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/inflection.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/inflection.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/byte_array.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/byte_array.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/mash.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/mash.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/lazy_module.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/lazy_module.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/nil.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/nil.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/simple_set.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/simple_set.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/virtual_file.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/virtual_file.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/object_space.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/object_space.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/rubygems.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/rubygems.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/pathname.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/pathname.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/object.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/object.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/class.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/class.rb ruby-extlib.noarch: W: dangling-relative-symlink /usr/lib/ruby/site_ruby/1.8/extlib/symbol.rb ../../../gems/1.8/gems/extlib-0.9.15/lib/extlib/symbol.rb 1 packages and 0 specfiles checked; 0 errors, 33 warnings.
Yes, those are bogus warnings due to the symlink policy for rubygems.
I'll take this one for review.
[+] MUST: rpmlint must be run on every package A bunch of warnings, but you explained those in IRC. [+] MUST: The package must be named according to the Package Naming Guidelines [+] MUST: The spec file name must match the base package %{name} [...] [+] MUST: The package must meet the Packaging Guidelines [+] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines [+] MUST: The License field in the package spec file must match the actual license [0] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc [+] MUST: The spec file must be written in American English. [+] MUST: The spec file for the package MUST be legible. [+] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. [rrix@stinkpad rpmbuild]$ md5sum extlib-0.9.15.gem e9b1dec213911f2e681b6554a4317f5e extlib-0.9.15.gem [rrix@stinkpad rpmbuild]$ md5sum SOURCES/extlib-0.9.15.gem e9b1dec213911f2e681b6554a4317f5e SOURCES/extlib-0.9.15.gem [+] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture [0] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line [+] MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. [0] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden [0] MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [0] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [+] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [+] MUST: A package must not contain any duplicate files in the %files listing. [+] MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [+] MUST: Each package must consistently use macros. [+] MUST: The package must contain code, or permissable content. [+] MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [+] MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [0] MUST: Header files must be in a -devel package. [0] MUST: Static libraries must be in a -static package. [0] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [0] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [0] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} [+] MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. [0] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [+] MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [+] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [+] MUST: All filenames in rpm packages must be valid UTF-8. Rubygems business: [+] MUST: Packages that contain Ruby Gems must be called rubygem-%{gemname} where gemname is the name from the Gem's specification. [+] MUST: The Source of the package must be the full URL to the released Gem archive; the version of the package must be the Gem's version [+] MUST: The package must have a Requires and a BuildRequires on rubygems [+] MUST: The package must provide rubygem(%{gemname}) where gemname is the name from the Gem's specification. For every dependency on a Gem named gemdep, the package must contain a Requires on rubygem(%{gemdep}) with the same version constraints as the Gem [+] MUST: The Gem must be installed into %{gemdir} defined as %global gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null) [+] SHOULD: The install should be performed with the command gem install --local --install-dir %{buildroot}%{gemdir} --force %{SOURCE0} [+] MUST: The package must own the following files and directories: %{gemdir}/gems/%{gemname}-%{version}/ %{gemdir}/cache/%{gemname}-%{version}.gem %{gemdir}/specifications/%{gemname}-%{version}.gemspec [+] MUST: Architecture-specific content must not be installed into %{gemdir} [+] MUST: If the Gem only contains pure Ruby code, it must be marked as BuildArch: noarch. If the Gem contains binary content (e.g., for a database driver), it must be marked as architecture specific, and all architecture specific content must be moved from the %{gemdir} to the [#ruby_sitearch %{ruby_sitearch} directory] during %install Looks good. APPROVED.
(In reply to comment #10) > Looks good. APPROVED. Hi Ryan, the package is FTBFS. Could you please revoke the APPROVED? 1) The test suite is not executed at all. I would suggest to execute the test suite using spec instead of rake. That would allow to remove the patch. 2) The YARD documentation is generated in %check section. That is not correct place. 3) I would suggest to not provide the ruby subpackage unless there is real need for it. 4) If that is .spec file recycled from EPEL, I would expect to see there the original changelog. 5) The BuildRoot is not necessary unless the spec is used to build EPEL5. In that case I would suggest to put there some condition to be clear. 6) defattr in files section is not necessary anymore 7) %clean section is not required
Created attachment 515442 [details] RSpec 2.x support Please also consider execution of test suite using RSpec 2.x
Well, as I mentioned, this RPM is needed for OpenNebula 3.0 so it is required for Fedora you already have it in EPEL. Is this still FTBFS with .15? it compiled fine for me. I was told since it was dropped in Fedora this is considered a brand new package and followed process.
It compiled for me fine, as well. I can't speak for the other issues, though.
(In reply to comment #14) > It compiled for me fine, as well. I can't speak for the other issues, though. It does not build for Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=323537 And it is due to the YARD documentation, which is generated in wrong section of spec file anyway. (In reply to comment #13) > Well, as I mentioned, this RPM is needed for OpenNebula 3.0 so it is required > for Fedora you already have it in EPEL. The point is that the credits should be preserved as well as the changelog. > Is this still FTBFS with .15? it compiled fine for me. Has to build against Rawhide, since you have to import it into Rawhide first anyway. > I was told since it was dropped in Fedora this is considered a brand new > package and followed process. That is correct.
(In reply to comment #15) > (In reply to comment #14) > > It compiled for me fine, as well. I can't speak for the other issues, though. > > It does not build for Rawhide: > http://koji.fedoraproject.org/koji/taskinfo?taskID=323537 Please point to the correct URL. http://koji.fedoraproject.org/koji/taskinfo?taskID=3235379
I can copy the previous %changelog info sure. So what changes otherwise do I need to make? Take the rspec 2.x patch and we're good?
Please consider fixing all 7 points I made or provide reasoning for them.
for #3, do we still need ruby subpackages from rubygems anymore? What is the policy on this? We can ditch it if not needed, I certainly don't. For the rest, I will fix accordingly, for the BuildRoot can be dropped, but if this .spec wants to be shared with EPEL we'll still need it then?
(In reply to comment #19) > for #3, do we still need ruby subpackages from rubygems anymore? What is the > policy on this? We can ditch it if not needed, I certainly don't. It is opposite, the ruby- subpackage requires the rubygem- package. The ruby- subpackage was never mandatory. The idea was to use libraries provided as rubygem without rubygems, but the design was wrong from begin IMO. > For the rest, I will fix accordingly, for the BuildRoot can be dropped, but if > this .spec wants to be shared with EPEL we'll still need it then? Yes, you need BuildRoot for EPEL5.
Before I submit my updated .spec with the requested changes: For Rakefile and .rake tasks, do we want these packaged or throw them away? /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/Rakefile /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/tasks/ci.rake /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/tasks/metrics.rake /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/tasks/spec.rake /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/tasks/yard.rake /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/tasks/yardstick.rake Should these not go into some -devel package? What is policy for these?
(In reply to comment #21) Typically we preserve such files and treat them as a documentation [1] (of course they have to fulfill the "If it is in %doc, the included programs must run properly if it is not present." clause). It means that if there is -doc subpackage (which is present in this case), the files goes there. Your -doc %file section should look something like: %files doc %defattr(-,root,root,-) %{geminstdir}/spec %doc %{geminstdir}/README.rdoc %{geminstdir}/Rakefile %{geminstdir}/tasks %{gemdir}/doc/%{gemname}-%{version} [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
Points addressed, removed non-ruby dependency/package, merge %changelog See updates spec: Spec URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib.spec SRPM URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib-0.9.13-1.fc17.src.rpm Now tracking rawhide (fedora 17) 1) The test suite is not executed at all. I would suggest to execute the test suite using spec instead of rake. That would allow to remove the patch. -- FIXED 2) The YARD documentation is generated in %check section. That is not correct place. - FIXED, RSpec 2.x is generating yard doc automagically now. 3) I would suggest to not provide the ruby subpackage unless there is real need for it. - FIXED, removed this 4) If that is .spec file recycled from EPEL, I would expect to see there the original changelog. - FIXED, merged %changelog 5) The BuildRoot is not necessary unless the spec is used to build EPEL5. In that case I would suggest to put there some condition to be clear. - FIXED, keep incase EPEL wants to use this spec file. 6) defattr in files section is not necessary anymore - FIXED, removed 7) %clean section is not required - FIXED, removed
(In reply to comment #23) > 2) The YARD documentation is generated in %check section. That is not correct > place. > > - FIXED, RSpec 2.x is generating yard doc automagically now. I don't understand it. The YARD doc is not generated at all, which is fine IMO, since nobody expect it to be generated. So now you can use BuildRequires: rubygem(rspec-core), ruby(json) and remove the Rake and Yard from BuildRequires. I would remove also the rakefile patch, since we are not using the rakefile, it is packaged in -doc subpackage and if somebody really wants to use it, (s)he should really know what is going on. Please also remove all the ruby_sitelib macro. It is not used anywhere and moreover rpmlint is complaining about the commented out version. If you fix/explain these issues, I will have no other objections.
I thought I was since it shows some YARD documentation being generated now? No matter, do we want to though does it have any value? Will remove the Rakefile patch. Will remove the macro I'll have this one wrapped up tonight.
(In reply to comment #25) > I thought I was since it shows some YARD documentation being generated now? No > matter, do we want to though does it have any value? We are including generated RDoc documentation, which should contains the same information. I am not really sure about YARD benefits, but they are lost anyway if you do not expect that there might be something like it.
Updated, bumped to 0.9.15 also. See updates spec: Spec URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib.spec SRPM URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib-0.9.15-2.fc17.src.rpm rpmlint: PASS (with usual ruby doc warnings) mock build: PASS Please re-review
Change flag from + -> - we're not done reviewing yet
Hi Shawn, * There is still unnecessary noise in rpmlint ouput: ./rubygem-extlib.spec:2: W: macro-in-comment %global ./rubygem-extlib.spec:2: W: macro-in-comment %(ruby ./rubygem-extlib.spec:81: W: macro-in-comment %exclude ./rubygem-extlib.spec:81: W: macro-in-comment %{geminstdir} ./rubygem-extlib.spec:91: W: macro-in-comment %exclude ./rubygem-extlib.spec:91: W: macro-in-comment %{geminstdir} rubygem-extlib.src: W: strange-permission extlib-0.9.15.gem 0666L * I am not sure why are still defining the ruby_sitearch macro. I would suggest to remove lines 2-3 (sed '2,3d' rubygem-extlib.spec). Note that this would fix also one of the rpmlint complaints. * The Source0 URL is obsolete. You should use "http://rubygems.org/gems/%{gemname}-%{version}.gem" instead. * Be careful with the VERSION file. Some gems may require it for proper functionality. Nevertheless in this case, it is not mandatory, so not and issue.
Good idea on rpmlint for .spec file itself: 1) Fixed noise in comments 2) Removed sitearch macro altogether, this rubygem has no DSOs 3) Replace SOURCE0 URL with new location - URL also is valid. 4) Don't delete VERSION and keep it with the package for consistency mark as a %doc file -> /usr/lib/ruby/gems/1.8/gems/extlib-0.9.15/VERSION Spec URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib.spec SRPM URL: http://www.sh0n.net/spstarr/fedora/rubygem-extlib/rubygem-extlib-0.9.15-3.fc17.src.rpm rpmlint: PASS (with usual ruby doc warnings) RPMs rpmlint: PASS .spec file mock build: PASS
Can someone please review?
Shawn, you spec seems to be inaccessible. Could you check it please?
Sorry, I've had a hardware failure I will move the package files to my fedorapeople account.
Please find packages here: SRPM: http://fedorapeople.org/~spstarr/packages/rubygem-extlib-0.9.15-3.fc17.src.rpm SPEC: http://fedorapeople.org/~spstarr/packages/rubygem-extlib.spec
Please find packages here: updated for Ruby packaging specifications and an additional rspec compat fix in test. SRPM: http://fedorapeople.org/~spstarr/packages/rubygem-extlib-0.9.15-4.fc17.src.rpm SPEC: http://fedorapeople.org/~spstarr/packages/rubygem-extlib.spec
*** Bug 823342 has been marked as a duplicate of this bug. ***
I notice that opennebula is in fedora; is this review still needed, and if so what's the status of it? It looks like Vit took ownership of this when I fell off the planet in 2011, but it's still owned by me.
(In reply to comment #37) > It looks like Vit took ownership Not entirely ;) Not sure what is the state anymore and if that is still needed by something.
This may or may not be needed for OpenNebula anymore, however if people want it we should still package it, no? :) I just need to bump to any newer version of the rubygem.
Drop it, unless someone else wants to take this, consider it abandoned (again)