Red Hat Bugzilla – Bug 487521
Review Request: pypar - Parallel programming with Python
Last modified: 2009-07-03 15:50:19 EDT
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.
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.
Using %{__python} instead of python is unnecessary and bad style, IMO.
(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
So it is. Weird.
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.
(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.
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.)
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
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:
CVS done.
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
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
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
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
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.
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.