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)
  • Workaround in fix: pin to a known version of rattler-build that works #404
• 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.

[esteve]

@traversaro I updated the smoke test to query robot_state_publisher to make sure it has been properly initialized, this should help with the timing issues in the CI. I also increased the timeout to give it enough time on macOS and Windows.

[esteve]

The cache is still invalidated, would we need to disable IGNORE_CACHE_AND_DO_FULL_REBUILD before merging?

[Tobias-Fischer]

The cache is still invalidated, would we need to disable IGNORE_CACHE_AND_DO_FULL_REBUILD before merging?

Yes please

[traversaro]

@traversaro I updated the smoke test to query robot_state_publisher to make sure it has been properly initialized, this should help with the timing issues in the CI. I also increased the timeout to give it enough time on macOS and Windows.

Thanks! That test is quite important as one of the few that is actually testing the rmw and everything else actually works in practice, so increasing its robustness is really helpful.

[esteve]

Some of the jobs get canceled, I don't know if it's because they take too long (linux-64 takes about 6 hours) or because they are canceled by another CI run.

[esteve]

It seems to me that CI jobs are getting canceled because they hit the 6 hour limit (https://docs.github.com/en/actions/reference/limits), however self hosted runners do not have that restriction, is there any external infrastructure that could be used? Build times will get longer and longer the more packages that are added.

[Tobias-Fischer]

There are a few providers that offer free CI for open source projects, e.g. https://buildkite.com/pricing/

Would be super happy to see this explored, but personally I don't have the bandwidth currently to contact them and then switch over the CI here.

At the moment, we typically get around it by running 2x6 hour jobs or so; it works fine on Linux and MacOS; Windows is a pain as it doesn't save the cache if it times out; there we need to manually cancel the workflow within the 6 hour window.

[Tobias-Fischer]

For this PR, I'd be happy to merge and sort out any potential remaining issues on the main branch.

[traversaro]

For this PR, I'd be happy to merge and sort out any potential remaining issues on the main branch.

Ok for me!

[Tobias-Fischer]

Thank you @esteve!

[Tobias-Fischer]

@esteve - the robot-state-publisher is stuck on the build branches (see Actions) on MacOS. Any clue what's going on?

Windows and Linux builds have completed :)

[esteve]

@esteve - the robot-state-publisher is stuck on the build branches (see Actions) on MacOS. Any clue what's going on?

Windows and Linux builds have completed :)

Not sure what's happening there, but I'll have a look. It's weird that Windows passed but macOS just hangs.

[esteve]

@Tobias-Fischer can you paste the log somewhere? Thanks

[traversaro]

@Tobias-Fischer can you paste the log somewhere? Thanks

See:

• https://github.com/RoboStack/ros-humble/actions/runs/25982034215
• https://github.com/RoboStack/ros-humble/actions/runs/25982016728

The hanging log is:

 │ Installing test environment
 │ ✔ Successfully updated the test environment
 │ Testing commands:
 │ [INFO] [launch]: All log files can be found below /Users/runner/.ros/log/2026-05-17-23-53-29-503506-iad01-dz253-e16844ca-2d47-4c6c-99c7-3171c4bfd951-C2A81DA68D44.local-29619
 │ [INFO] [launch]: Default logging verbosity is set to INFO
 │ [INFO] [robot_state_publisher-1]: process started with pid [29628]
 │ [robot_state_publisher-1] [INFO] [1779062009.858633571] [robot_state_publisher]: got segment base_link
 │ [robot_state_publisher-1] [INFO] [1779062009.859695631] [robot_state_publisher]: got segment child_link
 │ test_node_output (robot_state_publisher_smoke_test_launch.TestRobotStatePublisher.test_node_output) ... 1779064181.947569 [0]        tev: ddsi_udp_conn_write to udp/239.255.0.1:7401 failed with retcode -1
 │ 1779064181.947618 [0]        tev: ddsi_udp_conn_write to udp/192.168.64.2:61930 failed with retcode -1
 │ 1779064183.000223 [0]        tev: ddsi_udp_conn_write to udp/239.255.0.1:7401 failed with retcode -1
 │ 1779064183.000270 [0]        tev: ddsi_udp_conn_write to udp/192.168.64.2:61930 failed with retcode -1
 │ 1779064184.014349 [0]        tev: ddsi_udp_conn_write to udp/239.255.0.1:7401 failed with retcode -1
 │ 1779064184.014395 [0]        tev: ddsi_udp_conn_write to udp/192.168.64.2:61930 failed with retcode -1

[esteve]

@traversaro @Tobias-Fischer PR #407 should fix this issue.