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
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 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
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
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 > /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.
(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
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
(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?
(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
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
(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.
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