This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 165398 - Review Request: python-numarray - Python array manipulation and computational library
Review Request: python-numarray - Python array manipulation and computational...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ed Hill
Fedora Package Reviews List
http://www.cora.nwra.com/~orion/fedora
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2005-08-08 16:31 EDT by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-11 17:23:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2005-08-08 16:31:45 EDT
Spec Name or Url: python-numarray.spec
SRPM Name or Url: python-numarray-1.3.3-1.src.rpm
Description: 

Numarray provides array manipulation and computational capabilities similar to those found in IDL, Matlab, or Octave. Using numarray, it is possible to write many efficient numerical data processing applications directly in Python without using any C, C++ or Fortran code (as well as doing such analysis interactively within Python or PyRAF). For algorithms that are not well suited for efficient computation using array facilities it is possible to write C functions (and eventually Fortran) that can read and write numarray arrays that can be called from Python.

Numarray is a re-implementation of an older Python array module called Numeric. In general its interface is very similar. It is mostly backward compatible and will be becoming more so in future releases. Numarray offers more capability than Numeric but is still behind Numeric in some areas:


http://www.stsci.edu/resources/software_hardware/numarray


A question here - there are include files in this package, that perhaps need to be put into a -devel package, but all the libraries are .so, and presumably need to be in the main package.
Comment 1 Ed Hill 2005-08-09 11:01:23 EDT
Hi Orion, I don't know the "right" answer to the include files.  I suppose 
it would be good to look at how other people package Python headers.  Or, 
maybe someone can step in and explain whats best...?

I did manage to build it on FC-4 and rpmlint threw up a handful of warnings 
and two errors:

  W: python-numarray devel-file-in-non-devel-package
     /usr/include/python2.4/numarray/arrayobject.h

  ...more devel-file-in-non-devel-package warnings skipped...

  E: python-numarray backup-file-in-package
     /usr/share/doc/python-numarray-1.3.3/release_notes/ANNOUNCE-1.3.~1.4.~
  E: python-numarray non-executable-script 
     /usr/lib/python2.4/site-packages/numarray/examples/convolve/benchmark.py 0644
Comment 2 Orion Poplawski 2005-08-09 12:30:03 EDT
Well, I found two other packages.  python-numeric (in core) has include files in
the main package.  python-imaging creates a -devel package, but it also has lots
of examples in the devel package as well.  I'm leaning toward no -devel package
since it just a few small text files.

Cleaned up the other errors and released -2.
Comment 3 Ville Skyttä 2005-08-09 13:00:48 EDT
Adding a "Provides: %{name}-devel = %{version}-%{release}" would sound like a 
good idea to me. 
Comment 4 Orion Poplawski 2005-08-10 16:57:56 EDT
Added the provides and re-pushed -2.  Ed - can you review/approve?
Comment 5 Ed Hill 2005-08-11 00:02:42 EDT
Hi Orion, heres the review notes:

needswork:
 - rpmbuild warns about files being list twice such as:

     warning: File listed twice: 
       /usr/lib/python2.4/site-packages/numarray/__init__.pyo

   so please take a closer look at

     %{python_sitelib}/numarray/
     %ghost %{python_sitelib}/numarray/*.pyo

   in the files section -- I don't know whether its a bug or 
   something that can be ignored or just my ignorance of the 
   %ghost macro...

good:
 - license looks OK and is included although one has to execute:

     $ python
     >>> import numarray
     >>> print numarray.__LICENSE__

   to read it (which seems OK since it appears to be what the 
   authors wanted and they went to some effort to have it that 
   way)

 - rpmlint reports warnings for the 16 *.h files but then the
   package does Provide: python-numarray-devel so someone could 
   easily split them off at a future date

 - specfile is easy to read and looks OK
 - names look OK
 - source matches upstream
 - builds nicely in mock on FC-4
 - Requires and BuildRequires look OK
 - dir ownership looks OK
 - code not content
 - no segfaults encountered

and I don't know what to say about the %ghost bit and the files-listed
-twice warning.  If it weren't so late right now I'd Google for some
examples and/or documentation.  But I need sleep...  ;-)
Comment 6 Paul Howarth 2005-08-11 03:44:36 EDT
Get rid of the "file listed twice" issue like this:

Change:
%{python_sitelib}/numarray/
%ghost %{python_sitelib}/numarray/*.pyo

To:
%dir %{python_sitelib}/numarray
%{python_sitelib}/numarray/*.py
%{python_sitelib}/numarray/*.pyc
%ghost %{python_sitelib}/numarray/*.pyo

Some people would advocate including the .pyo files rather than ghosting them too.
Comment 7 Orion Poplawski 2005-08-11 13:55:33 EDT
Okay, looks like %ghost is the way to go.  -3 has been pushed.
Comment 8 Ed Hill 2005-08-11 15:44:34 EDT
Hi Orion, I just downloaded and built -3 in mock without any problems.  
Your %ghost approach gets rid of the listed-twice problem -- good!
And it might be easier to maintain if the syntax was something like:

  %dir %{python_sitelib}/numarray
  ...list the other dirs...
  %{python_sitelib}/numarray/*.[ps][yo]
  %{python_sitelib}/numarray/*.pyc
  %{python_sitelib}/numarray/*/*.[ps][yo]
  %{python_sitelib}/numarray/*/*.pyc
  %ghost %{python_sitelib}/numarray/*.pyo
  %ghost %{python_sitelib}/numarray/*/*.pyo

But you maintain it so its your choice...  ;-)

Approved!
Comment 9 Ville Skyttä 2005-08-11 16:43:31 EDT
Skimming the commit I noticed that this is an arch dependent package but uses 
%{python_sitelib}.  That will most likely fail on x86_64.  If that's the case, 
use %{python_sitearch} instead (see python spec template in 
fedora-rpmdevtools). 
Comment 10 Orion Poplawski 2005-08-11 17:23:48 EDT
Just discovered this.  Thanks.

Checked in and built.
Comment 11 Christian Iseli 2007-01-02 18:15:25 EST
Changed summary for tracking purposes.

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