Bug 487521 - Review Request: pypar - Parallel programming with Python
Summary: Review Request: pypar - Parallel programming with Python
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-26 14:46 UTC by Susi Lehtola
Modified: 2009-07-03 19:50 UTC (History)
3 users (show)

Fixed In Version: 2.1.0_66-3.fc10
Clone Of:
Environment:
Last Closed: 2009-07-03 19:43:46 UTC
Type: ---
Embargoed:
j: fedora-review+
j: fedora-cvs+


Attachments (Terms of Use)

Description Susi Lehtola 2009-02-26 14:46:33 UTC
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 13:38:09 UTC
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 22:54:39 UTC
Using %{__python} instead of python is unnecessary and bad style, IMO.

Comment 3 Susi Lehtola 2009-03-20 23:02:42 UTC
(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 23:22:57 UTC
So it is. Weird.

Comment 5 Jason Tibbitts 2009-03-25 21:27:57 UTC
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 21:41:29 UTC
(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 11:20:26 UTC
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 20:00:56 UTC
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 20:14:56 UTC
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 15:41:20 UTC
CVS done.

Comment 11 Fedora Update System 2009-06-04 20:30:13 UTC
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 20:31:04 UTC
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-16 02:16:05 UTC
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-16 02:35:13 UTC
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 19:43:41 UTC
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 19:50:13 UTC
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.