Full rebuild August 2026 bump ros2-distro-mutex to 0.19.0 and build number to 24

[mini-1235]

Summary

• refresh the Rolling rosdistro snapshot
• bump the rebuild number to 24 and mutex to 0.19.0
• refresh/remove patches that changed with the new source snapshot, including Foxglove SDK 0.26.0 hashes

Validation

• pixi run check-patches
  • Total recipes tested: 94
  • Passed: 94
  • Failed: 0
• git diff --check

Full package rebuild is intended to run in CI.

[mini-1235]

I need newer versions of some packages, so I asked my agent to help prepare this PR. I will mark it as ready once all checks are green and I have completed a self review

[traversaro]

I need newer versions of some packages, so I asked my agent to help prepare this PR. I will mark it as ready once all checks are green and I have completed a self review

Great thanks! I think @Tobias-Fischer contributed a lot of patches upstream in this period (see RoboStack/robostack.github.io#16). I am not sure how many of those have been actually merged and released, but I guess this is an information that could be useful as context for your agents.

[mini-1235]

Hi @traversaro, during a local full rebuild of ros-rolling on macOS arm64, I hit a failure in ros-rolling-resource-retriever.

The package builds with C++20 and uses std::format in several files:

• src/exception.cpp
• src/plugins/curl_retriever.cpp
• src/plugins/retriever_plugin.cpp

The build fails because libc++’s std::format implementation instantiates floating-point formatting code that depends on std::to_chars(long double, ...), which is unavailable below macOS 13.3.

Representative error:

$BUILD_PREFIX/bin/../include/c++/v1/__format/formatter_floating_point.h:66:30:
error: 'to_chars' is unavailable: introduced in macOS 13.3

$SRC_DIR/ros-rolling-resource-retriever/src/work/src/plugins/retriever_plugin.cpp:114:14:
note: in instantiation of function template specialization 'std::format<const std::string_view &>' requested here

Would it be possible to raise the macOS deployment target for Rolling to at least 13.3, so packages using C++20 std::format can build without patching each package individually? I believe we have 11.0 now

ros-rolling/conda_build_config.yaml

Line 62 in b1cd6ac

- 11.0 # [osx and arm64]

(?)

Or are there any alternatives that you would suggest?

[mini-1235]

Related PR ros/resource_retriever#123

[traversaro]

Hi @traversaro, during a local full rebuild of ros-rolling on macOS arm64, I hit a failure in ros-rolling-resource-retriever.

The package builds with C++20 and uses std::format in several files:

• src/exception.cpp
• src/plugins/curl_retriever.cpp
• src/plugins/retriever_plugin.cpp

The build fails because libc++’s std::format implementation instantiates floating-point formatting code that depends on std::to_chars(long double, ...), which is unavailable below macOS 13.3.

Representative error:

$BUILD_PREFIX/bin/../include/c++/v1/__format/formatter_floating_point.h:66:30:
error: 'to_chars' is unavailable: introduced in macOS 13.3

$SRC_DIR/ros-rolling-resource-retriever/src/work/src/plugins/retriever_plugin.cpp:114:14:
note: in instantiation of function template specialization 'std::format<const std::string_view &>' requested here

Would it be possible to raise the macOS deployment target for Rolling to at least 13.3, so packages using C++20 std::format can build without patching each package individually? I believe we have 11.0 now

ros-rolling/conda_build_config.yaml

Line 62 in b1cd6ac

- 11.0 # [osx and arm64]

(?)

Or are there any alternatives that you would suggest?

Ok for me, but @Tobias-Fischer is more the macOS expert.

[Tobias-Fischer]

OK for me, too, thanks!

let’s also make use of RoboStack/vinca#104

[mini-1235]

@Tobias-Fischer After some local testing, I think we also need to bump Vinca’s OSX_DEPLOYMENT_TARGET to 13.3 in the generated build templates, for example here:
https://github.com/RoboStack/vinca/blob/4a2f33b8dbbcb49cc6b98012dac1648e4fbc3a5e/vinca/templates/build_ament_cmake.sh.in#L17-L25

Does that sound right before I open a Vinca PR?

[Tobias-Fischer]

We should be able to simply remove it these days

[mini-1235]

All green now! Let me know if any other changes needed. If no, I can then remove the 6x rm -rf * in testpr.yml before merging

[traversaro]

Is this necessary? I would expect not, which error do you get if you omit them.

[mini-1235]

Ah, I forgot to remove them, I don't think this is needed

[traversaro]

Minor comments, thanks a lot for the great work!

[traversaro]

By the way, do you know of any good way to run the Windows build on macOS so I can reproduce the issue locally instead of relying on CI for testing?

Just for completeness, I discovered that there is some support for linux --> windows cross-compilation in https://github.com/conda-forge/clang-win-activation-feedstock , but it is not super-documented and I am not sure how much it would work for robostack.

[mini-1235]

Just for completeness, I discovered that there is some support for linux --> windows cross-compilation in https://github.com/conda-forge/clang-win-activation-feedstock , but it is not super-documented and I am not sure how much it would work for robostack.

Thanks! I will give it a try when I have time

[mini-1235]

CI passes after dab44f4, I will go ahead and revert the 6x rm -rf changes in testpr.yml

[mini-1235]

Out of curiosity, and also so I know for future contributions, is there any policy or guideline for the versions specified in conda_build_config.yaml, similar to what we have in ROS?

For this PR, I mostly copied the versions from RoboStack/ros-lyrical#34 and only updated the ones that caused conflicts

[traversaro]

Out of curiosity, and also so I know for future contributions, is there any policy or guideline for the versions specified in conda_build_config.yaml,
For this PR, I mostly copied the versions from RoboStack/ros-lyrical#34 and only updated the ones that caused conflicts

Ideally that should be aligned with the latest from conda-forge pinnings (i.e. https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml) plus the most advanced migration (i.e. https://github.com/conda-forge/conda-forge-pinning-feedstock/tree/main/recipe/migrations, https://conda-forge.org/status/#migrations). Which migrations to include is the tricky part.

similar to what we have in ROS?

This is the tricky part. conda-forge is a rolling release distribution, so we can't just fix versions, as we would not be compatible with newly added package, as opposed to Ubuntu/Fedora that are stable distros that for the whole lifetime of the distro version do not change the version. Each model as its own pro and cons, and I think they are actually quite complementary (all the work that we do for packaging ROS in a rolling release distributions, just make it easier for Ubuntu/Fedora-based packaging to update to new distros). See RoboStack/robostack.github.io#135 . Do have a different workflow, you would need to have stable conda-based distros, something that is possible in theory/technically, but as far as I know now community is maintaining.

[traversaro]

Go for me, but I would like a green flag from @wep21 or @Tobias-Fischer !

[wep21]

Awesome work!

[traversaro]

Sorry, I missed this, this would constraint any ROS package to a specific patch version of libgdal, while the run_exports of libgdal is x.x, so in the future this is really too constraining. Do you recall why that was necessary? Can't we just pin libgdal in conda_build_config.yaml ?

[traversaro]

Ok, I suspect I know this problem, at least looking at https://index.ros.org/d/libgdal-dev/, it is the same of conda-forge/gz-common-feedstock#96 . Let me attempt a fix, I think we can merge after that fix.

[mini-1235]

It was because of this CI failure.
I don't have a very good understanding of what should be pinned in a mutex versus what should be pinned in conda_build_config.yaml. Could you give me a short explanation? I saw vtk was pinned there, so I added to there in the first place

[traversaro]

I want actually to open an issue suggesting to remove all the run_constraints from the mutex. :D

In a nutshell, any run_constraint in the mutex ensures that all ros packages in the rebuild can only be installed with the specified version of those packages. So even if you are only installing ros2-rclcpp/ros-rolling-rclpp that does not depend at all on libgdal, with a run_constraint like that you can only install ros-rolling-rclcpp with libgdal 3.13.1, not for example with libgdal 3.13.3 .

On the other hand, conda_build_config.yaml constraints are only considered when the specified version is explicitly listed as a dependency.

Back in time, we added a lot of constraints to mutex's run_constraint as it worked fine even when the run_exports of the packages were not present, or the dependencies metadata was wrong. I think we solved most of those cases over the time, so I would really like to get rid of most of those mutex's run_constraints, or at least not add more.

[traversaro]

I want actually to open an issue suggesting to remove all the run_constraints from the mutex. :D

In a nutshell, any run_constraint in the mutex ensures that all ros packages in the rebuild can only be installed with the specified version of those packages. So even if you are only installing ros2-rclcpp/ros-rolling-rclpp that does not depend at all on libgdal, with a run_constraint like that you can only install ros-rolling-rclcpp with libgdal 3.13.1, not for example with libgdal 3.13.3 .

On the other hand, conda_build_config.yaml constraints are only considered when the specified version is explicitly listed as a dependency.

Back in time, we added a lot of constraints to mutex's run_constraint as it worked fine even when the run_exports of the packages were not present, or the dependencies metadata was wrong. I think we solved most of those cases over the time, so I would really like to get rid of most of those mutex's run_constraints, or at least not add more.

[traversaro]

I think 0596f22, b5248bb and 6170db4 should have mitigate most problems you could have.

[mini-1235]

Thanks for the help @traversaro !

[mini-1235]

I see many workflows are failing, not sure if it is related to this PR