Bump build number to 3

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I've started rerendering the recipe as instructed in #39.

If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!

Here's a checklist to do before merging.

• [ ] Bump the build number if needed.

[conda-forge-webservices[bot]]

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.

[hmaarrfk]

i mean technically we should just patch build 2 to add back the dependency, otherwise you are going to have a hard time recreating the issue.

[ehfd]

@hmaarrfk Ok so what I'm thinking is that changing the pinning of libxcb inside this feedstock to 'x', then it should fix it.

[ehfd]

I'm not sure if it's supposed to be ignore_run_exports than pinning alternatively somehow, or just - {{ pin_compatible('libxcb', max_pin='x') }}. @hmaarrfk

In fact, I don't completely understand the difference of pin_compatible and pin_subpackage to this day.

[hmaarrfk]

see proposed patch: https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/770

I checked the builds they seem to have a line that looks like

WARNING (libva,lib/libva-x11.so.2.2100.0): Needed DSO lib/libxcb.so.1 found in ['conda-forge/linux-ppc64le::libxcb==1.15=h4194056_0']

[hmaarrfk]

@hmaarrfk Ok so what I'm thinking is that changing the pinning of libxcb inside this feedstock to 'x', then it should fix it.

This is in fact one good question to ask on the feedstock itself.

Generally the concept of run_export is that the feedstock maintainers know best what they should declare.

[hmaarrfk]

or just - {{ pin_compatible('libxcb', max_pin='x') }}

This is no longer in fashion in 2024 since the "downstream" feedstock mainters (ie. you trying to build libva) would have to learn the inner workings to libxcb to put the appropriate max_pin value. The run_export strategy centralizes that knowledge in the libxcb feedstock where a single decision can be made.

[ehfd]

@hmaarrfk I think I mixed things up because I was doing a local conda-build on aarch64 where it was pinned to libxcb >=1.16.0,<1.17.0 and FFmpeg 6.1.* was pinned to >=1.15.0,<1.16.0 with no alternative libva versions.

So the commit for build 2 was probably unnecessary.

However, this does lead to unnecessary restrictions in the installation of this feedstock combined with other packages, so it should be fixed somehow.

[hmaarrfk]

yes again, this can be resolved if you create a clear reproducer with

conda create --name example "libva=2.21.0=*_1" "my_other_package>=VERSION"

and we can take it from there.

please start an issue on this feedstock

[ehfd]

Following up: https://github.com/conda-forge/libva-feedstock/issues/41