3.16.6

[dalcinl]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] 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.

[dalcinl]

@minrk @isuruf Any idea why the bot did not pick this version update? Should we change anything in the recipe? Or it is just the bot being unable to handle this particular download URL?

[dalcinl]

The arm64 builds with scalar-type=complex on Travis CI are failing for unknown reasons (make is being killed). What should I do?

[minrk]

If make is being killed, resource limits are the most common cause. My inclination would be to:

1. skip linux+aarch64+complex with a note,
2. merge, and then
3. open a new PR reinstating the broken builds to investigate

One option would be to switch the linux_aarch64 builds to azure in conda-forge.yml:

provider: 
  linux_aarch64: azure

IIRC, That may have more resources, but I think it will also be much slower. You might give that one go before removing the builds.

[minrk]

Thanks @isuruf!

[dalcinl]

I'm confused. According to documentation and actual code, conda-build sets CPU_COUNT from multiprocessing.get_cpu_count(), exactly as PETSc does. Is conda-forge tweaking the value of CPU_COUNT?

[isuruf]

Is conda-forge tweaking the value of CPU_COUNT?

Yes. multiprocessing.get_cpu_count() gets things wrong inside travis containers. It shows 44 cores, but we get only 2 in reality.