NO MRG: Test building with conda-build 2.0.x and conda 4.2.x

[jjhelmus]

No description provided.

[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:

• The recipe license should not include the word "License".

[jjhelmus]

Commit 5960e39 pulls in three packages (ncurses, openssl, and curl) from the jjhelmus/label/bootstrap channel which were copied from the defaults channel and support installation into a long prefix environment. Without these a short (80) character prefix environment is used for the build.

[jakirkham]

So I'm unclear on if we can tell if that fixes the issue as upgrading to the newer conda seemed to already fix it. Would be worthwhile to drop the conda upgrade and see if that still works?

[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.

[jjhelmus]

So I'm unclear on if we can tell if that fixes the issue as upgrading to the newer conda seemed to already fix it. Would be worthwhile to drop the conda upgrade and see if that still works?

Nope, using conda 4.1.12 results in the cmake: error while loading shared libraries: libarchive.so.13: cannot open shared object file: No such file or directory issue

[jakirkham]

So it sounds like the fix is just to upgrade conda then and it doesn't matter if we rebuild anything, right?

[jjhelmus]

So it sounds like the fix is just to upgrade conda then and it doesn't matter if we rebuild anything, right?

That will result in builds which work but produces packages with a short 80 character prefix. It is a step forward but more is needed.

[ocefpaf]

I think this one is safe to close. Please re-open it I am wrong.