Release 1.1.0

[megies]

https://pypi.io/packages/source/o/obspy/obspy-1.1.0.zip

SHA256: ef48b4e52a8166c35c46775b523899ffaa00658018822103e1ad9f5008050d61

Issues left to handle:

• milestone 1.1.0
• other issues with no action or lower priority were bumped to 1.2.0 milestone
• feel free to still get issues ready that were bumped to 1.2.0

Things to do, when release candidates and final release are done:

• Run docker tests (@krischer / @megies -- are done routinely now, but double-checking can't hurt)
• source distribution to pypi
• conda packages via conda-forge: Build next ObsPy release 1.0.3 conda-forge/obspy-feedstock#6
• conda packages for Linux 32bit via https://github.com/obspy/obspy/tree/master/misc/installer/anaconda and distributed at https://anaconda.org/obspy/obspy/files (@krischer / @megies)
• maxiconda bundled installer via recipes in https://github.com/obspy/anaconda-installers but built locally on win+nix and attached to release: https://github.com/obspy/obspy/releases/tag/1.1.0 (@megies and @barsch)
• wheels for Linux+OSX (@krischer)
• Windows pypi packages (@barsch / appveyor)
• debian packages (@megies)
• redhat/centos packages (@QuLogic)
• macports packages (@petrrr)
• zenodo: reserve a DOI pre-release (@megies)
• zenodo: upload sdist zipball and finalize release (@megies)
• Update docs once released (@megies)
• News entry in the wiki
• "What's new?" page in the wiki
• Email to the users and announcements mailing lists
• Tweet
• update base branches for all issues bumped to 1.1.1 to a new branch maintenance_1.1.x
• check dependency versions, some old distros we used to support might have gone EOL since release of 1.0, so we might be able to bump minimum dependency versions of e.g. numpy, scipy, matplotlib, ...

---

• Party 🎉 (don't tick before all other checkboxes are ticked!)

[krischer]

👍 For releasing! We should release more often.

We should keep in mind that 1.1 will break lots of peoples code as it no longer contains the deprecation renaming from the Big Rename ™ which are still part of 1.0. I'm very sure very many people just ignore all the warnings...

Not really anything we can do about that but a thing to keep in mind.

[ThomasLecocq]

👍 aaaand I will finish my homework... Could we (you) introduce the name change from datamark to win in there too ?

[megies]

We should keep in mind that 1.1 will break lots of peoples code as it no longer contains the deprecation renaming from the Big Rename ™ which are still part of 1.0. I'm very sure very many people just ignore all the warnings...

Yes, we'll have to include this notice again when releasing.

Could we (you) introduce the name change from datamark to win in there too ?

I don't care about that naming and low-level I/O routines should not be used directly in normal use cases anyway. So just go after it if you want. (Do we want to be nice and keep the old datamark folder in place for one release cycle and deprecate those two functions there?)

[megies]

@obspy/developers I propose we target end of November for releasing 1.0.3 and 1.1.0.

We should start bumping issues/PRs without activity to 1.1.1 and 1.2.0 in the next weeks.

[mbyt]

so we might be able to bump minimum dependency versions of e.g. numpy, scipy, matplotlib, ...

👍

[krischer]

I'm not sure we can do that. Last time I looked the limiting ones where Ubuntu 12.04 (which is EOL soon so it should be no problem) and Debian Squeeze Wheezy (EOL I think is somewhen in 2018). I don't think we want to give up Debian Squeeze support especially as long as the effort it really not that big - ones it becomes too much we can talk about it.

[megies]

Ah, OK, just checked to confirm. Debian 7 "Wheezy" has LTS until May 2018 and has..

• numpy 1.6.2
• scipy 0.10.1
• matplotlib 1.1.1

[krischer]

Well I guess we can at least bump scipy to 0.10.1 soonish ;-)

In any case - I think we should really support Wheezy until it really just becomes too much work from our side.

[MMesch]

I suggest to introduce a 5 sec delay timer for deprecated routines, that would make people change their codes :)

[krischer]

1.1.0 will actually remove almost all the deprecated functions. Let chaos ensue!

[megies]

We could wait with 1.1.0 a couple of days after 1.0.3 (with the "last warning" ☠️ message).

[krischer]

