Full Rebuild May 2026: bump ros2-distro-mutex to 0.9.0 and build_number to 18

[esteve]

This PR prepares a new full rebuild for ROS Humble with the following fixes:

• Pin rattler-build to >=0.57.0,<0.58 to avoid regression in the solver (see Full rebuild fails on ros-humble-ament-uncrustify package #400 and fix: respect run dependencies on sibling outputs for build ordering prefix-dev/rattler-build#2488)
• Pin poco to 1.15.0 because the version of libfranka on conda-forge that ROS Humble depends is built for 1.15.0 and letting Pixi upgrade poco would cause a conflict.
  • Not needed, libfranka can handle newer versions of poco Full Rebuild May 2026: bump ros2-distro-mutex to 0.9.0 and build_number to 18 #403 (comment)
• Replace uses of tl_expected with the vendored version in rcpputils, I've made it an explicit dependency, but it's included via rclcpp so there are some warnings about overdependency. tl_expected is deprecated and will be removed in ROS Lyrical Luth (see https://index.ros.org/p/tl_expected/#humble)
  • Use cpp-expect from conda-forge and expose it as a libexpect-dev rosdep key.
• Added PI values for autoware_ground_filter
• Fix constructor initialization for the ouster_ros package, somehow sysmacros.h is included and initializing major / minor using parenthesis would trigger the macros in sysmacros.h, so I changed it to use braces.
• Skip librealsense and downstream dependencies because the version available on conda-forge is too old (see Update librealsense to v2.57.7 conda-forge/librealsense-feedstock#83)
  • Thanks @traversaro for reviewing the PR so quickly!

[traversaro]

Pin poco to 1.15.0 because the version of libfranka on conda-forge that ROS Humble depends is built for 1.15.0 and letting Pixi upgrade poco would cause a conflict.

I think we should have the abi_migration_branches active for all libfranka versions in conda-forge to avoid this, so we should be able to use 1.15.1 as done in https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/9904691dfd1261cf018b55e2e6cb95f8a3fd69a4/recipe/conda_build_config.yaml#L892 . Currently we mantain 0.9.2 and 0.15.0 as old libfranka versions to be rebuilt with recent versions of deps, see https://github.com/conda-forge/libfranka-feedstock/blob/main/conda-forge.yml#L3-L5 . Can we use libfranka 0.21.2 here? If not, we can add 0.20.4 as abi migration branch in libfranka-feedstock (fyi @nmarticorena).

[traversaro]

Replace uses of tl_expected with the vendored version in rcpputils, I've made it an explicit dependency, but it's included via rclcpp so there are some warnings about overdependency. tl_expected is deprecated and will be removed in ROS Lyrical Luth (see https://index.ros.org/p/tl_expected/#humble)

Can't we just use the conda-forge package for it? That is the conda equivalent to "Use tl/expected.hpp from libexpected-dev".

[traversaro]

Replace uses of tl_expected with the vendored version in rcpputils, I've made it an explicit dependency, but it's included via rclcpp so there are some warnings about overdependency. tl_expected is deprecated and will be removed in ROS Lyrical Luth (see https://index.ros.org/p/tl_expected/#humble)

Can't we just use the conda-forge package for it? That is the conda equivalent to "Use tl/expected.hpp from libexpected-dev".

In a nutshell, I think we can just define the libexpected-dev rosdep key to cpp-expected, see https://prefix.dev/channels/conda-forge/packages/cpp-expected and http://github.com/conda-forge/cpp-expected-feedstock .

[traversaro]

@esteve can we use the "Full Rebuild May 2026: bump ros2-distro-mutex to 0.9.0 and build_number to 18" title scheme, used in other PRs? That make it easier to find full rebuilds PR by specifying the build number and the mutex version.

[esteve]

Replace uses of tl_expected with the vendored version in rcpputils, I've made it an explicit dependency, but it's included via rclcpp so there are some warnings about overdependency. tl_expected is deprecated and will be removed in ROS Lyrical Luth (see https://index.ros.org/p/tl_expected/#humble)

Can't we just use the conda-forge package for it? That is the conda equivalent to "Use tl/expected.hpp from libexpected-dev".

In a nutshell, I think we can just define the libexpected-dev rosdep key to cpp-expected, see https://prefix.dev/channels/conda-forge/packages/cpp-expected and http://github.com/conda-forge/cpp-expected-feedstock .

I've replaced tl-expected with cpp-expected / libexpected-dev in 51e4152, does that address your feedback?

[esteve]

Pin poco to 1.15.0 because the version of libfranka on conda-forge that ROS Humble depends is built for 1.15.0 and letting Pixi upgrade poco would cause a conflict.

I think we should have the abi_migration_branches active for all libfranka versions in conda-forge to avoid this, so we should be able to use 1.15.1 as done in https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/9904691dfd1261cf018b55e2e6cb95f8a3fd69a4/recipe/conda_build_config.yaml#L892 . Currently we mantain 0.9.2 and 0.15.0 as old libfranka versions to be rebuilt with recent versions of deps, see https://github.com/conda-forge/libfranka-feedstock/blob/main/conda-forge.yml#L3-L5 . Can we use libfranka 0.21.2 here? If not, we can add 0.20.4 as abi migration branch in libfranka-feedstock (fyi @nmarticorena).

I've removed the pin, Pixi should now pick whatever version of poco is compatible.

[traversaro]

Pin poco to 1.15.0 because the version of libfranka on conda-forge that ROS Humble depends is built for 1.15.0 and letting Pixi upgrade poco would cause a conflict.

I think we should have the abi_migration_branches active for all libfranka versions in conda-forge to avoid this, so we should be able to use 1.15.1 as done in https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/9904691dfd1261cf018b55e2e6cb95f8a3fd69a4/recipe/conda_build_config.yaml#L892 . Currently we mantain 0.9.2 and 0.15.0 as old libfranka versions to be rebuilt with recent versions of deps, see https://github.com/conda-forge/libfranka-feedstock/blob/main/conda-forge.yml#L3-L5 . Can we use libfranka 0.21.2 here? If not, we can add 0.20.4 as abi migration branch in libfranka-feedstock (fyi @nmarticorena).

I've removed the pin, Pixi should now pick whatever version of poco is compatible.

I bumped libfranka to 0.21.2, as the changes w.r.t. to 0.20.4 are minimal. I also added a fix for #397 .

[nmarticorena]

I bumped libfranka to 0.21.2, as the changes w.r.t. to 0.20.4 are minimal. I also added a fix for #397 .

FWIW, I recently installed libfranka on a brand new FR3 manually using libfranka 0.21.2 from conda-forge and ros-humble, so I can confirm it works normally

[esteve]

@traversaro can you trigger another CI run? I've fixed the patches for Windows and macOS, but I have no way of testing them locally as I don't have either. Thanks.

[traversaro]

I forced a full rebuild, it is possible that this exposed some new failures that were hidden by the cached results.

[traversaro]

I am a bit confused by whole the:

autoware_trajectory:
  remove_host: ["ros-humble-tl-expected"]
  remove_run: ["ros-humble-tl-expected"]
  add_host: ["cpp-expected"]
  add_run: ["cpp-expected"]

As we are still building a ros-humble-tl-expected, that could conflict with conda-forge's cpp-expected. Perhaps it can make sense to just patch https://github.com/PickNikRobotics/cpp_polyfills/blob/main/tl_expected/CMakeLists.txt to avoid install its header file (so basically commenting out https://github.com/PickNikRobotics/cpp_polyfills/blob/main/tl_expected/CMakeLists.txt#L16-L19), and add a run dependeny for it on cpp-expected? In this way we do not need to patch all packages that uses ros-humble-tl-expected, and using ros-humble-tl-expected will do the "right" thing, instead of clobbering.

[mhubii]

lbr_fri_ros2_stack versions look good now (version mismatch #398).

[esteve]

As we are still building a ros-humble-tl-expected, that could conflict with conda-forge's cpp-expected. Perhaps it can make sense to just patch https://github.com/PickNikRobotics/cpp_polyfills/blob/main/tl_expected/CMakeLists.txt to avoid install its header file (so basically commenting out https://github.com/PickNikRobotics/cpp_polyfills/blob/main/tl_expected/CMakeLists.txt#L16-L19), and add a run dependeny for it on cpp-expected? In this way we do not need to patch all packages that uses ros-humble-tl-expected, and using ros-humble-tl-expected will do the "right" thing, instead of clobbering.

I don't think this is the right approach:

• tl_expected already installs headers in a location separate from cpp-expected/libexpected-dev, so there's no conflict
• Patching tl-expected to not install its headers is not necessary
• I don't see the point of making cpp-expected depend tl-expected, messing with the dependency chain of a package feels wrong
• tl-expected is declared as deprecated and will be removed soon

I added those add/remove lines because I assumed that each package was built in isolation and I wanted to make sure that tl-expected was not installed when building the the patched packages.

[traversaro]

tl_expected already installs headers in a location separate from cpp-expected/libexpected-dev, so there's no conflict

Ah, I missed this. Then the current approach is fine for me.

[esteve]

The ubuntu-24.04-arm CI job is failing with this:

│ [INFO] [launch]: All log files can be found below /home/runner/.ros/log/2026-05-12-09-36-53-809415-runnervm6gd1v-53672
 │ [INFO] [launch]: Default logging verbosity is set to INFO
 │ [INFO] [robot_state_publisher-1]: process started with pid [53674]
 │ [robot_state_publisher-1] [INFO] [1778578613.889796056] [robot_state_publisher]: got segment base_link
 │ test_node_output (robot_state_publisher_smoke_test_launch.TestRobotStatePublisher.test_node_output) ... ok
 │ [robot_state_publisher-1] [INFO] [1778578613.890425406] [robot_state_publisher]: got segment child_link
 │ ----------------------------------------------------------------------
 │ Ran 1 test in 0.070s
 │ OK
 │ [INFO] [robot_state_publisher-1]: sending signal 'SIGINT' to process[robot_state_publisher-1]
 │ [robot_state_publisher-1] [INFO] [1778578613.893294590] [rclcpp]: signal_handler(SIGINT/SIGTERM)
 │ [robot_state_publisher-1] terminate called after throwing an instance of 'rclcpp::exceptions::RCLError'
 │ [robot_state_publisher-1]   what():  could not create subscription: rcl node's context is invalid, at /home/runner/work/ros-humble/ros-humble/output/bld/rattler-build_ros-humble-rcl_1778571403/work/ros-humble-rcl/src/work/src/rcl/node.c:428
Error: OR] [robot_state_publisher-1]: process has died [pid 53674, exit code -6, cmd '$PREFIX/lib/robot_state_publisher/robot_state_publisher --ros-args -r __node:=robot_state_publisher --params-file /tmp/launch_params_hq844pmy'].
 │ test_exit_codes (robot_state_publisher_smoke_test_launch.TestRobotStatePublisherPostShutdown.test_exit_codes) ... FAIL
 │ ======================================================================
 │ FAIL: test_exit_codes (robot_state_publisher_smoke_test_launch.TestRobotStatePublisherPostShutdown.test_exit_codes)
 │ ----------------------------------------------------------------------
 │ Traceback (most recent call last):
 │   File "$SRC_DIR/robot_state_publisher_smoke_test_launch.py", line 56, in test_exit_codes
 │     launch_testing.asserts.assertExitCodes(proc_info)
 │   File "$PREFIX/lib/python3.12/site-packages/launch_testing/asserts/assert_exit_codes.py", line 62, in assertExitCodes
 │     assert info.returncode in allowable_exit_codes, 'Proc {} exited with code {}'.format(
 │            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 │ AssertionError: Proc robot_state_publisher-1 exited with code -6
 │ ----------------------------------------------------------------------
 │ Ran 1 test in 0.001s
 │ FAILED (failures=1)

Seems to be an internal rclcpp/rcl issue not related to packaging, I don't know what is expected to be done in these cases.

[traversaro]

Seems to be an internal rclcpp/rcl issue not related to packaging, I don't know what is expected to be done in these cases.

I think this was just a flaky failure, restarting seems that the test pass fine.

[esteve]

Looks like https://github.com/RoboStack/ros-humble/actions/runs/25725011648/job/75655014701?pr=403 (osx-arm64) built the packages fine, but there was a DNS resolution error for github.com that made the job fail. At least the Ubuntu jobs passed.