[Numpy-discussion] Numpy 1.4.1 fails to build on (Debian) alpha and powepc

Sandro Tosi morph@debian....
Sun Aug 1 08:04:45 CDT 2010

Hi David,
sorry for the late reply.

On Fri, Jul 30, 2010 at 04:58, David <david@silveregg.co.jp> wrote:
> On 07/30/2010 06:47 AM, Sandro Tosi wrote:
>> For the build logs it's easy:
>> alpha: https://buildd.debian.org/fetch.cgi?pkg=python-numpy&arch=alpha&ver=1%3A1.4.1-4&stamp=1280296333&file=log&as=raw
>> powerpc: https://buildd.debian.org/fetch.cgi?pkg=python-numpy&arch=powerpc&ver=1%3A1.4.1-4&stamp=1280297029&file=log&as=raw
>> for powerpc "import numpy; numpy.test()" I've already sent you the
>> output, want me to re-run them? for alpha, attached you can find the
>> log for both 2.5 and 2.6; there are some errors/warnings but nothing
>> too dramatic?
> Wow, I am genuily surprised that the alpha test suite has no error (the
> 2.5 error has nothing to do with the fixes).


Anyhow, I plan to enable tests execution at package build time, so
that we can spot "strange" behaviors/faults on all the archs supported
by Debian.

>>> Also, if there is another issue preventing numpy 1.4.x integration on
>>> debian and ubuntu, please speak up. Ideally, I would like to remove
>> I don't think there is anything else (for now :) ) from the numpy
>> side: Thanks a lot for the support!! Now on Debian we have to fix some
>> packages to avoid breakages when we upgrade numpy in the future (the
>> biggest issue was that dtype was extended with new fields at the end,
>> but some packages were checking the size of dtype with the one the
>> packge was compiled with (1.3.*) and failed).
> Yes, we have improved quite a bit our support here in 1.4.x - we hope
> that those issues won't arise in the 1.x series anymore. Note also that
> if those dtype errors appear with pyrex/cython-generated code, using a
> more recent cython will prevent the error from happening (warnings
> raised instead).

Ah, thanks for letting me know! I'll keep in mind.

>> As usual, Ubuntu will
>> just sit and wait for us to do the work and then just sync it (sigh).
>>> the need for downstream patches (none of them was necessary IIRC),
>> Here is the list of the patches we currently have in the Debian
>> package (you can look at them at [2]):
>> 02_build_dotblas.patch
>> - Patch to build _dotblas.c when ATLAS is not installed.
>> -- dunno exactly what it does, it seems to infer _dotblas is compiled
>> is ATLAS is missing
> This is is caused by not having atlas as a build dependency I guess.
> Strictly speaking, dotblas only requires cblas, but we don't have the
> check in place to do so. Since numscons already does this, and it has
> worked pretty well, maybe I will take time to add this as well in
> numpy.distutils. But this has relatively little consequence I think.

yep, I agree, it would be nice tho to have it directly upstream.

>> 03_force_f2py_version.patch
>> - force generation f2py postfixed with interpreter version
>> -- Debian specific: we ship f2py2.5 and f2py2.6 and we make f2py a
>> symlink towards f2py2.6
> ok.
>> 05_fix_endianness_detection.patch
>> - Fix endianness detection: endian.h should be present on all Debian
>> machines. This patch forces the use of endian.h, this reventing
>> several reverse dependencies os Numpy from failing to build.
>> -- Debian specific: we want to enforce the usage of endian.h file
>> available on all of our architectures
> This one has been fixed in the 1.4.x branch (and trunk of course)
>> 07_bts585309_string_exceptions.diff
>> - Remove string exceptions
>> -- patch from trunk, we can remove it once a new release is out
> This one as well

I'll live those patches there, until a new release will be out, or do
you suggest to sync the package with the 1.4.x branch?

Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

More information about the NumPy-Discussion mailing list