Probably no use - if people ignored it until now they'll keep ignoring it. They can always use 1.0.3 though and their scripts will continue to work.

[trichter]

By the way: I'd love to have an anaconda linux-32bit package for my ancient hardware at home. The package could be build the old way and copied to the conda-forge channel. If it is too much hassle - don't mind, installation by pip is OK, just takes way longer. linux-32bit support in conda-forge seems pretty low priority, see conda-forge/conda-forge.github.io#163.

[megies]

@krischer has built conda packages for Linux 32bit: https://anaconda.org/obspy/obspy/files they're just over in our channel and not in conda-forge.

[trichter]

Yes, I recognized that, thanks and that is great. I was talking about releases>=1.1 and that it would be nice to have these builds in future, too.

[krischer]

Yea sure - I can keep building the 32bit conda packages - that is really no big issue.

[megies]

@obspy/developers

1.0.3 will be ready within a day or two, so 1.1.0 is also gonna be freezed shortly.

Anything that's supposed to be in 1.1.0 will have to be worked on within the next days....

[QuLogic]

What is left to do for this release? Not having Mpl2 support is troubling...

[megies]

See https://github.com/obspy/obspy/milestone/12 (some will have to be punted to 1.2, I guess)

• Make Stream.rotate() take an Inventory object / Stream.rotate from unaligned to ZNE #1310 should be ready, I'd like a review as it's fairly core-ish
• we likely have to punt vcr, as I think it's not really reliable if we don't check outgoing traffic as well (and that's not yet ready, see Playback: Check outgoing traffic if it matches what is recorded in VCR tape + check if test source code changed + remove non-gzip vcr tape compat vcr#8, wasn't able to finish it back then, other important things got in the way)
• SEED -> Inventory read support + NRL client #1185: I'm not sure what the exact status is.. @krischer worked on it.. that would be nice to have in 1.1.0

[megies]

@obspy/developers so getting a pre-EGU release out was an utter fail. If we don't make a pre-AGU release in October/November than it's getting ridiculous.

For anybody who can spare some time, here's the list tickets that could use input / work / reviews / commenting for improvement: https://github.com/obspy/obspy/milestone/12

[kaspervanwijk]

Would have finished my taup plot_times() <#1877>job, if I hadn't just lost 13 minutes in hypnosis by the audiovisuals <https://www.youtube.com/watch?v=vZ80K3i4t3w&feature=youtu.be> of one of the other PRs on the todo list.... Amazing!! (Should finish my first obspy PR this week, for sure!) Kasper

[megies]

@obspy/developers we plan to do a rc1 tomorrow, since all big roadblocks have been pretty much cleared out..

[megies]

Here's the sdist zipball for 1.1.0rc1: obspy-1.1.0rc1.zip

[krischer]

I drafted a "What's new in Obspy 1.1" wiki page: https://github.com/obspy/obspy/wiki/What's-New-in-ObsPy-1.1

Please have a look and edit/add things which you feel are important. Some pretty pictures would also be nice.

[megies]

Most important bug fixes should also be mentioned.. e.g. the ZNE from non-orthogonal components

[barsch]

@krischer thought we dropped support for python 3.3? also maybe add read support for seisan v6

[hugovk]

Yep, I ran the command with - - pip to exclude downloads from mirrors and so on.

[krischer]

Okay people - final push towards 1.1.0! Four things left to do:

• Someone review this: Routing to fdsnws sub domains #1957
• Can someone reproduce this? Improve LocalNRL/RemoteNRL check in NRL #1951
• If somebody want to chime into the ISF reader (read ISF ISM1.0 bulletin event format #1946) please do so know. I'll otherwise merge this later today.
• This should be looked into as well: fix docker Linux32 conda package builder #1950 But maybe we can also fix this after the release as it is build system related an we know from the docker tests that ObsPy works on 32bit machines. (Do it after the release as its purely a packaging issue.)

[ThomasLecocq]

will pull #1946 and test it on windows
edit: I guess it's unrelated... http://tests.obspy.org/89254/

[krischer]

This is somehow again your installation? I feel like we discussed these failures before.

[ThomasLecocq]

yeah I do remember it... damn
edit: feels like I talk to my psy :) eheh

[megies]

So, looks like our release milestone is clear right now, so here goes: obspy-1.1.0rc8.zip
SHA256: 686b2d4364ed4d93cd21c13e17751e3867d30c1428f060544fb2c28c04d7bab2

