Debian/Ubuntu patch help (was: ANN: NumPy 1.6.2 release candidate 1)
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. 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. 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. 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)
On Tue, May 15, 2012 at 10:35 PM, Julian Taylor < 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?
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.
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.
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. Ralf
On 05/16/2012 09:01 PM, Ralf Gommers wrote:
On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
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.
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
Hello,
On Wed, May 16, 2012 at 9:01 PM, Ralf Gommers
On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
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?
second half of June, but it's still not set in stone (but I'd also not expect too much variation)
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.
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.
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.
Agreed, i'll add back the Debian specific patch. Thanks for your time and analysis - so time to release 1.6.2? :) Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Wed, May 16, 2012 at 10:41 PM, Sandro Tosi
Hello,
On Wed, May 16, 2012 at 9:01 PM, Ralf Gommers
wrote: On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
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?
second half of June, but it's still not set in stone (but I'd also not expect too much variation)
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.
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.
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.
Agreed, i'll add back the Debian specific patch. Thanks for your time and analysis - so time to release 1.6.2? :)
Yes, this weekend probably. Ralf
On Wed, May 16, 2012 at 9:57 PM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:
On 05/16/2012 09:01 PM, Ralf Gommers wrote:
On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
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.
Yes, and better sooner than later. If you or someone else can provide this as a pull request on Github, that would be helpful. As would a check that the patch doesn't fail on Windows or OS X. Ralf
On Wed, May 16, 2012 at 10:50 PM, Ralf Gommers
On Wed, May 16, 2012 at 9:57 PM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:
On 05/16/2012 09:01 PM, Ralf Gommers wrote:
On Tue, May 15, 2012 at 10:35 PM, Julian Taylor
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.
Yes, and better sooner than later. If you or someone else can provide this as a pull request on Github, that would be helpful. As would a check that the patch doesn't fail on Windows or OS X.
I opened a ticket for this so it doesn't get forgotten for 1.7.0: http://projects.scipy.org/numpy/ticket/2150 Ralf
participants (3)
-
Julian Taylor
-
Ralf Gommers
-
Sandro Tosi