[arch-general] scipy package - is there anything important that stops the update to 0.9?
Hi all, I'd like to ask if there are any important issues regarding update of python-scipy? It's been flagged out of date for nearly two months, that's quite long time for Arch standards! Is there any issue remaining to be solved, anything I can help with? I'd really like to see this updated to 0.9, as I have some aur packages waiting for this. Cheers, Andrzej.
On 23 April 2011 00:08, Andrzej Giniewicz <gginiu@gmail.com> wrote:
Hi all,
I'd like to ask if there are any important issues regarding update of python-scipy? It's been flagged out of date for nearly two months, that's quite long time for Arch standards! Is there any issue remaining to be solved, anything I can help with? I'd really like to see this updated to 0.9, as I have some aur packages waiting for this.
If you check out the buildscripts from Subversion (or from the GIT clone of the repository), you'll notice that it has already been updated. Granted, that in itself took longer than usual, but I suppose that was basically just lack of maintainer time. The main issue now is linking to lapack, which fails. There is a symlink hack (you can refer to the python3- PKGBUILD in AUR), but we do not know why and how (this works). Without that hack, SciPy should not be choosy about linking to static or dynamic lapack libs, but in this case it builds only if a static lapack is present. The reason for the stall in releasing an update is basically waiting to sort out this behaviour. Otherwise, it's good to go. -- GPG/PGP ID: 8AADBB10
Hi,
The main issue now is linking to lapack, which fails. There is a symlink hack (you can refer to the python3- PKGBUILD in AUR), but we do not know why and how (this works). Without that hack, SciPy should not be choosy about linking to static or dynamic lapack libs, but in this case it builds only if a static lapack is present. The reason for the stall in releasing an update is basically waiting to sort out this behaviour. Otherwise, it's good to go.
I think I know what this is about, i.e. iirc it was bug in Numpy. In Python 3.2 because of PEP 3149 ( http://www.python.org/dev/peps/pep-3149/ ) all .so files are prefixed with SOABI name, i.e. cpython-32 in that case. It was made so compiled files by multiple python versions could coexist. Python itself uses sysconfig to determine the name:
sysconfig.get_config_var('SO') '.cpython-32mu.so' sysconfig.get_config_var('SOABI') 'cpython-32mu'
the problem is that it's use is aimed for internal python use, not external libraries. Numpy used sysconfig.get_config_var('SO') - the internel python extension name, for external libraries. This is fixed for Numpy 1.6, when they instead check if there is SOABI and if yes, they remove it from SO to get previous behaviour. This is actually affecting numpy and scipy and probably others, because that use distutils of numpy. The patch is attached to ticket: http://projects.scipy.org/numpy/ticket/1749 and was accepted upstream/merged and it seems to work. 2011/4/22 Ángel Velásquez <angvp@archlinux.org>:
Maybe you should try to build it by yourself first, before asking if there is anything important that is stoping the release...
tried and it worked, because I'm running prerelease of numpy 1.6 - sorry, I probably should downgrade numpy to 1.5.1 as in official package and test then, my bad, did not see that coming at first, before I started to dig, but I've seen no issues with scipy 0.9 or git, that's why I asked.
As Ray explained to you, to build this version, for now it have to be hacked horribly, and isn't being possible, plus, I had on vacations, and the unique person who helped me to see this behaviour by far have been Ray, nobody from the community, not you btw who next time before ask this kind of stuff you should contact first the maintainer.
Sorry again. Though I better ask on list/start discussion when multiple people see that flow and can add to finally find solution, that's why lists are for, to talk, not? Especially for people who prefer lists before forums like myself, I like to keep the copy in my mailbox. I looked trough list and found nothing, checked forum and found one issue marked as solved which I wasn't able to reproduce - so I asked if there is something I don't know about and maybe help... Anyway next time I will contact peer to peer if this is preferred way, no problem, you have my word. Cheers, Andrzej.
2011/4/22 Andrzej Giniewicz <gginiu@gmail.com>:
Hi,
The main issue now is linking to lapack, which fails. There is a symlink hack (you can refer to the python3- PKGBUILD in AUR), but we do not know why and how (this works). Without that hack, SciPy should not be choosy about linking to static or dynamic lapack libs, but in this case it builds only if a static lapack is present. The reason for the stall in releasing an update is basically waiting to sort out this behaviour. Otherwise, it's good to go.
I think I know what this is about, i.e. iirc it was bug in Numpy. In Python 3.2 because of PEP 3149 ( http://www.python.org/dev/peps/pep-3149/ ) all .so files are prefixed with SOABI name, i.e. cpython-32 in that case. It was made so compiled files by multiple python versions could coexist. Python itself uses sysconfig to determine the name:
sysconfig.get_config_var('SO') '.cpython-32mu.so' sysconfig.get_config_var('SOABI') 'cpython-32mu'
the problem is that it's use is aimed for internal python use, not external libraries. Numpy used sysconfig.get_config_var('SO') - the internel python extension name, for external libraries. This is fixed for Numpy 1.6, when they instead check if there is SOABI and if yes, they remove it from SO to get previous behaviour. This is actually affecting numpy and scipy and probably others, because that use distutils of numpy. The patch is attached to ticket:
http://projects.scipy.org/numpy/ticket/1749
and was accepted upstream/merged and it seems to work.
2011/4/22 Ángel Velásquez <angvp@archlinux.org>:
Maybe you should try to build it by yourself first, before asking if there is anything important that is stoping the release...
tried and it worked, because I'm running prerelease of numpy 1.6 - sorry, I probably should downgrade numpy to 1.5.1 as in official package and test then, my bad, did not see that coming at first, before I started to dig, but I've seen no issues with scipy 0.9 or git, that's why I asked.
As Ray explained to you, to build this version, for now it have to be hacked horribly, and isn't being possible, plus, I had on vacations, and the unique person who helped me to see this behaviour by far have been Ray, nobody from the community, not you btw who next time before ask this kind of stuff you should contact first the maintainer.
Sorry again. Though I better ask on list/start discussion when multiple people see that flow and can add to finally find solution, that's why lists are for, to talk, not? Especially for people who prefer lists before forums like myself, I like to keep the copy in my mailbox. I looked trough list and found nothing, checked forum and found one issue marked as solved which I wasn't able to reproduce - so I asked if there is something I don't know about and maybe help... Anyway next time I will contact peer to peer if this is preferred way, no problem, you have my word.
Cheers, Andrzej.
No problem, feel free to talk to me on irc, I am just working on it :-) -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
2011/4/23 Ángel Velásquez <angvp@archlinux.org>:
2011/4/22 Andrzej Giniewicz <gginiu@gmail.com>:
Hi,
The main issue now is linking to lapack, which fails. There is a symlink hack (you can refer to the python3- PKGBUILD in AUR), but we do not know why and how (this works). Without that hack, SciPy should not be choosy about linking to static or dynamic lapack libs, but in this case it builds only if a static lapack is present. The reason for the stall in releasing an update is basically waiting to sort out this behaviour. Otherwise, it's good to go.
I think I know what this is about, i.e. iirc it was bug in Numpy. In Python 3.2 because of PEP 3149 ( http://www.python.org/dev/peps/pep-3149/ ) all .so files are prefixed with SOABI name, i.e. cpython-32 in that case. It was made so compiled files by multiple python versions could coexist. Python itself uses sysconfig to determine the name:
sysconfig.get_config_var('SO') '.cpython-32mu.so' sysconfig.get_config_var('SOABI') 'cpython-32mu'
the problem is that it's use is aimed for internal python use, not external libraries. Numpy used sysconfig.get_config_var('SO') - the internel python extension name, for external libraries. This is fixed for Numpy 1.6, when they instead check if there is SOABI and if yes, they remove it from SO to get previous behaviour. This is actually affecting numpy and scipy and probably others, because that use distutils of numpy. The patch is attached to ticket:
http://projects.scipy.org/numpy/ticket/1749
and was accepted upstream/merged and it seems to work.
2011/4/22 Ángel Velásquez <angvp@archlinux.org>:
Maybe you should try to build it by yourself first, before asking if there is anything important that is stoping the release...
tried and it worked, because I'm running prerelease of numpy 1.6 - sorry, I probably should downgrade numpy to 1.5.1 as in official package and test then, my bad, did not see that coming at first, before I started to dig, but I've seen no issues with scipy 0.9 or git, that's why I asked.
As Ray explained to you, to build this version, for now it have to be hacked horribly, and isn't being possible, plus, I had on vacations, and the unique person who helped me to see this behaviour by far have been Ray, nobody from the community, not you btw who next time before ask this kind of stuff you should contact first the maintainer.
Sorry again. Though I better ask on list/start discussion when multiple people see that flow and can add to finally find solution, that's why lists are for, to talk, not? Especially for people who prefer lists before forums like myself, I like to keep the copy in my mailbox. I looked trough list and found nothing, checked forum and found one issue marked as solved which I wasn't able to reproduce - so I asked if there is something I don't know about and maybe help... Anyway next time I will contact peer to peer if this is preferred way, no problem, you have my word.
Cheers, Andrzej.
No problem, feel free to talk to me on irc, I am just working on it :-)
OK guys did you manage any progress on this? The list is fine for the discussion of this issue and the concerns are valid. It's easy for other people to keep track and also there's something to cite when in need. Anyway thanks for figuring this out! -- GPG/PGP ID: 8AADBB10
2011/4/22 Andrzej Giniewicz <gginiu@gmail.com>:
Hi all,
I'd like to ask if there are any important issues regarding update of python-scipy? It's been flagged out of date for nearly two months, that's quite long time for Arch standards! Is there any issue remaining to be solved, anything I can help with? I'd really like to see this updated to 0.9, as I have some aur packages waiting for this.
Cheers, Andrzej.
Hi, Maybe you should try to build it by yourself first, before asking if there is anything important that is stoping the release... As Ray explained to you, to build this version, for now it have to be hacked horribly, and isn't being possible, plus, I had on vacations, and the unique person who helped me to see this behaviour by far have been Ray, nobody from the community, not you btw who next time before ask this kind of stuff you should contact first the maintainer. Your _packages_ are depending on scipy 0.9.0 or builds fine with 0.8.0, if so, you should update your stuff to 0.8.0 until we can figure out how to build 0.9.0. Thanks for your !help -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com
participants (3)
-
Andrzej Giniewicz
-
Ray Rashif
-
Ángel Velásquez