On 05/16/2012 09:01 PM, Ralf Gommers wrote:
>
>
> On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
> <jtaylor.debian@googlemail.com <mailto:jtaylor.debian@googlemail.com>>
> wrote:
>
>     > Hi, if there's anyone wants to have a look at the above issue this
>     > week,
>     >that would be great.
>
>     > If there's a patch by this weekend I can create a second RC, so we can
>     > still have the final release before the end of this month (needed for
>     > Debian freeze). Otherwise a second RC won't be needed.
>
>     bugfixes are still allowed during the debian freeze, so that should not
>     be an issue for the release timing.
>
> OK, that's good to know. So what's the hard deadline then?

the release team aims for a freeze in the second half of june, but the
number of release critical bugs is still huge so it could still change [0].
The freeze is will probably be 3-6 month long.

>
>
>
>     I don't see the issue with the gcc --print-multiarch patch besides maybe
>     some cleanup.
>     --print-multiarch is a debian specific gcc patch, but multiarch is
>     debian specific for now.
>
>     It doesn't work in 11.04, but who cares, that will be end of life in 5
>     month anyway.
>
>
> Eh, we (the numpy maintainers) should care. If we would not care about
> an OS released only 13 months ago, we're not doing our job right.

I scanned the list of classes in system_info, the only libraries
multiarched in 11.04 on the list are:
x11_info
xft_info
freetype2_info

the first one is handled by the existing glob method, the latter two are
handled correctly via pkg-config
So I don't think there is anything to do for 11.04. 11.10 and 12.04
should also be fine.
Wheezy will have multiarched fftw but probably not much more.

Though one must also account for backports and future releases will
likely have more multiarch ready numerical stuff to allow partial
architectures like i386+sse2, x86_64+avx or completely new ones like x32.

>
>
>     Besides x11 almost nothing is multiarched in 11.04 anyway
>     and that can still be covered by the currently existing method.
>
>     gcc should be available for pretty much anything requiring
>     numpy.distutils anyway so that should be not be an issue.
>     On systems without --print-multiarch or gcc you just ignore the failing,
>     there will be no repercussions as there will also not be any multiarched
>     libraries.
>
> If it's really that simple, such a patch may go into numpy master. But
> history has shown that patches to a central part of numpy.distutils are
> rarely issue-free (more due to the limitations/complexity of distutils
> than anything else). Therefore making such a change right before a
> release is simply a bad idea.

I agree its probably a bit late to add it to 1.6.2.
There is also no real need to have multiarch handled in this version.
The Debian can add the patch to its 1.6.2 package

It would be good to have the patch or something equivalent in the next
version so upgrading from the package to 1.6.3 or 1.7 will not cause a
regression in this respect.