Closed conda-forge-admin closed 2 months ago
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.
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.
@hmaarrfk Ok so what I'm thinking is that changing the pinning of libxcb inside this feedstock to 'x', then it should fix it.
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.
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 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.
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.
@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.
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
Following up: https://github.com/conda-forge/libva-feedstock/issues/41
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.