bump build and rerender with conda-forge-pinning 2021.06.07.07.55.19

[izahn]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [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.

Fixes https://github.com/conda-forge/qt-feedstock/issues/193

See details there.

I built it for linux locally but failed to persist the build log :-( I guess python build_locally.py does not do that for you...

The build artifact is at https://anaconda.org/izahn/qt and what I have of the build log is at https://gist.github.com/izahn/3bc5da52013046c4feda7a6c45aba262

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

[izahn]

Is there anyone here with access to osx willing to investigate the package conflict issue on that platform?

[izahn]

ooh, I just found https://conda-forge.org/docs/maintainer/maintainer_faq.html#mfaq-mamba-local -- tying that now!

[izahn]

It says

The reported errors are: Encountered problems while solving:

• package clangxx_osx-64-11.0.0-hc3ec130_0 requires clang_osx-64 11.0.0 h05bbb7f_0, but none of the providers can be installed

I also see warnings like

WARNING Found corrupted repodata_record file "/Users/runner/miniforge3/pkgs/libcxx-11.1.0-habf9029_0/info/repodata_record.json"

Any ideas?

[wolfv]

@izahn ignoring the corrupted repodata_record stuff, I think the issue is

 - clangxx_osx-64 11.*
 - libclang >=12.0.0,<13.0a0

The libclang version is 12.x, while clangxx is 11.x

IDK why that is

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

• requirements: host: clangdev=11 must contain a space between the name and the pin, i.e. clangdev =11
• requirements: host: libclang=11 must contain a space between the name and the pin, i.e. libclang =11

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

[izahn]

I think this is in good working order now and ready for review. It just rebuilds against zstd 1.5 for compatibility with r-base 4.1 (and presumably anything else depending on zstd 1.5).

[isuruf]

This is because mysql is pinned too strictly. Please open an issue in mysql-feedstock.

[izahn]

This is because mysql is pinned too strictly. Please open an issue in mysql-feedstock.

Thank you @isuruf , I have to confess that I don't understand conda-forge pinning machinery well but I did my best over in https://github.com/conda-forge/mysql-feedstock/issues/48

[Quogu]

Hi @isuruf, could you please merge this MR, or a similar change that increments the build number? This is because an instance of the package with the exact version and build string (qt-5.12.9-hda022c4_4) was previously published and then republished with different dependencies, and this plays badly with third party tools (such as mirrors of conda-forge) that make assumptions about packages of a given version and build string being immutable. Bumping the build number would really help out users who ingested the previous package and are having trouble using the fixed version such as myself.