Bug 306271 - Request (w/ attached scipy.spec) to update SciPy package to 0.6.0
Request (w/ attached scipy.spec) to update SciPy package to 0.6.0
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: scipy (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jef Spaleta
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-25 20:51 EDT by Jarrod Millman
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-04 12:24:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SciPy 0.6.0 spec file (3.70 KB, text/x-rpm-spec)
2007-09-25 20:51 EDT, Jarrod Millman
no flags Details
Warning messages concerning files which may need to be excluded (15.61 KB, text/plain)
2007-10-02 16:39 EDT, Jef Spaleta
no flags Details
rpmlint errors for files which may require exclusion or fixing (5.60 KB, text/plain)
2007-10-02 16:40 EDT, Jef Spaleta
no flags Details

  None (edit)
Description Jarrod Millman 2007-09-25 20:51:44 EDT
Description of problem:
I would like to see SciPy updated to release 0.6.0.  I am the release manager
for SciPy and have been in email contact with Jeff Spaleta.  Jeff suggested that
I update the scipy.spec and create a ticket.  The scipy.spec is attached.  I
made a few modifications, but it is basically just updated to create an rpm for
the new release.

Please let me know if there is any more information or changes that I need to make.

Thanks,
Jarrod Millman
Comment 1 Jarrod Millman 2007-09-25 20:51:44 EDT
Created attachment 206281 [details]
SciPy 0.6.0 spec file
Comment 2 Jef Spaleta 2007-10-02 15:07:46 EDT
Okay first couple of comments on the spec file that you have submitted.

1) The license of the source code for some of the included files in the scipy
source tarball are in fact licensed under the LGPLv2+:
For example:  scipy-0.6.0/scipy/weave/blitz/blitz/vecbfn.cc

Under the Fedora licensing policy this must be noted in the Licensing tag of the
spec file to indicate that multiple source code files in the srpm are licensed
under different licenses.  Please refer to the Multiple Licensing Section of
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines

2) Requires: libblas.so.3, liblapack.so.3  and are unnecessary
rpmbuild auto-generates library dependencies such as these based on linking
information.

I'm doing local builds of this in mock against F-7 and development.

-jef
Comment 3 Jef Spaleta 2007-10-02 16:37:05 EDT
Okay building locally with mock... it seems we've got some cruft that I missed
previously concerning the inclusion of source code files in the binary rpm.

running rpmlint on the binary rpm I see there are a number of .cpp, .h  and
setup.py files being written into the
/usr/lib/python2.5/site-packages/scipy/weave directory tree
for both the 0.5.2 and 0.6.0 packages.

I think these are errenously being installed, and I would prefer to exclude them
from the binary package. There are over 100 items in total.

Additionally, does it make sense to package the tests scripts such as 
/usr/lib/python2.5/site-packages/scipy/fftpack/tests/test_helper.py
as part of the main scipy package payload?

I'll attach the output of rpmlint for reference.

-jef  

