version clash

[tdegeus]

Solution to issue cannot be found in the documentation.

• [X] I checked the documentation.

Issue

One of my dependencies seems to be pinned against libffi 3.4.*, but that is incompatible with ghc it seems:

package ghc-8.10.7-h4a049f1_0 requires libffi >=3.3,<3.4.0a0, but none of the providers can be installed

which in my opinion could be due to the fact that pinning should be changed, or the package should be rebuild.

Trying here: https://github.com/conda-forge/git-annex-feedstock/pull/154

Installed packages

- autoconf
    - automake
    - binutils
    - bzip2
    - coreutils
    - findutils
    - gmp
    - libffi
    - libtool
    - libxml2
    - make
    - ncurses
    - perl
    - pkg-config
    - stack
    - xz
    - dbus
    - gmp
    - libffi
    - libiconv
    - libmagic
    - lsof
    - ncurses
    - openssh
    - rsync
    - sqlite
    - zlib
    - curl
    - git >=2.22
    - gnupg >=2.1.1
    - lsof
    - openssh
    - rsync

Environment info

-

[yarikoptic]

I think this package went did not go though libffi 3.4 migration like attempted / tested in https://github.com/conda-forge/git-annex-feedstock/pull/128 for git-annex . May be someone knowledgeable could request bot to request similar migration PR here?

[yarikoptic]

pinging maintainers on this package/issue.

[yarikoptic]

Dear @conda-forge/core - if you could try to make this package to go through libffi 3.4 migration -- would be appreciated

[hmaarrfk]

conda forge is a volunteer run effort. it isn't for core to maintain all the packages, rather, to guide others in their maintenance efforts.

consider making a PR for an updated versions of this recipe.

[hmaarrfk]

Just to complete my thought above, anybody can make a PR to update a version.

Sometimes original maintainers cannot make the PRs themselves, but they will review.

If they take too long to review (2 weeks), then pining core members becomes OK and we can help push a PR through.

[yarikoptic]

@hmaarrfk thanks for chiming in! I was pinging core primarily to get a pointer for libffi 3.4 migration HOWTO or an instruction to a bot if that is what it takes. As an "occasional" conda-forge contributor I tend to forget specific instructions for particular migrations, etc... Any guidance would be appreciated.

[jakirkham]

Maybe these docs help?

[hmaarrfk]

some packages that are abandoned don't go through our migrations.

it seems the latest pinning is at 3.4 https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/e5206766771131eaa6d0110d642a24aaed4dcc16/recipe/conda_build_config.yaml#L466

rerender the recipe. bump the build number (or ideally the version number to the latest) and get the CIs to pass

[yarikoptic]

rerender the recipe.

initial attempt failed, filed

• https://github.com/conda/conda/issues/13345

[yarikoptic]

Maybe these docs help?

thanks! indeed they do although not sure now about that migration since it is declared "done":

• https://github.com/conda-forge/conda-forge-pinning-feedstock//commit/ee63cf5851d3dd6d39e75c7a35cdea29d650e660

[hmaarrfk]

@conda-forge-admin please rerender

[conda-forge-webservices[bot]]

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

I just wanted to let you know that I started rerendering the recipe in conda-forge/ghc-feedstock#37.

[jaimergp]

initial attempt failed, filed

conda/conda is not likely the issue here. I'd try in conda-forge/conda-smithy. That said, it looks like a missing version variable. Given:

  - {{ c_compiler }}_{{ target_platform }} >={{ c_compiler_version }}

We expect:

  - gcc_linux-64 >=1.2.3

But if c_compiler_version is undefined, you'd get.

  - gcc_linux-64 >=

Hence the "version" error. The operator on its own is not valid.

The actual question here is why are we not using {{ compiler('c') }}? 🤔

[yarikoptic]

conda/conda is not likely the issue here. I'd try in conda-forge/conda-smithy.

yeap, FWIW refiled as https://github.com/conda-forge/conda-smithy/issues/1804 and most likely you are just right that some prior template variable was made unavailable now. Well, there is still description of c_compiler_version at https://docs.conda.io/projects/conda-build/en/stable/resources/variants.html#compiler-versions but the question is really do we need such a versioned check here at all? it was added in 8c923d6c8dedc99017209b516de2fc851c608c41 by @isuruf , but there were no description why it needs to be versioned.

[yarikoptic]

let's see if builds in https://github.com/conda-forge/ghc-feedstock/pull/39