[Python-modules-team] Bug#466392: python-scipy: adding zvode to scipy.integrate
Ondrej Certik
ondrej at certik.cz
Thu Feb 21 15:15:38 UTC 2008
On Thu, Feb 21, 2008 at 11:16 AM, <silva at lma.cnrs-mrs.fr> wrote:
> Quoting Ondrej Certik <ondrej at certik.cz>:
> > $ apt-get source python-scipy
> > $ cd python-scipy-0.6.0/
> > $ head -n 15 debian/control
> > [...]
> > Vcs-Svn: svn://svn.debian.org/svn/python-modules/packages/scipy/trunk
> > Vcs-Browser: http://svn.debian.org/wsvn/python-modules/packages/scipy/trunk/
> >
> > In some other directory:
> > $ svn co svn://svn.debian.org/svn/python-modules/packages/scipy/trunk scipy
> >
> > Also read upstream mailinglist, the author of this patch is rebasing
> > it against the upstream svn right now. If you prepare a patch
> > against the current debian package (as a file in debian/patches), I
> > will upload it.
> > Please ask if you have more questions.
> > Ondrej
>
> One thing I've missed is why 'apt-get source python-scipy' dowloads
> files that are not in the .deb package (same version number 0.6.0-5.1
> for instance). In fact all the files in scipy/integrate/mach/ for
> example were not in my installation so that applying the patch failed.
>
> How explain this difference ? I though sources and deb were similar
> packaging of the same stuff, one being as a tarball, the other one as
> a binary...
Thanks for trying it out. I don't understand the problem though. Below
is how you can find out exactly what is happening:
This is when I do apt-get source python-scipy:
$ ls scipy/integrate/mach/
d1mach.f i1mach.f r1mach.f xerror.f
The package is build using those sources, you can (and you need to
when testing your patch) compile it with "dpkg-buildpackage", which
builds the binary.
Here are build logs from the Debian build daemons:
http://buildd.debian.org/fetch.cgi?pkg=python-scipy;ver=0.6.0-5.1;arch=powerpc;stamp=1199115265
Search for "mach" in there. Here are the relevant lines:
building 'mach' library
using additional config_fc from setup script for fortran compiler:
{'noopt': ('scipy/integrate/setup.py', 1)}
customize GnuFCompiler
gnu: no Fortran 90 compiler found
compiling Fortran sources
Fortran f77 compiler: /usr/bin/g77 -g -Wall -fno-second-underscore -fPIC
creating build/temp.linux-ppc-2.4/scipy/integrate/mach
compile options: '-c'
g77:f77: scipy/integrate/mach/d1mach.f
g77:f77: scipy/integrate/mach/xerror.f
g77:f77: scipy/integrate/mach/r1mach.f
g77:f77: scipy/integrate/mach/i1mach.f
ar: adding 4 object files to build/temp.linux-ppc-2.4/libmach.a
So the mach sources are compiled in the libmach.a and this library is
then statically linked into _quadpack.so:
/usr/bin/g77 -g -Wall -g -Wall -shared
build/temp.linux-ppc-2.5/scipy/integrate/_quadpackmodule.o
-Lbuild/temp.linux-ppc-2.5 -lquadpack -llinpack_lite -lmach -lg2c -o
build/lib.linux-ppc-2.5/scipy/integrate/_quadpack.so
And this file is in the binary package:
$ wajig list-files python-scipy | grep _quadpack.so
/usr/lib/python2.4/site-packages/scipy/integrate/_quadpack.so
/usr/lib/python2.5/site-packages/scipy/integrate/_quadpack.so
Could you please ellaborate on what kind of differences there are?
Ondrej
More information about the Python-modules-team
mailing list