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 <loganje...@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. _______________________________________________ package-review mailing list package-review@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/package-review
