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]

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?

Unfortunately not, unless you use a Windows Virtual Machine.

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

The macOS failure is related to RoboStack/vinca#134, which I believe is an issue we have run into several times before. I have opened a PR in Vinca to address it. In the meantime, I am planning to refresh the snapshot here again, which should also resolve the problem.
The good news is that, after this refresh, we should be able to remove around 25 patches since MoveIt cut a new release a few days ago.

[traversaro]

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

I am back at my laptop, I reproduced the issue and I am preparing an upstream PR for this.

[mini-1235]

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

I am back at my laptop, I reproduced the issue and I am preparing an upstream PR for this.

Thanks so much! I really appreciate it. I was still working through some of the other failures after the snapshot update

[traversaro]

I will spend some more time on this today to see if I can fix it. Otherwise, I would really appreciate some help from the maintainers or others in the community, as it is quite difficult for me to borrow a Windows laptop for testing these days.

I am back at my laptop, I reproduced the issue and I am preparing an upstream PR for this.

Here you are: gazebosim/ros_gz#930 .

[traversaro]

Thanks so much! I really appreciate it. I was still working through some of the other failures after the snapshot update

Thank you for all the work on this PR and on RoboStack in general!

[mini-1235]

Thanks so much! I really appreciate it. I was still working through some of the other failures after the snapshot update

Thank you for all the work on this PR and on RoboStack in general!

And thank you for all the help, and for maintaining such a great project 😄

[mini-1235]

Hello @traversaro @Tobias-Fischer @wep21, I think this is ready for review now.

For some reason I don't understand, the last few runs have kept hitting this error:

Error:   × FileSystem error: 'Path "/Users/runner/work/ros-rolling/ros-rolling/
  │ output/src_cache/rcl-release.git/.git/objects/maintenance.lock" does not
  │ exist or you don't have access!'

I am not quite sure what's causing it.

The macos-15-intel job also only restored part of the cache, so it is still building. It did pass in some earlier runs, though, so I am assuming it should pass once the build finishes.

Please take a look when you have time. Thank you!

[traversaro]

Hello @traversaro @Tobias-Fischer @wep21, I think this is ready for review now.

Amazing work!

[traversaro]

Minor, but that sounds like we should actually have generate_dummy_package_with_run_deps for these packages, so this kind of substitution would happen automatically (that is also the issue tracked in RoboStack/robostack.github.io#116).

[traversaro]

Also, cyclonedds itself seems to have been updated and aligned with robostack builds thanks to @nmarticorena and @Tobias-Fischer (see conda-forge/cyclonedds-feedstock#16), so I wonder if we could generate_dummy_package_with_run_deps directly cyclonedds?