[Numpy-discussion] Debian/Ubuntu patch help

Julian Taylor jtaylor.debian at googlemail.com
Wed May 16 15:57:36 EDT 2012


On 05/16/2012 09:01 PM, Ralf Gommers wrote:
> 
> 
> On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
> <jtaylor.debian at googlemail.com <mailto:jtaylor.debian at 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.

> 
>     the only potential issue I see is that upstream gcc adds a
>     --print-multiarch that does something completely different and harmful
>     for distutils, but I don't consider that very likely.
> 
>     Hardcoding a bunch of paths defeats the whole purpose of multiarch.
>     It will just to break in future (e.g. when the x32 abi comes to
>     debian/ubuntu) and will make cross compiling harder (though I guess
>     numpy distutils may not be built for that anyway)
> 
> 
> If that hardcoding will break in the future, then I think for 1.6.2 the
> maintainers of the Debian package should apply the gcc patch to their
> packaged numpy if they think that is necessary.

the patch is already applied in Ubuntu 12.04 and will likely be applied
again in the next Debian upload.

Julian

[0] http://lists.debian.org/debian-devel-announce/2012/05/msg00004.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120516/49b66be6/attachment.sig>


More information about the NumPy-Discussion mailing list