[Bug 619355] Review Request: python26-numpy - A fast multidimensional array facility for Python

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=619355

--- Comment #17 from Jerry James <loganjerry at gmail.com> 2011-04-28 18:35:18 EDT ---
I have a couple of observations before getting to the standard review items. 
First, I saw a lot of warnings about code that breaks strict aliasing rules.  I
suggest adding -fno-strict-aliasing to CFLAGS, else you may see some subtly
weird behavior at runtime.

Second, I don't understand why both lapack-devel and atlas-devel are BRs.  The
atlas package provides a lapack replacement (%{_libdir}/atlas/liblapack.so.3). 
The only ELF object I can find that is linked to liblapack,
linalg/lapack_lite.so, is indeed linked to %{_libdir}/atlas/liblapack.so.3. 
Why is lapack-devel a BR?

Third, totally trivial, but 's/in in/be in/' on line 118 of the spec file.

rpmlint output:
python26-numpy.x86_64: W: no-soname
/usr/lib64/python2.6/site-packages/numpy/lib/_compiled_base.so
python26-numpy.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/python2.6/site-packages/numpy/lib/_compiled_base.so
/lib64/libpthread.so.0
python26-numpy-devel.x86_64: W: no-documentation
python26-numpy-f2py.x86_64: W: manpage-not-compressed bz2
/usr/share/man/man1/f2py2.6.1.gz
python26-numpy-f2py.x86_64: E: devel-dependency python26-devel
python26-numpy-f2py.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/python2.6/site-packages/numpy/f2py/tests/src/array_from_pyobj/wrapmodule.c
python26-numpy-f2py.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/python2.6/site-packages/numpy/f2py/src/fortranobject.h
python26-numpy-f2py.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/python2.6/site-packages/numpy/f2py/src/fortranobject.c
python26-numpy-f2py-tests.x86_64: E: devel-dependency python26-devel
python26-numpy-f2py-tests.x86_64: W: no-documentation
python26-numpy-f2py-tests.x86_64: W: devel-file-in-non-devel-package
/usr/lib64/python2.6/site-packages/numpy/f2py/tests/src/array_from_pyobj/wrapmodule.c
python26-numpy-tests.x86_64: W: no-documentation
6 packages and 1 specfiles checked; 2 errors, 10 warnings.

#1, #3, #10, #12: appear inconsequential.
#2: it would be good to not link lib/_compiled_base.so against -lpthread if
that isn't impossible to arrange.
#4: rpmlint has apparently gone insane, since ALL man pages are gz compressed
#5-#8: these appear to be a consequence of python26-numpy-f2py being a
"stealth" devel package
#9, #11: ditto for python26-numpy-f2py-tests

So it looks like only #2 needs attention.  You only get that warning if you run
rpmlint on the installed package, by the way; checking the binary rpm won't
trigger this warning.

+: OK
-: Must fix
=: Needs attention (but not a review blocker)
N: Not applicable

MUST items:
[=] rpmlint output: shown above
[+] Package name follows the Package Naming Guidelines
[+] Spec file name matches the base package name
[+] Package meets the Packaging Guidelines
[+] Package has a Fedora-approved license
[=] License field matches the actual license
[+] Iff the license appears in a file, that file is in %doc.
[+] Spec file is in American Engligh
[+] Spec file is legible
[+] Sources match the upstream sources: md5sum is
376ef150df41b5353944ab742145352d
[+] Source RPM builds on a least one arch: x86_64
[N] Appropriate use of ExcludeArch
[+] BuildRequires for all build-time dependencies
[N] Proper handling of locales
[N] Proper use of ldconfig in %post and %postun
[+] No bundled copies of system libraries
[N] No relocatable packages
[+] Package owns all directories it creates
[+] No duplicates in %files
[+] Appropriate permissions on files
[+] Consistent use of macros
[+] Package contains code or permissible content
[+] Large documentation goes into a -doc subpackage
[+] No runtime dependencies in %doc
[+] Header files in -devel
[N] Static libraries in -static
[N] If a shared library has a suffix, then a .so symlink is in -devel
[=] -devel has a fully versioned Requires on the main package: this should be
%{name}%{?_isa} in Fedora, but I don't know if that is the case in EPEL
[+] No libtool archives in the binary packages
[N] GUI applications install a desktop file
[+] Does not own any files/dirs owned by other packages
[+] All filenames are valid UTF-8

SHOULD items:
[N] Query upstream to include a missing license file
[N] Description and summary should contain translations, if available
[+] Package builds in mock: tried epel-5-x86_64
[=] Package builds on all supported arches: only tried x86_64
[=] Package functions as described: minimal testing only
[N] Sane scriptlets
[+] All subpackages require the main package
[N] Good pkgconfig file placement
[+] Package dependencies instead of file dependencies
[+] Package has man pages for binaries/scripts

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.