Bug 487521 - Review Request: pypar - Parallel programming with Python
Review Request: pypar - Parallel programming with Python
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-26 09:46 EST by Susi Lehtola
Modified: 2009-07-03 15:50 EDT (History)
3 users (show)

See Also:
Fixed In Version: 2.1.0_66-3.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-03 15:43:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Susi Lehtola 2009-02-26 09:46:33 EST
Spec URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/pypar.spec

SRPM URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/pypar-2.1.0_53-1.fc10.src.rpm

Description:
Pypar is an efficient but easy-to-use module that allows programs written in
Python to run in parallel on multiple processors and communicate using message
passing. Pypar provides bindings to a subset of the message passing interface
standard MPI.

rpmlint output:
pypar.x86_64: W: devel-file-in-non-devel-package /usr/share/pypar-2.1.0_53/demos/mandelbrot_example/mandelplot_ext.c
pypar.x86_64: E: non-executable-script /usr/share/pypar-2.1.0_53/demos/demo3.py 0644
pypar.x86_64: E: non-executable-script /usr/lib64/python2.5/site-packages/pypar/test_init.py 0644
pypar.x86_64: E: non-executable-script /usr/lib64/python2.5/site-packages/pypar/network_timing.py 0644
pypar.x86_64: E: non-executable-script /usr/share/pypar-2.1.0_53/demos/demo.py 0644
pypar.x86_64: E: non-executable-script /usr/share/pypar-2.1.0_53/demos/demo4.py 0644
pypar.x86_64: E: non-executable-script /usr/lib64/python2.5/site-packages/pypar/test_pypar.py 0644
pypar.x86_64: E: non-executable-script /usr/share/pypar-2.1.0_53/demos/mandelbrot_example/mandel_sequential.py 0644
pypar.x86_64: W: devel-file-in-non-devel-package /usr/share/pypar-2.1.0_53/demos/mandelbrot_example/mandel_ext.c
pypar.x86_64: E: non-executable-script /usr/share/pypar-2.1.0_53/demos/demo2.py 0644
2 packages and 0 specfiles checked; 8 errors, 2 warnings.


Contacted upstream to fix the non-executable-script errors.

devel-file-in-non-devel-package warnings should not cause any concern, since they are demo files for using the package.
Comment 1 Susi Lehtola 2009-03-02 08:38:09 EST
Merged patches with upstream.

Spec URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/pypar.spec

SRPM URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/pypar-2.1.0_66-1.fc10.src.rpm


rpmlint output:
pypar-examples.x86_64: W: no-documentation
pypar-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/pypar-2.1.0_66/demos/mandelbrot_example/mandel_ext.c
pypar-examples.x86_64: W: devel-file-in-non-devel-package /usr/share/pypar-2.1.0_66/demos/mandelbrot_example/mandelplot_ext.c
3 packages and 1 specfiles checked; 0 errors, 3 warnings.

The warnings are expected, since examples contain source code.
Comment 2 Conrad Meyer 2009-03-20 18:54:39 EDT
Using %{__python} instead of python is unnecessary and bad style, IMO.
Comment 3 Susi Lehtola 2009-03-20 19:02:42 EDT
(In reply to comment #2)
> Using %{__python} instead of python is unnecessary and bad style, IMO.  

Well, that's the way it's in the guidelines:
http://fedoraproject.org/wiki/Packaging/Python
Comment 4 Conrad Meyer 2009-03-20 19:22:57 EDT
So it is. Weird.
Comment 5 Jason Tibbitts 2009-03-25 17:27:57 EDT
Would it make more sense to package those examples as documentation?  Or will this package somehow compile them.  If it will, shouldn't it have some sort of dependency on a compiler?  I guess the point is that if you want to package the example up so that it works (instead of just sticking it in a documentation directory), you should actually make sure that it's functional.  According to the README, it also wants eog to be present.
Comment 6 Susi Lehtola 2009-03-25 17:41:29 EDT
(In reply to comment #5)
> Would it make more sense to package those examples as documentation?  Or will
> this package somehow compile them.  If it will, shouldn't it have some sort of
> dependency on a compiler?  I guess the point is that if you want to package the
> example up so that it works (instead of just sticking it in a documentation
> directory), you should actually make sure that it's functional.  According to
> the README, it also wants eog to be present.  

The examples (and everything else too) works just with the package itself, the Python library accesses the MPI library.

Hmm, the eog dependency seems to be only in the mandelbrot example. I wouldn't add eog as a dependency since everything else works without it. Same thing goes for gcc: it's only needed if your software tries to integrate C modules in the parallel Python program.

I can put the examples into %doc but that'll cause a bunch of rpmlint warnings since the distinction between executables and libraries is blurry in Python (unexecutable script warnings / missing shebangs / etc). Maybe it's the best choice since it's true that the files in datadir should work straight away.
Comment 7 Susi Lehtola 2009-05-15 07:20:26 EDT
Okay, fixed everything. rpmlint output is clean.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/pypar.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/pypar-2.1.0_66-2.fc10.src.rpm

(I didn't add eog as a requirement since it's only a requirement for the one example.)
Comment 8 Jason Tibbitts 2009-06-03 16:00:56 EDT
Looks good to me.

* source files match upstream.  sha256sum:
   0c0155ad75c3cc73bf3d5a25e7e96e50b7dbf3f7f924c9c84d7f1dec8484925c
   pypar-2.1.0_66.tgz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint is silent.
* final provides and requires are sane:
   mpiext.so()(64bit)
   pypar = 2.1.0_66-2.fc11
   pypar(x86-64) = 2.1.0_66-2.fc11
  =
   libmpi.so.0()(64bit)
   libopen-pal.so.0()(64bit)
   libopen-rte.so.0()(64bit)
   libpython2.6.so.1.0()(64bit)
   numpy
   python(abi) = 2.6

* %check is not present; no test suite upstream.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no static libraries.
* no libtool .la files.

APPROVED
Comment 9 Susi Lehtola 2009-06-03 16:14:56 EDT
Thanks for picking this up and for the review!

New Package CVS Request
=======================
Package Name: pypar
Short Description: Parallel programming with Python
Owners: jussilehtola
Branches: EL-5 F-10 F-11
InitialCC:
Comment 10 Jason Tibbitts 2009-06-04 11:41:20 EDT
CVS done.
Comment 11 Fedora Update System 2009-06-04 16:30:13 EDT
pypar-2.1.0_66-3.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/pypar-2.1.0_66-3.fc10
Comment 12 Fedora Update System 2009-06-04 16:31:04 EDT
pypar-2.1.0_66-3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/pypar-2.1.0_66-3.fc11
Comment 13 Fedora Update System 2009-06-15 22:16:05 EDT
pypar-2.1.0_66-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pypar'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6350
Comment 14 Fedora Update System 2009-06-15 22:35:13 EDT
pypar-2.1.0_66-3.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pypar'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-6417
Comment 15 Fedora Update System 2009-07-03 15:43:41 EDT
pypar-2.1.0_66-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2009-07-03 15:50:13 EDT
pypar-2.1.0_66-3.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.