+++ This bug was initially created as a clone of Bug #450483 +++ +++ This bug was initially created as a clone of Bug #450482 +++ +++ This bug was initially created as a clone of Bug #450481 +++ +++ This bug was initially created as a clone of Bug #450470 +++ This is the Open Fabrics Alliance Infiniband Subnet Manager (OpenSM). It's responsible for assigning a link ID to all members of the fabric, determining routing via one of several routing algorithms, and other tasks. If you have an IB fabric with a dumb switch (meaning one without a built in SM, or one where the SM is turned off), then you must have opensm (or another SM) up and running on the fabric in order to be able to communicate with other hosts. As such, this is an essential element of the IB network stack. This package relies upon the libibumad package this bug was cloned from. src rpm can be found under http://people.redhat.com/dledford/Infiniband/f10/SRPMS/ x86_64 rpms can be found under http://people.redhat.com/dledford/Infiniband/f10/x86_64/
Hi Doug, thank you for submitting an opensm package for Fedora. Here is a quick review: GOOD: + source matches upstream: f2f47a9bad4ba3ed1c48361dfc8f21826882b7cb opensm-3.2.1.tar.gz f2f47a9bad4ba3ed1c48361dfc8f21826882b7cb opensm-3.2.1.tar.gz.UP + license is correct and correctly included + permissions look good + dir ownership looks good + with dependencies installed, local builds on F8 x86_64 succeed + rpmlint reports: opensm.src: W: strange-permission opensm.initd 0775 opensm.x86_64: W: non-conffile-in-etc /etc/logrotate.d/opensm opensm.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/osmtest ['/usr/lib64', '/u/u0/ehill/rpmbuild/BUILD/opensm-3.2.1/osmtest/../../libibumad/.libs', '/u/u0/ehill/rpmbuild/BUILD/opensm-3.2.1/osmtest/../../libibcommon/.libs'] opensm.x86_64: E: binary-or-shlib-defines-rpath /usr/sbin/opensm ['/usr/lib64', '/u/u0/ehill/rpmbuild/BUILD/opensm-3.2.1/opensm/../../libibumad/.libs', '/u/u0/ehill/rpmbuild/BUILD/opensm-3.2.1/opensm/../../libibcommon/.libs'] opensm.x86_64: W: dangerous-command-in-%preun rm opensm.x86_64: E: malformed-line-in-lsb-comment-block # opensm-devel.x86_64: W: no-documentation opensm-libs.x86_64: W: no-documentation opensm-libs.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/libosmvendor.so.2.0.0 ['/usr/lib64'] opensm-libs.x86_64: W: one-line-command-in-%post /sbin/ldconfig opensm-libs.x86_64: W: one-line-command-in-%postun /sbin/ldconfig opensm-static.x86_64: W: no-documentation NEEDSWORK: + First, the rpath issues. I've tried to put together a patch that removes the rpaths from the configure script and some of the Makefile.in-s but so far I've failed to remove all of them. And, removing some of the rpaths breaks the install since certain *.la{i,} files won't get generated. Perhaps someone with stronger hack-fu can (please?) take a look at it? Or, perhaps we can just ignore these rather-annoying rpath warnings since it is something specific to just these two opensm executables (and cannot cause any std-path problems for other packages since they are not shared libs). + Please delete the blank line in the LSB comment block. + Please use '%post libs -p /sbin/ldconfig' and '%postun libs -p /sbin/ldconfig' I haven't (yet) had the time to install and run it on a machine with IB hardware -- will try that next.
I fixed the two easy items. The rpath item is going to need to be run through upstream. Whenever you have a package with a bunch of junk like this in Makefile.in's and the configure script, the correct way to *attempt* to fix it is to modify the Makefile.am's and configure.in and then run autoreconf (which will also rerun automake). However, once I did that, it became clear that there is some incompatibility or some switch I'm missing in my setup that the maintainer uses to run automake on these sources because my devel environment throws loads of errors over the contents of the Makefile.am files. So, I'll go talk to the upstream maintainer and see about both A) what's going on with automake and B) getting the changes in upstream directly so I don't have to carry a patch forever.
Do you think it would make sense to use the "last resort" option described in the Guidelines: chrpath --delete $RPM_BUILD_ROOT%{_bindir}/* as a temporary measure (assuming it works)? That would remove the rpath blocker and allow me to approve the package. Then (or perhaps simultaneously?) the work you describe could be done to improve the upstream build setup? Its just a suggestion... :-)
Actually, I'm close to having a fixed version already. The upstream maintainer has already replied and I figured out what I was doing wrong in trying to run autoreconf (automake needs the --foreign flag to work with these Makefile.am files). I should have something soon that meets all the criteria I think.
OK, new versions of the files uploaded that solve the rpath problem properly. I'll also send the patch upstream, although I don't know if they'll take it just because they might want to keep things the way they are for devel purposes. As before, files have the same name and have been copied over the old files, so you might have to force a refresh if there is a web cache between you and people.redhat.com.
Cool, that was quick! :-) I just downloaded and built the new version and the rpath problem is gone. I don't see any blockers so its APPROVED.
Awesome, thanks ;-) New Package CVS Request ======================= Package Name: opensm Short Description: OpenIB InfiniBand Subnet Manager and management utilities Owners: dledford Branches: F-8 F-9 InitialCC: Cvsextras Commits: yes
cvs done.