CC @obspy/packagers

conda package build PR updated: conda-forge/obspy-feedstock#11

[megies]

RC9: obspy-1.1.0rc9.zip

SHA256: cb0fce24e9a9542ec1b3a9bbf1bacac97cf89e7aa2adfae87e55fea2d96848c7

CC @obspy/packagers

[krischer]

RC10: https://www.dropbox.com/s/d92npjvy17yklma/obspy-1.1.0rc10.zip?dl=1

SHA256: 19a4dfa8ad1a587ce304a79dc2f93e27edbfdd0d03cc2f07359282f77e9901da

CC: @obspy/packagers

[megies]

conda feedstock build for rc10 triggered: conda-forge/obspy-feedstock#11

[krischer]

The hopefully final rc11...

https://www.dropbox.com/s/zrxb5uvncsokxg8/obspy-1.1.0rc11.zip?dl=1

SHA256: 07493250110af77b84843683592ce6c27bc5c6c27d5a530df180ead7ce05e413
b2a3d4bc35c5e1c3c70c31aec4e8ff8cfe030681feda0b7c93d82d9a155f6123

CC: @obspy/packagers

[krischer]

Please test! 1.1.0 will be tagged tomorrow if no serious issues arise.

http://tests.obspy.org/?version%3D1.0rc11

[megies]

@krischer the SHA256 I get for your dropbox download is different from what you specified above: b2a3d4bc35c5e1c3c70c31aec4e8ff8cfe030681feda0b7c93d82d9a155f6123, also see build fail in conda-forge/obspy-feedstock#11 for both dropbox downloads.

[krischer]

Yea I don't know what I copied there - on my computer the hash is the same as you've written...

[kaspervanwijk]

import numpy as np import matplotlib.pyplot as plt from obspy.taup import TauPyModel model = TauPyModel(model='iasp91') model.get_ray_paths(1890, 100).plot_times(phase_list=("ttbasic",), show=True,legend=True) No longer works: [kvan637@sc-phy-324060 code]$ python testmethodtimeplot.py Traceback (most recent call last): File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", line 228, in load_from_depth_cache value = self._depth_cache.pop(depth) KeyError: 1890 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "testmethodtimeplot.py", line 7, in <module> model.get_ray_paths(1890, 100).plot_times(phase_list=("ttbasic",), show=True,legend=True) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau.py", line 694, in get_ray_paths rp.run() File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/taup_time.py", line 38, in run self.depth_correct(self.source_depth, self.receiver_depth) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/taup_pierce.py", line 63, in depth_correct TauPTime.depth_correct(self, depth, receiver_depth) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/taup_time.py", line 50, in depth_correct self.depth_corrected_model = self.model.depth_correct(depth) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", line 221, in depth_correct return self.load_from_depth_cache(depth) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", line 230, in load_from_depth_cache value = self._load_from_depth_cache(depth) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", line 241, in _load_from_depth_cache depth_corrected = self.split_branch(depth) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", line 333, in split_branch s_wave_ray_param, out_s_mod, index_s) File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_branch.py", line 131, in insert "TauBranch depths not compatible with slowness sampling.") obspy.taup.helper_classes.TauModelError: TauBranch depths not compatible with slowness sampling.

[kaspervanwijk]

Oops! That was my test for a bug that was reported last week in taup <#1938>. Still is a bug.... (all the standard stuff for sources at reasonable depths still works)

[krischer]

Puh - I was scared there for a second. Yea it's a bug but only for a crazy edge case and we'll not fix it within the next couple of days. BTW: Feel free to add some pictures of your taup additions here: https://github.com/obspy/obspy/wiki/What%27s-New-in-ObsPy-1.1 ⁣Gesendet mit TypeApp ​ Am 26. Okt. 2017, 10:18, um 10:18, kasper van wijk <[email protected]> schrieb:

…

