how to get python-numpy to testing

[Ondrej Certik]

Hi,

python-numpy seems ok to go to testing, but:

http://bjorn.haxx.se/debian/testing.pl?package=python-numpy

a) Updating python-numpy makes 1 depending packages uninstallable on
i386: python-scipy, this should however fall into:

1. Sometimes packages have seemingly recursive dependencies (adding X
makes Y uninstallable, Y is waiting for X). This means the new version
of X will break the old version of Y, but there's also a new version
of Y that needs the new version of X. As soon as all other
dependencies are solved, the two packages can be hinted to go in
together.

as python-scipy needs newer python-numpy etc. So all should be ok here.

b) Updating python-numpy makes 5 non-depending packages uninstallable
on i386: model-builder, ninix-aya, python-gastables, python-nifti,
pyxplot

Looking for example at:

$ wajig show model-builder
[...]
Depends: python, python-central (>= 0.5.8), python-numpy-ext,
python-scipy, python-wxtools, python-wxversion, python-matplotlib,
python-setuptools

I don't see why newer python-numpy makes it uninstallable.

Any ideas how to fix b), so that python-numpy can go to testing?

Ondrej


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to get python-numpy to testing

[Steve Langasek]

On Sat, Dec 29, 2007 at 06:49:35PM +0100, Ondrej Certik wrote:

> python-numpy seems ok to go to testing, but:

> http://bjorn.haxx.se/debian/testing.pl?package=python-numpy

> a) Updating python-numpy makes 1 depending packages uninstallable on
> i386: python-scipy, this should however fall into:

> 1. Sometimes packages have seemingly recursive dependencies (adding X
> makes Y uninstallable, Y is waiting for X). This means the new version
> of X will break the old version of Y, but there's also a new version
> of Y that needs the new version of X. As soon as all other
> dependencies are solved, the two packages can be hinted to go in
^
> together.

A member of the release team has to notice the hint is needed or have it
pointed out by the maintainer, and then add that hint by hand.

That part's done now, though it's generally more effective to mail
debian-release instead of debian-python in order to get the release team to
take note. :)

The other problem is that python-scipy is *not* ready to go into testing:

$ grep-excuses python-scipy
python-scipy (0.5.2-0.1 to 0.6.0-5)
Maintainer: Debian Python Modules Team
21 days old (needed 5 days)
out of date on arm: python-scipy (from 0.6.0-4)
Not considered
Depends: python-scipy python-numpy
$

The package is failing to build on arm with a swig error:


I don't know why this is happening only on arm, but it needs resolved before
these packages will be updated in testing.

> b) Updating python-numpy makes 5 non-depending packages uninstallable
> on i386: model-builder, ninix-aya, python-gastables, python-nifti,
> pyxplot

> Looking for example at:

> $ wajig show model-builder
> [...]
> Depends: python, python-central (>= 0.5.8), python-numpy-ext,
> python-scipy, python-wxtools, python-wxversion, python-matplotlib,
> python-setuptools

> I don't see why newer python-numpy makes it uninstallable.

Because it depends on python-scipy, which is the depending package that has
already been made uninstallable?

> Any ideas how to fix b), so that python-numpy can go to testing?

By dealing with python-scipy.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to get python-numpy to testing

[Thomas Viehmann]

Steve Langasek wrote:
> The package is failing to build on arm with a swig error:
> 
> 
> I don't know why this is happening only on arm, but it needs resolved before
> these packages will be updated in testing.

I seem to be able to reproduce this build failure in a clean cowbuilder chroot.
It goes away if I see to "-I/usr/include" being passed to the failing swig call,
to test, I just did 'export SWIG_FEATURES="-I/usr/include"' before building the
package, that looks like it is working.

On arm, apparently in contrast to (at least one of) the other  atlas3-base-dev
is not installed, but I'm not sure whether that is of importance.
Both build logs I looked at noted libsuitesparse-dev, the package containing the
file swig is missing, being installed as required by the build-depends, both in
the same version.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: how to get python-numpy to testing

[Kumar Appaiah]

Dear Steve and Thomas,

On Sat, Dec 29, 2007 at 11:22:28PM +0100, Thomas Viehmann wrote:
> Steve Langasek wrote:
> > The package is failing to build on arm with a swig error:
> > 

Thanks for the hints on hints. :-)

> > I don't know why this is happening only on arm, but it needs resolved before
> > these packages will be updated in testing.
> 
> I seem to be able to reproduce this build failure in a clean cowbuilder 
> chroot.
> It goes away if I see to "-I/usr/include" being passed to the failing swig 
> call,
> to test, I just did 'export SWIG_FEATURES="-I/usr/include"' before building 
> the
> package, that looks like it is working.

Actually, the FTBFS is on i386 as well, and I have strong reason to
believe it is because of swig behaviour change. It doesn't seem to
look in /usr/include, for some reason, as you rightly point
out. Therefore, I patch setup.py for the umfpack part to add it to
`include_dirs', and it works now.

Thanks!

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature