Refresh requirements

[jakirkham]

Updates conda-build's requirements based on it's included meta.yaml.

Checklist

• Used a fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

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

[jakirkham]

jakirkham requested a review from stuertz as a code owner now

Weird. Definitely did not do that. Seems GitHub has a mind of its own.

---

Though I did request a review from you Mike. 🙂

[isuruf]

@jakirkham, can you add ripgrep too? #102

[jakirkham]

Let’s handle that separately. Right now I just want to get the requirements correct, which they are not currently.

[jakirkham]

@msarahan, could you give this a quick look please?

[msarahan]

bump CPH, otherwise fine

[jakirkham]

Thanks for giving it a look. Can do. 🙂

[scopatz]

Looks like it is failing on mac

[jakirkham]

Sounds like some sort of other issue outside of this PR then. Presumably we were already using the latest version of conda-package-handling, which is already 1.3+.

[scopatz]

Yeah, I am seeing this in staged-recipes too: conda-forge/staged-recipes#8651

[jakirkham]

Yeah it affected the JupyterLab 1.0.1 PR too ( conda-forge/jupyterlab-feedstock#158 ).

[mariusvniekerk]

Restarted the failed builds and seems to be okay now

[jakirkham]

FWIW we probably don't want to merge this until we are ready to go back to the new version of conda-build.

[mariusvniekerk]

Or until we have some patches (eeew) that make it work

[mariusvniekerk]

I'm not entirely sure what the build errors are on the emulated platforms. It suggests that there may be some issues with how qemu operates since we moved to 4.0.0-5 Should we roll that back to the last good 3.x release?

[jjhelmus]

I'm not entirely sure what the build errors are on the emulated platforms. It suggests that there may be some issues with how qemu operates since we moved to 4.0.0-5 Should we roll that back to the last good 3.x release?

These errors have been seen in a few other recipes:

• Split out static libraries and update to 1.1.1c openssl-feedstock#46
• See if we can just add aarch64 and ppc64le fribidi-feedstock#2

If reverting to qemu 3.x fixes this I would be in favor.

[mbargull]

Looks like @mariusvniekerk is spot-on:

>>> docker run --rm -it --entrypoint='' mbargull/condaforge-linux-anvil-aarch64:qemu-3.1.0-3 /opt/conda/bin/python -c 'import os;os.listxattr(".");print("all good")'
all good
>>> docker run --rm -it --entrypoint='' mbargull/condaforge-linux-anvil-aarch64:qemu-4.0.0-5 /opt/conda/bin/python -c 'import os;os.listxattr(".");print("all good")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 38] Function not implemented: '.'

[mariusvniekerk]

Reverted to qemu 3.1 and its now fine

[jakirkham]

Ok, feel free to merge then 🙂