Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#39795 closed update (fixed)

py-obspy: update to 0.8.4

Reported by: petrrr Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch maintainer Cc:
Port: py-obspy

Description

Please commit this update. This update resolves some issues:

  • switch to setuptools broke this port;
  • 0.8.3 is broken and would not build on Python 2.7.5;
  • mseed write in version 0.8.3 was broken for Python >= 2.7.3;

Limitations:

  1. Currently for Python 2.6 this port works fine only if py26-scipy +gcc44 and py26-obspy +gcc44 is used. This is due to #35141 as py-scipy is an important dependency. (Maybe a similar problem applies here as well).
  2. On Mac OS X 10.5.8 only the py27 subport works correctly. The py26 subport installs, but some test will fail.

Attachments (1)

patch.py-obspy.diff (3.1 KB) - added by petrrr 11 years ago.
Patch for the updated port; Portfile and patch-setup.diff

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by petrrr

Attachment: patch.py-obspy.diff added

Patch for the updated port; Portfile and patch-setup.diff

comment:1 Changed 11 years ago by mf2k (Frank Schima)

Keywords: haspatch maintainer added
Version: 2.1.3

comment:2 Changed 11 years ago by petrrr

On MacPorts Development I got feedback that the patch could not be applied. I checked this and had no problem, it patches two files (Portfile and a patch to setup.py)

However, apart from unified format, I am not aware of any requirements on patch files for submission here. I have looked a bit around but have not found any documentation on this. So if these special requirements exist, please point me the right place to look at.

Otherwise, just let me know what you would need. Thanks!

Last edited 11 years ago by petrrr (previous) (diff)

comment:3 in reply to:  description ; Changed 11 years ago by larryv (Lawrence Velázquez)

Replying to Peter.Danecek@…:

  1. Currently for Python 2.6 this port works fine only if py26-scipy +gcc44 and py26-obspy +gcc44 is used. This is due to #35141 as py-scipy is an important dependency. (Maybe a similar problem applies here as well).

It’s broken for all variants other than +gcc44? Does it work without any variants at all?

  1. On Mac OS X 10.5.8 only the py27 subport works correctly. The py26 subport installs, but some test will fail.

Do you think we should actively prevent installation of py26-obspy on 10.5, then?

comment:4 in reply to:  3 Changed 11 years ago by petrrr

Replying to larryv@…:

Replying to Peter.Danecek@…:

  1. Currently for Python 2.6 this port works fine only if py26-scipy +gcc44 and py26-obspy +gcc44 is used. This is due to #35141 as py-scipy is an important dependency. (Maybe a similar problem applies here as well).

It’s broken for all variants other than +gcc44? Does it work without any variants at all?

Well I did not try gcc43 until now, but I somehow assumed that this broke from gcc44 to gcc45. It may be actually be an gcc4{5,6,7} issue or at least some combination with python26, gcc & binary builds, fortran support (just guessing here!). I think the gccXX variants for scipy are due to Fortran support, and that's why it comes in for obspy as well. So doing without gcc variants is difficult. For obspy we could try to leave out modules requiring fortran, but I would have preferred not to do that, as most people just want to install the whole package as is.

  1. On Mac OS X 10.5.8 only the py27 subport works correctly. The py26 subport installs, but some test will fail.

Do you think we should actively prevent installation of py26-obspy on 10.5, then?

Well this is one possibility. Another would be just to support py27 for the moment. But as there is the +gcc44 work-arround I proposed it as is.

In any case, I would appreciate if we can get the update committed because at least for python 2.7 it seems to work all fine, both on 10.8 and on 10.5.

comment:5 Changed 11 years ago by petrrr

Short update: py26-scipy -gcc47 fails to build. Should I file this against py-scipy?

running build_clib
customize UnixCCompiler
customize UnixCCompiler using build_clib
customize Gnu95FCompiler
Could not locate executable gfortran
Could not locate executable f95
customize NAGFCompiler
customize AbsoftFCompiler
Could not locate executable f90
Could not locate executable f77
customize IBMFCompiler
Could not locate executable xlf90
Could not locate executable xlf
customize IntelFCompiler
Found executable /usr/bin/ifort
customize GnuFCompiler
Could not locate executable g77
customize PGroupFCompiler
Could not locate executable pgfortran
don't know how to compile Fortran code on platform 'posix'
building 'dfftpack' library
error: library dfftpack has Fortran sources but no Fortran compiler found
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-scipy/py26-scipy/work/scipy-0.12.0" && /opt/local/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6 setup.py --no-user-cfg build 
Exit code: 1

comment:6 Changed 11 years ago by petrrr

2nd update: I checked for +gcc43, and all works fine both for py26-scipy and py26-obspy, and any combination of these. Tested on the 10.8 system. On the older system compiling gcc43 would take way to long.

comment:7 Changed 11 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed

r108652. It was completely unusual how you created your patchfile and thus non-obvious (to me) how to apply it. In the future, I would suggest creating it in the same directory as the Portfile.

comment:8 in reply to:  7 Changed 11 years ago by petrrr

Replying to macsforever2000@…:

r108652. It was completely unusual how you created your patchfile and thus non-obvious (to me) how to apply it. In the future, I would suggest creating it in the same directory as the Portfile.

Thanks for the commit! I actually used git to create the diff, which looked fine and valid. Of cause, I can make the diff relative to the ports directory in future, but I was not aware of this policy and found no note on this. Wouldn't it be useful to document it somehow?

comment:9 Changed 11 years ago by mf2k (Frank Schima)

Perhaps. Every single patch I have ever applied in Macports has been in the same directory as the Portfile. I had no idea that I had to move your patch up to the parent directory and use patch -p3 to apply it. How would I know to do that?

Note: See TracTickets for help on using tickets.