Bug 823344

Please note that rubygem-ohai was already in Fedora: https://admin.fedoraproject.org/pkgdb/acls/name/rubygem-ohai

Is there a different process I should be following to resurrect the old package?  I do know the person who was working on the packages in the past, and have confirmed that he doesn't have any plans to re-take the maintenance role on this package (or the other several packages that are also retired).

(In reply to comment #2)
> Is there a different process I should be following to resurrect the old
> package?

This is the procedure [1]. For the review, the process it the same, just when you are doing SCM request, you should do "Package change request" [2] instead of requesting new repository.



[1] https://fedoraproject.org/wiki/Extras/OrphanedPackages#Claiming_Ownership_of_a_Deprecated_Package

[2] http://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages

Hi Jonas,
   for this specific package, would you mind if you also do it for EPEL from the beginning? if maintaining effort is the only blocker i could happily co-maintain it.

   I'll do an informal (as i can't sponsor you) review later on this. If someone else sponsor you for any other package we can change it to a formal one to proceed :).

Christos

PS: I was planning to put a rubygems-ohai review request this week anyway :)

Yes, I do plan on maintaining Chef and related packages (including rubygem-ohai) for EPEL 6 as well.  I've created the initial spec files, and do plan on submitting them shortly.  Since this is my first set of package submissions, the plan is to tackle the Fedora side first.

Updated:
-------
SPEC URL: https://raw.github.com/jcourteau/rubygems-rpms/master/fc17/rubygem-ohai/rubygem-ohai.spec
SRPM URL: http://rpms.courteau.org/fedora/rubygem-ohai-0.6.12-2.fc17.src.rpm

- found a workaround for a previously disabled test
- updated URLs
- removed tests from final package

ping! any updates on this?

Bobby et. al.: I've started working on these under the auspices of http://tickets.opscode.com/browse/CHEF-522. If you can lend any testing/review efforts I would be most appreciative.

Julian, the name of the package should be changed from 'rubygem-ohai' to just 'ohai' as per the naming guidelines, because it provides user space tools/utilities.

See: https://fedoraproject.org/w/index.php?title=Packaging:Ruby&oldid=306009#Naming_Guidelines

(In reply to comment #9)
> Julian, the name of the package should be changed from 'rubygem-ohai' to
> just 'ohai' as per the naming guidelines, because it provides user space
> tools/utilities.
> 
> See:
> https://fedoraproject.org/w/index.php?title=Packaging:
> Ruby&oldid=306009#Naming_Guidelines

Completely agree with you. Chef will also be named "chef" when I get to that point.

Right now we're blocked on yajl-ruby vendoring the YAJL C library (see bz#823351); after the patch gets accepted and YAJL is in Fedora, I'll rebuild the Ohai RPM with the right name.

Julian, sounds great. I am currently playing with building chef and its dependency packages.

I have noticed some issues with your spec files. Shall I submit a pull request with my fixes?

Definitely! I have neglected the chef/ohai specs while dealing with the deps but feel free to correct any errors of mine (or Jonas's)

https://github.com/juliandunn/rubygems-rpms

(In reply to comment #10)
> (In reply to comment #9)
> > Julian, the name of the package should be changed from 'rubygem-ohai' to
> > just 'ohai' as per the naming guidelines, because it provides user space
> > tools/utilities.
> > 
> > See:
> > https://fedoraproject.org/w/index.php?title=Packaging:
> > Ruby&oldid=306009#Naming_Guidelines
> 
> Completely agree with you. Chef will also be named "chef" when I get to that
> point.

I am unsure about it. This refers especially to applications as described in application section of Ruby guidelines [1]. Not sure if this is the case for Chef, but this is what Ohai upstream says about Ohai:

"It can be used standalone, but its primary purpose is to provide node data to Chef."

According to this statement, Ohai should be packaged as a gem and named according to it, i.e. rubygem-ohai.


[1] https://fedoraproject.org/wiki/Packaging:Ruby#Applications

Here is the updated spec and SRPM for Ohai 7.0.4, patched to use ffi-yajl. I'm comfortable using the patch because it's the same one going into future versions of Ohai and is already in Ohai master.

https://github.com/opscode/ohai/commit/86b123e52e59a00f7a48da7479a40df72e1cfbd7

Spec: https://fedorapeople.org/~jdunn/rubygem-ohai/rubygem-ohai.spec
SRPM: https://fedorapeople.org/~jdunn/rubygem-ohai/rubygem-ohai-7.0.4-1.fc21.src.rpm

There are a few errors from rpmlint:

rubygem-ohai.noarch: E: devel-dependency yajl-devel
rubygem-ohai.noarch: E: useless-provides rubygem(ohai)

The first one is necessary because FFI tries to load by using 'libyajl.so', however only the devel package provides this symlink. Let me know if this is acceptable or if it is something to be raised with the yajl maintainer.

The second I am ignoring because it is necessary to build on EPEL, which I will work on after this is accepted into Fedora.

This is an automatic check from review-stats script.

This review request ticket hasn't been updated for some time. We're sorry
it is taking so long. If you're still interested in packaging this software
into Fedora repositories, please respond to this comment clearing the
NEEDINFO flag.

You may want to update the specfile and the src.rpm to the latest version
available and to propose a review swap on Fedora devel mailing list to increase
chances to have your package reviewed. If this is your first package and you
need a sponsor, you may want to post some informal reviews. Read more at
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group.

Without any reply, this request will shortly be considered abandoned
and will be closed.
Thank you for your patience.

This is an automatic action taken by review-stats script.

The ticket submitter failed to clear the NEEDINFO flag in a month.
As per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
we consider this ticket as DEADREVIEW and proceed to close it.