Comment 4 Jef Spaleta 2007-10-02 16:39:11 EDT
Created attachment 213921 [details]
Warning messages concerning files which may need to be excluded
Comment 5 Jef Spaleta 2007-10-02 16:40:12 EDT
Created attachment 213931 [details]
rpmlint errors for files which may require exclusion or fixing
Comment 6 Jarrod Millman 2007-10-02 18:56:26 EDT
(In reply to comment #3)
> running rpmlint on the binary rpm I see there are a number of .cpp, .h  and
> setup.py files being written into the
> /usr/lib/python2.5/site-packages/scipy/weave directory tree
> for both the 0.5.2 and 0.6.0 packages.

This is correct.  Weave provides tools for including C/C++ code within in Python
code.  The inlined C/C++ code is compiled at runtime.

> Additionally, does it make sense to package the tests scripts such as 
> /usr/lib/python2.5/site-packages/scipy/fftpack/tests/test_helper.py
> as part of the main scipy package payload?

This is a functionality that I would rather not separate out from the package. 
The way our testing code functions now, you can import any module and run the
test directly from that location.  For example,

>>> from scipy import io
>>> io.test()

runs the testsuite for the IO code.  If we package the testsuite separately it
seems like it would be difficult to still have this functionality.  (I could be
wrong about that, but how we could do it doesn't seem obvious to me at the moment.)

Also given that the first things our typical users do after trying a new version
is to run the full testsuite, it would be inconvenient to not have the numerical
tests distributed with the code.
Comment 7 Jef Spaleta 2007-10-02 19:18:28 EDT
(In reply to comment #6)
> This is correct.  Weave provides tools for including C/C++ code within in 
> Python code.  The inlined C/C++ code is compiled at runtime.

Right. But now this gets me thinking a bit. To use this functionality correctly,
does that mean gcc and friends need to be on the system?  I don't want to have
to drag a compiler and its dep chain into the requirements for scipy. If weave
needs these things on a runtime system in order for weave to work, weave may be
best packaged as a scipy subpackage in the future.

> This is a functionality that I would rather not separate out from the package. 
> The way our testing code functions now, you can import any module and run the
> test directly from that location.  For example,

That's fine by me.

I'm building against development now.  Once the local test build is done, I'm
going to be imported the corrected specfile into Fedora cvs for building against
development and then as an update for F-7.

Here is the corrected specfile:
http://jspaleta.fedorapeople.org/Fedora/scipy-0.6/scipy.spec

Mock built F-7 binaries for x86 are here:
http://jspaleta.fedorapeople.org/Fedora/scipy-0.6/F-7/

-jef
Comment 8 Jef Spaleta 2007-10-03 01:37:25 EDT
I've hit a snag. it seems the build process is not working on the fedora
development tree. Jarrod do you have access to the a fedora development install
or to mock on F-7 so that you can see why swig is failing on umfpack.i against
the fedora development tree?

Here's the end of the mock build.log:
swig: scipy/linsolve/umfpack/umfpack.i
swig -python -o build/src.linux-i686-2.5/scipy/linsolve/umfpack/_umfpack_wrap.c 
-outdir build/src.linux-i686-2.5/scipy/linsolve/umfpack scipy/linsolve/umfpack/u
mfpack.i
scipy/linsolve/umfpack/umfpack.i:192: Error: Unable to find 'umfpack.h'
scipy/linsolve/umfpack/umfpack.i:193: Error: Unable to find 'umfpack_solve.h'
scipy/linsolve/umfpack/umfpack.i:194: Error: Unable to find 'umfpack_defaults.h'
scipy/linsolve/umfpack/umfpack.i:195: Error: Unable to find 'umfpack_triplet_to_
col.h'
scipy/linsolve/umfpack/umfpack.i:196: Error: Unable to find 'umfpack_col_to_trip
let.h'
scipy/linsolve/umfpack/umfpack.i:197: Error: Unable to find 'umfpack_transpose.h
'
scipy/linsolve/umfpack/umfpack.i:198: Error: Unable to find 'umfpack_scale.h'
scipy/linsolve/umfpack/umfpack.i:200: Error: Unable to find 'umfpack_report_symb
olic.h'
scipy/linsolve/umfpack/umfpack.i:201: Error: Unable to find 'umfpack_report_nume
ric.h'
scipy/linsolve/umfpack/umfpack.i:202: Error: Unable to find 'umfpack_report_info
.h'
scipy/linsolve/umfpack/umfpack.i:203: Error: Unable to find 'umfpack_report_cont
rol.h'
scipy/linsolve/umfpack/umfpack.i:215: Error: Unable to find 'umfpack_symbolic.h'
scipy/linsolve/umfpack/umfpack.i:216: Error: Unable to find 'umfpack_numeric.h'
scipy/linsolve/umfpack/umfpack.i:225: Error: Unable to find 'umfpack_free_symbol
ic.h'
scipy/linsolve/umfpack/umfpack.i:226: Error: Unable to find 'umfpack_free_numeri
c.h'
scipy/linsolve/umfpack/umfpack.i:248: Error: Unable to find 'umfpack_get_lunz.h'
scipy/linsolve/umfpack/umfpack.i:272: Error: Unable to find 'umfpack_get_numeric
.h'
error: command 'swig' failed with exit status 1
Comment 9 Jarrod Millman 2007-10-03 18:04:28 EDT
(In reply to comment #8)

I don't have the development install, but I am running Fedora 7 with all the
current patches.  I added the site.cfg to the spec file to avoid this error. 
Without specifying where to find UMF I get this error.  But I don't get that
error when I use this scipy.spec file:
http://jspaleta.fedorapeople.org/Fedora/scipy-0.6/scipy.spec

On my system, ufsparse-devel puts its header files in /usr/include/ufsparse
which is where the site.cfg from the spec file specifies.  Can you verify that
this location hasn't changed on the development branch?
Comment 10 Jef Spaleta 2007-10-03 19:00:17 EDT
(In reply to comment #9)
> On my system, ufsparse-devel puts its header files in /usr/include/ufsparse
> which is where the site.cfg from the spec file specifies.  Can you verify that
> this location hasn't changed on the development branch?

Looks like its now  /usr/include/suitesparse/
on fedora-development.

I've updated my spec to include the additional include directory
http://jspaleta.fedorapeople.org/Fedora/scipy-0.6/scipy.spec

Running Local builds against development and F-7 now. 

If you get the chance you should install mock on your fedora 7 box. With box you
can get clean buildroots for any of the active fedora releases and
fedora-development. 

once you add your user to the mock group you can do this:
mock -r fedora-development fedora-devel-i386 scipy-0.6.0-3.fc7.i386

and mock will pull development bits over the network necessary to build the
specified srpm locally in a clean x86 fedora development buildroot.

-jef
Comment 11 Jef Spaleta 2007-10-03 19:19:29 EDT
Okay local builds on F-7 and development completed. I'm going to commit the
latest spec and the 0.6.0 sources to development cvs and required a koji build.

Once the build is finished for development I'll push a build to updates-testing
in  F-7.

We are in a continual development freeze leading up to F8. If release
engineering allows it, this may slide into the public development tree before
F-8 release. Otherwise we'll have to wait for post F8 release.  

Once this is in a public development or F-8 tree I'll push this from
updates-testing to updates-released in F-7

-jef
Comment 12 Jarrod Millman 2007-10-03 19:23:26 EDT
(In reply to comment #10)
> Looks like its now  /usr/include/suitesparse/
> on fedora-development.

That makes sense.

> If you get the chance you should install mock on your fedora 7 box. With box you
> can get clean buildroots for any of the active fedora releases and
> fedora-development.

Will do.  Thanks.

Comment 13 Jef Spaleta 2007-10-04 12:24:10 EDT
Okay I pushed a build to fedora development  and to fedora 7 updates-testing.
Feel free to brutalize the F-7 test build and drop a comment into
bodhi.fedoraproject.org  about the update.

If you haven't already you want to go through the necessary paperwork for Fedora
contributor. Get the CLA signed, and sign up for an account in the Fedora
accounts system.  Once you get all the prelims done we can see if we can get you
sponsored  so you can be co-maintainer on scipy with me.

Closing the ticket.
-jef 

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