Oops! That was my test for a bug that was reported last week in taup <#1938>. Still is a bug.... (all the standard stuff for sources at reasonable depths still works) On 26 October 2017 at 21:14, Kasper van Wijk ***@***.***> wrote: > import numpy as np > import matplotlib.pyplot as plt > from obspy.taup import TauPyModel > > model = TauPyModel(model='iasp91') > > model.get_ray_paths(1890, 100).plot_times(phase_list=("ttbasic",), > show=True,legend=True) > > No longer works: > > ***@***.*** code]$ python testmethodtimeplot.py > Traceback (most recent call last): > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", > line 228, in load_from_depth_cache > value = self._depth_cache.pop(depth) > KeyError: 1890 > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "testmethodtimeplot.py", line 7, in <module> > model.get_ray_paths(1890, 100).plot_times(phase_list=("ttbasic",), > show=True,legend=True) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau.py", line > 694, in get_ray_paths > rp.run() > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/taup_time.py", > line 38, in run > self.depth_correct(self.source_depth, self.receiver_depth) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/taup_pierce.py", > line 63, in depth_correct > TauPTime.depth_correct(self, depth, receiver_depth) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/taup_time.py", > line 50, in depth_correct > self.depth_corrected_model = self.model.depth_correct(depth) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", > line 221, in depth_correct > return self.load_from_depth_cache(depth) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", > line 230, in load_from_depth_cache > value = self._load_from_depth_cache(depth) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", > line 241, in _load_from_depth_cache > depth_corrected = self.split_branch(depth) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_model.py", > line 333, in split_branch > s_wave_ray_param, out_s_mod, index_s) > File "/home/kvan637/Downloads/obspy-1.1.0rc11/obspy/taup/tau_branch.py", > line 131, in insert > "TauBranch depths not compatible with slowness sampling.") > obspy.taup.helper_classes.TauModelError: TauBranch depths not compatible > with slowness sampling. > > > > On 26 October 2017 at 21:06, Lion Krischer ***@***.***> > wrote: > >> Yea I don't know what I copied there - on my computer the hash is the >> same as you've written... >> >> — >> You are receiving this because you are on a team that was mentioned. >> Reply to this email directly, view it on GitHub >> <#1562 (comment)>, or mute >> the thread >> <https://github.com/notifications/unsubscribe-auth/AE253p1kOS6QxUm6t_XXL_h1d1dIs35Nks5swD2XgaJpZM4Ka4y3> >> . >> > > -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1562 (comment)

[megies]

Yea I don't know what I copied there - on my computer the hash is the same as you've written...

Man-in-the-middle attack by Guido him very self? ;-)
Did you check the SHA of the original file you locally built (not the download)? Otherwise it's kinda useless..

[krischer]

Yes of course :) ⁣Gesendet mit TypeApp ​ Am 26. Okt. 2017, 10:41, um 10:41, Tobias Megies <[email protected]> schrieb:

…

> Yea I don't know what I copied there - on my computer the hash is the same as you've written... Man-in-the-middle attack by Guido? Did you check the SHA of the original file you locally built, not the download? Otherwise it's kinda useless.. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1562 (comment)

[krischer]

1.1.0 is locked and loaded: https://pypi.org/project/obspy/
SHA256: ef48b4e52a8166c35c46775b523899ffaa00658018822103e1ad9f5008050d61

Package away and thanks everyone for contributing!

[megies]

conda-forge build all green, after OSX was built, finally: https://github.com/conda-forge/obspy-feedstock/commits/master, so conda packages for all archs/Python versions supported by conda-forge are live at https://anaconda.org/conda-forge/obspy/files

Debian + Ubuntu packages are live as well in our Apt repository at debs.obspy.org

[krischer]

Binary wheels for OSX and Linux are now also up.

[megies]

Corrected all base branches of open PRs, moving from maintenance_1.0.x to maintenance_1.1.x.

[megies]

Conda packages for Linux 32 bit are up: https://anaconda.org/obspy/obspy/files?version=1.1.0 (feedback and test results appreciated)

[megies]

@petrrr are you still doing macports packages?

Otherwise this issue is ready to be closed.. :-)

[petrrr]

@megies: Sorry! Was a bit too busy lately. Will try to get this done tonight!

[megies]

@petrrr, no worries!

Coming from Linux I even really don't know how big macports is.. but just asking since it's on our release todo list. :-)

[megies]

Closing this milestone now, even though I'm not sure what status on macports is, @petrrr.

And we didn't manage to get this "Party!" item ticked.. well at least not officially. ;-)

[petrrr]

Sorry, done.

[megies]

No worries, and thanks!