Fix conda action boost dependency

[johnwason]

Attempt to fix the failing conda tests caused by boost dependency error.

[johnwason]

@traversaro I am getting another dependency problem from conda: https://github.com/tesseract-robotics/tesseract/actions/runs/12057112091/job/33621028026

[traversaro]

Interesting, it seems something is still pulling boost-cpp . I will check this tomorrow morning (in Europe). If I do not feel free to ping me.

[traversaro]

@traversaro I am getting another dependency problem from conda: https://github.com/tesseract-robotics/tesseract/actions/runs/12057112091/job/33621028026

I may be missing something, but those job seem to refer to a commit where boost-cpp is still used? See

tesseract/.github/workflows/conda/recipe/meta.yaml

Line 24 in f79d8ce

- boost-cpp

.

[johnwason]

I grabbed the wrong log link. This is for the branch that uses libboost-devel https://github.com/johnwason/tesseract/actions/runs/12059352095/job/33627810158

[traversaro]

Ah, ok! The problem is that you are requiring pcl >= 1.14.1 that was built after the libboost 1.86 migration, but also pinning libboost to 1.84 (probably as you depend on the main conda-forge-pinnings)? As the liboost 1.86 migration is quite progressed (and we just build ompl for boost 1.86 as well, see conda-forge/ompl-feedstock#51) probably you can override the conda-forge pinning and pin libboost to 1.86 ?

[johnwason]

The script runs conda-smithy as part of the CI process so I don't think we have any pins: https://github.com/johnwason/tesseract/blob/d63aa65982c398b200dbcb4ee67a501605e9d452/.github/workflows/conda.yml#L84

[traversaro]

The script runs conda-smithy as part of the CI process so I don't think we have any pins: https://github.com/johnwason/tesseract/blob/d63aa65982c398b200dbcb4ee67a501605e9d452/.github/workflows/conda.yml#L84

I guess you get the conda-forge global binnings via conda-smithy, that at the moment are inconsistent as they prescribed to use pcl 1.4.1 and boost 1.84, but in conda-forge it is not a problem as all packages using pcl have been migrated to boost 1.86. To override the conda-smithy pinnings, you can add a conda_build_config.yaml file next to the recipe with the override, where you can override either the boost or pcl pinning.

[johnwason]

@traversaro It looks like assimp is specifically pinning to libboost_devel 1.86: https://github.com/conda-forge/assimp-feedstock/blob/cab7e2d0ef5f51f4654e05b060401255f16555a8/.ci_support/migrations/libboost186.yaml#L7

The global pinning file still has libboost 1.84: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/a5db2568f1bb32782ccebb9edf196343da9718d1/recipe/conda_build_config.yaml#L477

Why is this being done? All the libraries should have the same boost version so they can be compiled together.

[traversaro]

Why is this being done? All the libraries should have the same boost version so they can be compiled together.

This is how migration work at the moment. Basically if liboost 1.84 is pinned at global level, the migration PRs will migrate all the packages that depend on libboost to use 1.86 (and 1.86 only, to avoid the explosion of the build matrix). That works fine if migration are opened and closed fast, while if that is not happening you can start seeing version of packages that are only available with 1.86, while the global pinning is still at 1.84 . At this point, as most conda-forge packages have been migrate to 1.86, the actual pinned 1.86 is effectively already 1.86, so you may want to override it locally until the boost 1.86 is actually completed : https://conda-forge.org/status/migration/?name=libboost186 .