Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 165398

Summary: Review Request: python-numarray - Python array manipulation and computational library
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: Package ReviewAssignee: Ed Hill <ed>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Package Reviews List <fedora-package-review>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-08-11 21:23:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 163779    

Description Orion Poplawski 2005-08-08 20:31:45 UTC
Spec Name or Url: python-numarray.spec
SRPM Name or Url: python-numarray-1.3.3-1.src.rpm

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:

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 15:01:23 UTC
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

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

  E: python-numarray backup-file-in-package
  E: python-numarray non-executable-script 
     /usr/lib/python2.4/site-packages/numarray/examples/convolve/ 0644

Comment 2 Orion Poplawski 2005-08-09 16:30:03 UTC
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 17:00:48 UTC
Adding a "Provides: %{name}-devel = %{version}-%{release}" would sound like a 
good idea to me. 

Comment 4 Orion Poplawski 2005-08-10 20:57:56 UTC
Added the provides and re-pushed -2.  Ed - can you review/approve?

Comment 5 Ed Hill 2005-08-11 04:02:42 UTC
Hi Orion, heres the review notes:

 - rpmbuild warns about files being list twice such as:

     warning: File listed twice: 

   so please take a closer look at

     %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...

 - 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 

 - 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 07:44:36 UTC
Get rid of the "file listed twice" issue like this:

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

%dir %{python_sitelib}/numarray
%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 17:55:33 UTC
Okay, looks like %ghost is the way to go.  -3 has been pushed.

Comment 8 Ed Hill 2005-08-11 19:44:34 UTC
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...
  %ghost %{python_sitelib}/numarray/*.pyo
  %ghost %{python_sitelib}/numarray/*/*.pyo

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


Comment 9 Ville Skyttä 2005-08-11 20:43:31 UTC
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 

Comment 10 Orion Poplawski 2005-08-11 21:23:48 UTC
Just discovered this.  Thanks.

Checked in and built.

Comment 11 Christian Iseli 2007-01-02 23:15:25 UTC
Changed summary for tracking purposes.