Upgrade to hdf5 1.8.18

[qwhelan]

A few CVEs were reported and fixed in hdf5 back in November 2016: http://blog.talosintelligence.com/2016/11/hdf5-vulns.html

The hdf5 release notes for that release are available here: https://support.hdfgroup.org/ftp/HDF5/current18/src/hdf5-1.8.18-RELEASE.txt

For additional info, please see: conda-forge/hdf5-feedstock#68 and conda-forge/hdf5-feedstock#71

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• Failed to even lint the recipe (might be a conda-smithy bug) 😢

[isuruf]

Does this PR really bump HDF5 to 1.8.18 ? Looks like conda-forge.yml needs to be updated

[183amir]

It doesn't matter. This is a deprecated feedstock. All bob packages are. We have our own channel now. I merged this so that people don't bother debugging this.

[CJ-Wright]

Does that mean that these packages should no longer be on conda-forge?

[183amir]

You mean remove the old packages or remove the feedstocks?

[ChrisBarker-NOAA]

I don't think we should ever remove pacakges unless they are truly broken or, worse, contaminated with malware or something.

As for the feedstock, it would be nice to have a standard way to mark a feedstock as no-longer-maintained -- that would be better than removing it.

Maybe we could simply update the README?

[CJ-Wright]

👍 on the README, although it would be nice to have something somewhere that is a bit more bot friendly (although I guess we could parse the README?) so we can tell the bot not to tick things (otherwise the bot will get swamped bumping things that won't get merged)

[ChrisBarker-NOAA]

yeah, it would be good to have a more tool-friendly indication:

A non_longer_maintianed file??

it's presence could indicate that it's no longer maintained, and optionally its contents could have explanation, and links to other sources, etc.

[isuruf]

Or something like

extras:
  deprecated: true

[183amir]

Please do whatever you see is necessary. I don't want to maintain these feedstocks anymore and there are 30 of them.

[ChrisBarker-NOAA]

I'm curious -- why did you decide to keep your own channel?

I'm trying to do the opposite, and move everything to conda-forge, so that I don't have to maintain anything that others are already doing, can take advantage of the nice automation, and it will be easier / more likely for people to find it.

So I'm wondering why you've gone the other route?

-CHB

[183amir]

I'm curious -- why did you decide to keep your own channel?

We started using conda and conda-forge in 2016 but at least then there were a couple of problems that we decided to move away from conda-forge (they might not exist now):

• I think the biggest frustration that we had was stability of packages. I remember one day python 3.6rc1 or something was released in the channel and it just broke everything for us. To us, conda-forge looked like a test bench for Continuum (back then at least) where they test and break here first and then push to defaults when looks good.
• Lack of compatibility with the defaults channel. defaults was using the old C++ ABI while conda-forge the new ABI and not all dependencies were available in conda-forge then.
• conda-forge used to delete some packages (not sure) and as Bob is a reproducible research framework that was a big no no. We wanted our environment.yaml files to be always reproducible.
• more control and freedom over what should be done.
• My memory is foggy though. Not all I said above might be true.

Anyways, we have come a long way since then. Now all bob packages are deeply integrated into conda. We even re-wrote our CI based on dynamic conda recipes, recently. (e.g. https://gitlab.idiap.ch/bob/bob.io.image/blob/c581fe5fffb6d22484154de0d2e76bbb21caa1c5/conda/meta.yaml) With every push we build the conda package of that package and run the tests using conda-build recipes. When everything is good, the built package is uploaded to our (beta) channel. When someone creates a git tag in the package, it will automatically build a stable version and uploads it in our (stable) channel.
Basically the developers are now forced to do the packaging work too as that is part of the CI too.

This took us months to figure out on how to do this properly but it would have not been possible without conda-build 3. I would say what we have now is truly amazing since we are only a few people and developing/maintaining 80+ packages. Hence, it was really important for us that anyone who changes the code also keeps the conda recipe up-to-date.