[Numpy-discussion] .debs of numpy-0.9.8 available for Ubuntu Dapper

[Andrew Straw]

Andrew Straw wrote:

>I've put together some .debs for numpy-0.9.8. There are binaries 
>compiled for amd64 and i386 architectures of Ubuntu Dapper, and I 
>suspect these will build from source for just about any Debian-based 
>distro and architecture.
>  
>
As usually happens when I try to release packages in the middle of the 
night, the cold light of morning brings some glaring problems. The 
biggest one is that the .diff.gz that was generated wasn't showing the 
changes against numpy that I had to make. I'm surprised that my own 
tests with apt-get source showed that it still built from source.

I've uploaded a new version, 0.9.8-0ads2 (note the 2 at the end). You 
can check your installed version by doing the following:
dpkg-query -l *numpy*

Anyhow, here's the debian/changelog for 0.9.8-0ads2:

  * Fixed .orig.tar.gz so that .diff.gz includes modifications made
    to source.
  * Relax build-depend on setuptools to work with any version
  * Don't import setuptools in numpy.distutils.command.install unless
    it's already in sys.modules.

I would like to merge with the package in debian experimental by Jose 
Fonseca and Marco Presi, but their package uses a lot of makefile 
wizardry that bombs out on me without any apparently informative error 
message. (I will be the first to admit that I know very little about 
Makefiles.) On the other hand, the main advantage their package 
currently has is installation of manpages for f2py, installation of the 
existing free documentation, and tweaks to script (f2py) permissions and 
naming. The latter of these issues seems to be solved by the 
build-dependency on setuptools, which is smart about installing scripts 
with the right permissions and names (it appends "2.4" to the python2.4 
version of f2py, and so on).

There have been a couple of offers of help from Ed and Ryan. I think in 
the long run, the best thing to do would be to invest these efforts 
communicating with the debian developers and to get a more up-to-date 
version in their repository. (My repository will only ever be an 
unofficial repository with the primary purpose of serving our needs at 
work which hopefully overlaps substantially with usefulness to others.) 
This should have a trickle-down effect to mainline Ubuntu repository, 
also. I doubt that the debian developers will want to start their 
python-numpy package from scratch, so I can suggest trying to submit 
patches to their system. You can checkout their source at 
svn://svn.debian.org/deb-scipy . Unfortunately, that's about the only 
guidance I can provide, because, like I said above, I can't get their 
Makefile wizardry to work on a newer version of numpy.

Arnd, I would like to get to the bottom of these atlas issues myself, 
and I've followed a similar chain of logic as you. It's possible that 
the svd routine (dgesdd, IIRC) is somehow just a bad one to benchmark 
on. It is a real workhorse for me, and so it's really the one that 
counts for me. I'll put together a few timeit routines that test svd() 
and dot() and do some more experimentation, although I can't promise 
when. Let's keep everyone informed of any progress we make.

Cheers!
Andrew