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

[Tobias-Fischer]

Amazing work, many thanks for this!!

[wep21]

unvendor iceoryx is preferable, same as ros-lyrical full rebuild PR.

[mini-1235]

unvendor iceoryx is preferable, same as ros-lyrical full rebuild PR.

I will take a look this Sunday

[mini-1235]

I am running into this because the ur_* packages set the CMake version to 3.28 and CXX_STANDARD to 20. On macOS, that causes a clang-scan-deps not found error during compilation:

https://discourse.cmake.org/t/cmake-3-28-cmake-cxx-compiler-clang-scan-deps-notfound-not-found/9244/2

My current workaround feels more like a hack than a proper solution. Another approach I tried was installing clang_tools and explicitly setting:

ur_calibration:
  additional_cmake_args: "-DCMAKE_CXX_COMPILER_CLANG_SCAN_DEPS=$BUILD_PREFIX/bin/clang-scan-deps"

That works as well, but it also feels like a workaround rather than a long-term fix, especially since more packages will likely start requiring CMake 3.28+ over time.

Any suggestions? @traversaro @Tobias-Fischer @wep21