Updates

[ocefpaf]

Updated to latest 1.7.2

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ocefpaf]

The failing test,

FAIL: tsformat.test 8 - chaining set 1 with netCDF4

is mentioned in https://code.zmaw.de/attachments/12693/terminal_log.txt#L222 without any answer 😒

[Try2Code]

the reason is, that the hdf5-installation used by netcdf is build non-thread-safe. This tests triggers this. Here you can run checks with serialized IO with something like this:

make check CDO="${buildDir}/src/cdo -L"

[ocefpaf]

the reason is, that the hdf5-installation used by netcdf is build non-thread-safe.

Do you recommend to merge this with the workaround you pasted above or should we wait for conda-forge/hdf5-feedstock#48 ?

BTW do you want to be added as a maintainer here?

PS: Can you take a look at the extra dependencies I added here. Are they OK?

[Try2Code]

there seem to be a linking problem to jasper. you could give it a try without jasper and grib_api

or you skip jasper and add

LIBS="-lopenjpeg"

to the configure call

[Try2Code]

About your extra dependencies:

• AFAIK libxml2 is only needed, if you build CDO with magics++ (plotting)
• Is ecmwf_grib the same as grib_api delivered from ECMWF?
• CDO itself does not need libgfortran
• the hdf5 problems are exactly triggered by the failing CDO tests. I guess, you have to enable the unsupported stuff when building hdf5. I'm not sure if the hl-interface of hdf5 is needed for netcdf4 (I guess not), but it is needed for a single CDO operator (import_cmsaf, read spec. formatted satelite data sets). You could just leave out the hdf5 dependency of CDO and do without the hl-interface, but the non-thread-safty still remains.

to become a maintainer: I'm still pretty new to conda and I do not use it regularly. So I guess, I'll cause more harm than happiness ;-)

[ocefpaf]

LIBS="-lopenjpeg"

We are building ecmwf_grib with jasper, so I am not sure that will work. I will make a few test and check what we can do. If nothing works we can drop both. Hopefully the users won't loose to much functionality without them.

AFAIK libxml2 is only needed, if you build CDO with magics++ (plotting)

Good to know. We do not have a recipe foe magics++ so I am removing that.

Is ecmwf_grib the same as grib_api delivered from ECMWF?

It is. I was also used to the name grib_api, but when we added it in conda-forge we followed the scitools recipe that used the name ecmwf_grib.

You could just leave out the hdf5 dependency of CDO and do without the hl-interface, but the non-thread-safty still remains.

Do you recommend to leave it out? I am not a cdo user so I am not sure how bad that would impact them.

to become a maintainer: I'm still pretty new to conda and I do not use it regularly. So I guess, I'll cause more harm than happiness ;-)

The conda part is easy and you can leave that to me. The info you gave me above is what is we are missing 😉

[Try2Code]

I'd recommend to install hdf5 thread-safe. Most people will not even realise, that they area using the library and here missing thread-safty can cause real trouble. And this is not only about CDO, but possible to a large number of tools.

enable the hl-interface and thread-safe and --enable-unsupported

before some 1.8.x release, there was no need to give an extra "unsupported" flag - I guess, they got too many user requests in the past, so they dropped the support. But, I'm surley not an hdf5-expert, who knows all the internals. From a user/programmers-perspective, thread-safty definitely has a high prio.

hth
ralf

[ocefpaf]

I'd recommend to install hdf5 thread-safe.

👍 but for that we need to wait for conda-forge/hdf5-feedstock#48

From a user/programmers-perspective, thread-safty definitely has a high prio.

Help us by making some noise in conda-forge/hdf5-feedstock#48 😉

[ocefpaf]

We are having many issues linking with the extra libraries on OS X (jasper, libxml2, curl, proj4, etc) not sure what is going on I know that at least jasper and proj4 were working before 😒

I do not have an OS X machine to debug this further but I will keep trying with Travis-CI.