[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