gepetto-viewer-corba v5.8.0

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• Dependencies have been updated if changed: see upstream
• Tests have passed
• Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name	Upstream Version	Current Version
qt-main	6.2.4

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: disabled to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis by source code inspection shows a discrepancy between it and the the package's stated requirements in the meta.yaml.

Packages found by source code inspection but not in the meta.yaml:

• urdf-parser-py
• numpy
• ros-roslib
• docutils
• omniorb
• cython
• sphinx
• pyyaml
• pygments

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/cf-scripts/actions/runs/8498255197, please use this URL for debugging.}

[conda-forge-webservices]

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.

[h-vetinari]

There's some mismatch happening here:

    omniorb:                   4.3.2-py310hc61f13b_2      conda-forge
    omniorb-libs:              4.3.2-h4514ac0_2           conda-forge
    omniorbpy:                 4.3.1-py310h546aac4_0      conda-forge

@conda-forge/omniorb it seems the metadata is not sufficiently constrained, i.e. the run-export of omniorb needs to go down to the patch level ('x.x.x') instead of just the minor version. Aside from that, merging conda-forge/omniorb-feedstock#48 (CC @beenje) should normally happen in sync with an an update for omniorbpy.

[beenje]

@conda-forge/omniorb it seems the metadata is not sufficiently constrained, i.e. the run-export of omniorb needs to go down to the patch level ('x.x.x') instead of just the minor version. Aside from that, merging conda-forge/omniorb-feedstock#48 (CC @beenje) should normally happen in sync with an an update for omniorbpy.

Sorry, I don't use omniorbpy.
cpptango only relies on omniorb and it is ABI compatible between patch releases.
Compiling with 4.3.0 and using 4.3.2 at run time works fine. I would prefer to not change the run-export.

I know that omniorb and omniorbpy come from the same svn repo.
Maybe it would make sense to move omniorbpy to the omniorb-feedstock and build it as another output?
It would then be easy to pin the dependency to the exact package. And that would make sure they are updated at the same time.

[ymontmarin]

@conda-forge-admin, please restart ci

[conda-forge-webservices]

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 do have some suggestions for making it better though...

For recipe:

• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.

[lockhart]

This is a long-standing problem where omniorbpy in the conda config does not constrain the omniorb pre-requisite to be *the exact same version* so builds a mis-matched combo. How would I adjust the omniorbpy meta.yaml (or other file) to provide this more rigorous constraint? I’m available to work on this and would like to help solve it. Thanks! - Tom

…

On Apr 28, 2024, at 5:23 PM, h-vetinari ***@***.***> wrote: There's some mismatch happening here: omniorb: 4.3.2-py310hc61f13b_2 conda-forge omniorb-libs: 4.3.2-h4514ac0_2 conda-forge omniorbpy: 4.3.1-py310h546aac4_0 conda-forge @conda-forge/omniorb <https://github.com/orgs/conda-forge/teams/omniorb> it seems the metadata is not sufficiently constrained, i.e. the run-export of omniorb needs to go down to the patch level ('x.x.x') instead of just the minor version. Aside from that, merging conda-forge/omniorb-feedstock#48 <conda-forge/omniorb-feedstock#48> (CC @beenje <https://github.com/beenje>) should normally happen in sync with an an update for omniorbpy. — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANLDAPORHJWRH5EURL43WTY7WHJPAVCNFSM6AAAAABFQM42EOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRG4YTOMJTG4>. You are receiving this because you are on a team that was mentioned.

[beenje]

This is a long-standing problem where omniorbpy in the conda config does not constrain the omniorb pre-requisite to be the exact same version so builds a mis-matched combo. How would I adjust the omniorbpy meta.yaml (or other file) to provide this more rigorous constraint? I’m available to work on this and would like to help solve it. Thanks! - Tom

As mentioned in my comment above, I think the easiest would be to move omniorbpy to the omniorb-feedstock and archive omniorbpy-feedstock, so they are always released together.
Do you want to try?

[lockhart]

Yes I’ll try. Any examples of a similar configuration with two separate products in one conda package? omniorbpy will need to find and run some python code in omniorb to build successfully. - TomOn May 6, 2024, at 11:50 PM, Benjamin Bertrand ***@***.***> wrote: This is a long-standing problem where omniorbpy in the conda config does not constrain the omniorb pre-requisite to be the exact same version so builds a mis-matched combo. How would I adjust the omniorbpy meta.yaml (or other file) to provide this more rigorous constraint? I’m available to work on this and would like to help solve it. Thanks! - Tom As mentioned in my comment above, I think the easiest would be to move omniorbpy to the omniorb-feedstock and archive omniorbpy-feedstock, so they are always released together. Do you want to try? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[beenje]

I'd look at https://conda-forge.org/docs/maintainer/knowledge_base/#multi-output-recipes

mamba-feedstock is mentioned and could be an example. It uses a single source but principle should be similar.

We can use https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#source-from-multiple-sources and use different build scripts.