Red Hat Bugzilla – Bug 306271
Request (w/ attached scipy.spec) to update SciPy package to 0.6.0
Last modified: 2007-11-30 17:12:16 EST
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.
Created attachment 206281 [details]
SciPy 0.6.0 spec file
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
2) Requires: libblas.so.3, liblapack.so.3 and are unnecessary
rpmbuild auto-generates library dependencies such as these based on linking
I'm doing local builds of this in mock against F-7 and development.
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
as part of the main scipy package payload?
I'll attach the output of rpmlint for reference.
Created attachment 213921 [details]
Warning messages concerning files which may need to be excluded
Created attachment 213931 [details]
rpmlint errors for files which may require exclusion or fixing
(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
> 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
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.
(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:
Mock built F-7 binaries for x86 are here:
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 -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
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_
scipy/linsolve/umfpack/umfpack.i:196: Error: Unable to find 'umfpack_col_to_trip
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
scipy/linsolve/umfpack/umfpack.i:201: Error: Unable to find 'umfpack_report_nume
scipy/linsolve/umfpack/umfpack.i:202: Error: Unable to find 'umfpack_report_info
scipy/linsolve/umfpack/umfpack.i:203: Error: Unable to find 'umfpack_report_cont
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
scipy/linsolve/umfpack/umfpack.i:226: Error: Unable to find 'umfpack_free_numeri
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
error: command 'swig' failed with exit status 1
(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:
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?
(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/
I've updated my spec to include the additional include directory
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
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.
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
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
(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
Will do. Thanks.
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.