Bug 773492

Summary: Review Request: ibsim - InfiniBand network simulator
Product: [Fedora] Fedora Reporter: Doug Ledford <dledford>
Component: Package ReviewAssignee: Jiri Popelka <jpopelka>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: fenlason, fullung, jonstanley, jpopelka, jstanley, package-review, volker27
Target Milestone: ---Flags: jpopelka: fedora-review?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1056054 (view as bug list) Environment:
Last Closed: 2014-01-21 13:33:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1056054    
Attachments:
Description Flags
ibsim spec file none

Description Doug Ledford 2012-01-11 23:27:36 UTC
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/

Comment 1 Doug Ledford 2012-01-11 23:28:13 UTC
[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.

Comment 2 Doug Ledford 2012-01-11 23:28:38 UTC
Created attachment 552254 [details]
ibsim spec file

Comment 3 Albert Strasheim 2012-01-12 05:52:13 UTC
Looks good.

Comment 4 Jiri Popelka 2012-06-29 14:28:23 UTC
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.

Comment 5 Jon Stanley 2012-10-22 19:58:14 UTC
I'll take this review from Doug after talking with him. I'll get this one taken care of shortly.

Comment 7 Volker Fröhlich 2013-04-17 15:44:30 UTC
I think you should open a new review request then.

Comment 8 Jon Stanley 2013-04-17 18:22:54 UTC
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.

Comment 9 Thomas Moschny 2013-04-27 18:45:08 UTC
(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.

Comment 10 Volker Fröhlich 2014-01-18 23:55:57 UTC
Now how is this going to continue?

Comment 11 Jiri Popelka 2014-01-20 12:43:51 UTC
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

Comment 12 Jon Stanley 2014-01-21 13:33:10 UTC
Sure thing.

Since there's nothing different from this bug other than the maintainer, I'm just going to clone it.