While at it, could you also revisit the -devel package header location? /usr/share instead of /usr/include is highly questionable, not only because the sample doesn't adjust the search path for headers either:

$ rpmls -p ipmiutil-devel-2.8.3-1.fc18.x86_64.rpm 
-rw-r--r--  /usr/lib64/libipmiutil.a
-rw-r--r--  /usr/share/ipmiutil/Makefile
-rw-r--r--  /usr/share/ipmiutil/ipmi_sample.c
-rw-r--r--  /usr/share/ipmiutil/ipmicmd.h

OK, proposed changes made to ipmiutil.spec (attached).
This will go into the upstream and a patch to fc18 will be added, if this is ok.

Created attachment 582143 [details]
ipmiutil.spec with changes

Hmmm, that spec file wouldn't pass the review process. Has the packaging changed so much since its initial version?

This bug report has been opened automatically by a script. I didn't mean to re-review your package, but there are several issues with it now that I've had a look at the spec file. Please run rpmlint on the src.rpm and the built rpms. It finds a couple of bugs as a start. Try to review your package based on this page:

  https://fedoraproject.org/wiki/Packaging:ReviewGuidelines


> %post devel
> /sbin/ldconfig

There doesn't make sense, because there are no shared libs within the package(s), and even if there were, typically one doesn't run ldconfig in the -devel package but in the base library package.

Yes, it has undergone some changes, particularly around systemd support.
Attached is an updated ipmiutil.spec which looks rpmlint clean.

Created attachment 582159 [details]
ipmiutil.spec with rpmlint fixes

Does this attachment 582159 [details] look ok?

Yeah, it would fix the static lib package bug. :)

With regard to other albeit unrelated issues:


> BuildRequires: openssl-devel gcc gcc-c++ libtool

https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2

Not a MUST item, though. However, omitting "gcc gcc-c++" in BuildRequires make it easier to build packages in an altered build environment with replaced compilers.


> %define systemd_fls %{_datadir}/%{name}
> %define init_dir  %{_initrddir}

https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define


> %package devel
> [...]
> Requires: ipmiutil

https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package

Since it's a -static-only -devel package, I guess it does not need the base package to be usable when compiling something. It just shares a directory with the base package to store the example source in. You could include the directory entry in both packages and drop the explicit dependency (if directory ownership is the only reason for it) and add a comment to the spec file:

https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function


> make

https://fedoraproject.org/wiki/Packaging:Guidelines#Parallel_make

Implemented the other changes, but I differ on the 'BuildRequires: gcc gcc++'.
I have seen more occurrences of VM auto-build systems that don't auto-install gcc and I have built cleanly without any issues in several custom compiler build environments.

Created attachment 586901 [details]
ipmiutil.spec with style changes from comment #8

I'll submit the new files to Fedora rawhide soon as a fix for this bug.

ipmiutil-2.8.4-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/ipmiutil-2.8.4-1.fc16

Package ipmiutil-2.8.4-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ipmiutil-2.8.4-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9366/ipmiutil-2.8.4-1.fc16
then log in and leave karma (feedback).

ipmiutil-2.8.4-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

ipmiutil-2.8.5-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/ipmiutil-2.8.5-2.fc18

ipmiutil-2.8.5-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Reopened by: fedora-report-static-batch.py

Build: ipmiutil-2.9.4-1.fc22.src.rpm

ipmiutil-devel
    /usr/lib/libipmiutil.so  <=>  /usr/lib/libipmiutil.a

OK, what is the non-compliance with this?  It doesn't say.

[yep, I need to update the hardcoded texts in the script]

It's this:

https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries_2

1. Static libraries and shared libraries. In this case, the static libraries must be placed in a *-static subpackage. Separating the static libraries from the other development files in *-devel allow us to track this usage by checking which packages BuildRequire the *-static package. The intent is that whenever possible, packages will move away from using these static libraries, to the shared libraries.

Oh, ipmiutil is mispackaged, btw. It includes the shared runtime library in the -devel subpackage:

  http://koji.fedoraproject.org/koji/rpminfo?rpmID=5550122
  http://pkgs.fedoraproject.org/cgit/ipmiutil.git/commit/?id=f912a15915f8fda5257dc5d372793dde17312754

Yes, I have added the shared library to the devel package, so now that this is no longer a static-only package, I need to move the static library into a '-static' package.

The upstream ipmiutil-2.9.5 now includes a compliant spec file separating out the static lib into a -static package.
I'll apply that to the fedora rawhide shortly.  

BTW, I had a request to apply the ipmiutil package to epel7, but I don't seem to have access to do that.  How do I get access to epel7?

https://fedoraproject.org/wiki/EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F

Closed by: fedora-report-static-batch.py
http://mschwendt.fedorapeople.org/staticbugstat.html