ibsim allows you to create a topology file that represents your InfiniBand fabric and then hook the ibsim application in between your end user application and the fabric itself and then use ibsim to create fake fabric events that your application will then see (such as link up/link down/packet loss/etc). If you aren't well versed in InfiniBand fabric management or know what a MAD packet is, this application is not for you. It is a very low level, get your hands dirty program. However, to someone who wants to see exactly how an application will perform under specific circumstances it will simulate those circumstances without the application knowing the difference between the simulation or the real event. Packages can be found at: http://people.redhat.com/dledford/Package%20Review/
[dledford@schwoop SPECS]$ rpmlint ibsim.spec ../SRPMS/ibsim-0.5-5.fc15.src.rpm ../RPMS/x86_64/ibsim-* ibsim.src: W: spelling-error %description -l en_US infiniband -> infinitude ibsim.x86_64: W: spelling-error %description -l en_US infiniband -> infinitude ibsim.x86_64: W: no-manual-page-for-binary ibsim 3 packages and 1 specfiles checked; 0 errors, 3 warnings.
Created attachment 552254 [details] ibsim spec file
Looks good.
Package Review ============== Key: - = N/A x = Pass ! = Fail ==== C/C++ ==== [-]: MUST Header files in -devel subpackage, if present. [x]: MUST Package does not contain any libtool archives (.la) [x]: MUST Package does not contain kernel modules. [x]: MUST Rpath absent or only used for internal libs. [x]: MUST Package is not relocatable. [x]: MUST Development (unversioned) .so files in -devel subpackage, if present. %{_libdir}/umad2sim/libumad2sim.so is ok in main package because it's not used for development. Also there seem to be no versioned library files installed, so %{_libdir}/umad2sim/libumad2sim*.so* could be I think changed to %{_libdir}/umad2sim/libumad2sim.so ==== Generic ==== [x]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: MUST %build honors applicable compiler flags or justifies otherwise. [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [!]: MUST Buildroot is not present See https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag [x]: MUST Package contains no bundled libraries. [x]: MUST Changelog in prescribed format. [!]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) See https://fedoraproject.org/wiki/Packaging/Guidelines#.25clean [x]: MUST Sources contain only permissible code or content. [!]: MUST Each %files section contains %defattr if rpm < 4.4 No need to use %defattr macro, see https://fedoraproject.org/wiki/Packaging/Guidelines#File_Permissions [x]: MUST Macros in Summary, %description expandable at SRPM build time. [-]: MUST Package requires other packages for directories it uses. [x]: MUST Package uses nothing in %doc for runtime. [!]: MUST Package is not known to require ExcludeArch. see https://fedoraproject.org/wiki/Architectures#ExcludeArch_.26_ExclusiveArch https://fedoraproject.org/wiki/Architectures#Tracker_Bugs https://fedoraproject.org/wiki/Packaging/Guidelines#Architecture_Build_Failures [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Spec file lacks Packager, Vendor, PreReq tags. [!]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. See https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag [-]: MUST Large documentation files are in a -doc subpackage, if required. [x]: 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 is included in %doc. [x]: MUST License field in the package spec file matches the actual license. [x]: MUST Package consistently uses macros (instead of hard-coded directory names). [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST Package does not generate any conflict. [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [!]: MUST Package must own all directories that it creates. It creates %{_libdir}/umad2sim/, doesn't it ? [x]: MUST Package does not own files or directories owned by other packages. [x]: MUST Package installs properly. [x]: MUST Requires correct, justified where necessary. [x]: MUST Rpmlint output is silent. Just some harmless warnings. [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. MD5SUM this package : 8f4928dbee64b0c0caaf838d03d95a86 MD5SUM upstream package : 8f4928dbee64b0c0caaf838d03d95a86 [x]: MUST Spec file is legible and written in American English. [x]: MUST Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: MUST File names are valid UTF-8. [x]: MUST Useful -debuginfo package or justification otherwise. [x]: SHOULD Reviewer should test that the package builds in mock. [x]: SHOULD Dist tag is present. [x]: SHOULD Latest version is packaged. [x]: SHOULD SourceX is a working URL. I didn't find any openib[-diag] package, so I think the Conflicts: openib-diags < 1.3 line could be removed.
I'll take this review from Doug after talking with him. I'll get this one taken care of shortly.
New SRPM: http://jstanley.fedorapeople.org/ibsim-0.5-6.20120810git.fc19.src.rpm New spec: http://jstanley.fedorapeople.org/ibsim.spec
I think you should open a new review request then.
Huh? This is just a change in maintainer from Doug to me. I'll happily open a new request if wanted, but it doesn't seem to apply in this case.
(In reply to comment #8) > Huh? This is just a change in maintainer from Doug to me. I'll happily open > a new request if wanted, but it doesn't seem to apply in this case. The last section in http://fedoraproject.org/wiki/Policy_for_stalled_package_reviews can be read in such a way that when the original submitter is not going to finish the submission, a new ticket shall be opened by the new/next submitter. While meant for the case of a not responding submitter, I'd say the procedure itself also fits here.
Now how is this going to continue?
Wow, looks like the one who's actually been unresponsive here has been me - no idea why I haven't responded to comment #6. Anyway, Jon, as others pointed out it'd probably be better to fill a new request and make this one duplicate of it. Could you do that ? Thanks
Sure thing. Since there's nothing different from this bug other than the maintainer, I'm just going to clone it.