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-1.fc17.src.rpm
Description: Ohai detects data about your operating system and prints out a JSON data blob.
It can be used standalone, but it's primary purpose is to provide node data to
This is part of a set of dependencies for rubygem-chef. I've got about 14 packages to add, all ruby gems, and am looking for a sponsor. Several of the packages were previously in Fedora (F11 and F12), but were removed due to lack of a maintainer.
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
This is the procedure . For the review, the process it the same, just when you are doing SCM request, you should do "Package change request"  instead of requesting new repository.
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 :).
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.
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.
(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
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)
(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
I am unsure about it. This refers especially to applications as described in application section of Ruby guidelines . 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.
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.
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.