Bug 721179 - Review Request: rubygem-extlib - Support library for DataMapper and Merb
Summary: Review Request: rubygem-extlib - Support library for DataMapper and Merb
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Ryan Rix
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 823342 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-13 23:14 UTC by Shawn Starr
Modified: 2013-08-28 04:28 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-08-28 04:28:56 UTC


Attachments (Terms of Use)
RSpec 2.x support (754 bytes, patch)
2011-07-27 08:42 UTC, Vít Ondruch
no flags Details | Diff

Description Shawn Starr 2011-07-13 23:14:22 UTC
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.

Comment 1 Ulrich Schwickerath 2011-07-14 15:41:09 UTC
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)

Comment 2 Shawn Starr 2011-07-14 20:06:43 UTC
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.

Comment 4 Mamoru TASAKA 2011-07-18 00:04:13 UTC
gem list -r extlib shows that the latest is 0.9.15.

Comment 5 Shawn Starr 2011-07-18 00:28:11 UTC
I can grab .15, need to confirm it builds.. will post update in 30 mins or so

Comment 6 Shawn Starr 2011-07-18 16:50:22 UTC
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.

Comment 7 Ulrich Schwickerath 2011-07-18 18:19:59 UTC
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.

Comment 8 Shawn Starr 2011-07-18 18:32:13 UTC
Yes, those are bogus warnings due to the symlink policy for rubygems.

Comment 9 Ryan Rix 2011-07-19 17:31:18 UTC
I'll take this one for review.

Comment 10 Ryan Rix 2011-07-19 18:11:13 UTC
[+] 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.

Comment 11 Vít Ondruch 2011-07-27 07:42:47 UTC
(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

Comment 12 Vít Ondruch 2011-07-27 08:42:26 UTC
Created attachment 515442 [details]
RSpec 2.x support

Please also consider execution of test suite using RSpec 2.x

Comment 13 Shawn Starr 2011-07-27 15:21:46 UTC
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.

Comment 14 Ryan Rix 2011-07-27 21:35:34 UTC
It compiled for me fine, as well. I can't speak for the other issues, though.

Comment 15 Vít Ondruch 2011-07-28 11:45:44 UTC
(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.

Comment 16 Mamoru TASAKA 2011-07-28 12:05:30 UTC
(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

Comment 17 Shawn Starr 2011-07-28 13:54:14 UTC
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?

Comment 18 Vít Ondruch 2011-07-28 14:09:11 UTC
Please consider fixing all 7 points I made or provide reasoning for them.

Comment 19 Shawn Starr 2011-07-28 15:12:41 UTC
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?

Comment 20 Vít Ondruch 2011-07-29 06:27:35 UTC
(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.

Comment 21 Shawn Starr 2011-08-01 18:10:37 UTC
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?

Comment 22 Vít Ondruch 2011-08-02 05:50:01 UTC
(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

Comment 23 Shawn Starr 2011-08-04 01:18:58 UTC
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

Comment 24 Vít Ondruch 2011-08-04 10:22:50 UTC
(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.

Comment 25 Shawn Starr 2011-08-04 14:53:37 UTC
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.

Comment 26 Vít Ondruch 2011-08-04 15:11:58 UTC
(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.

Comment 27 Shawn Starr 2012-01-02 21:47:09 UTC
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

Comment 28 Shawn Starr 2012-01-02 21:49:37 UTC
Change flag from + -> - we're not done reviewing yet

Comment 29 Vít Ondruch 2012-01-03 11:57:29 UTC
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.

Comment 30 Shawn Starr 2012-01-03 18:24:01 UTC
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

Comment 31 Shawn Starr 2012-01-11 16:32:18 UTC
Can someone please review?

Comment 32 Vít Ondruch 2012-01-27 10:41:59 UTC
Shawn, you spec seems to be inaccessible. Could you check it please?

Comment 33 Shawn Starr 2012-01-27 14:25:36 UTC
Sorry, I've had a hardware failure I will move the package files to my fedorapeople account.

Comment 35 Shawn Starr 2012-02-10 05:08:52 UTC
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

Comment 36 Vít Ondruch 2012-05-21 07:41:31 UTC
*** Bug 823342 has been marked as a duplicate of this bug. ***

Comment 37 Ryan Rix 2013-01-25 08:22:03 UTC
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.

Comment 38 Vít Ondruch 2013-01-28 11:01:10 UTC
(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.

Comment 39 Shawn Starr 2013-08-09 17:20:32 UTC
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.

Comment 40 Shawn Starr 2013-08-28 02:03:04 UTC
Drop it, unless someone else wants to take this, consider it abandoned (again)


Note You need to log in before you can comment on or make changes to this bug.