Add missing rosidl_typesupport_c dep#121
Open
nbbrooks wants to merge 12 commits into
Open
Conversation
nbbrooks
force-pushed
the
pr-add-rosidl_typesupport_c-dep
branch
2 times, most recently
from
28bda37 to
a088063
Compare
…oes not use industrial_ci - rosidl-typesupport-fastrtps-* - python3-ament-package Source builds (e.g. serial) fail with "ModuleNotFoundError: No module named 'ament_package'" because ros-tooling/setup-ros installs ROS with --no-install-recommends, which can drop python3-ament-package. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
nbbrooks
force-pushed
the
pr-add-rosidl_typesupport_c-dep
branch
from
a088063 to
719f908
Compare
libhardware_interface.so has a runtime NEEDED entry for libjoint_saturation_limiter.so, but ros-rolling-hardware-interface's Debian package does not declare ros-rolling-joint-limits as a Depends. This is a packaging gap upstream — rosdep does not pull it in, so tests fail with "libjoint_saturation_limiter.so: cannot open shared object file" at runtime even though the build succeeds. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…INK_PATH Tests 2-5 in robotiq_driver fail loading libhardware_interface.so even though the build succeeds, because they only link to the workspace robotiq_driver target — not directly to hardware_interface — so their RPATH does not include /opt/ros/$distro/lib. Test 1 works because it explicitly links hardware_interface::hardware_interface. Setting CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE causes CMake to embed the directories of all linked libs (including transitive ones from imported targets) in the install RPATH. Combined with --symlink-install (where install location is the build location), this fixes the test runtime resolution. Also add a debug step to the workflow that prints LD_LIBRARY_PATH, relevant /opt/ros/$distro/lib contents, and the RPATH/RUNPATH/NEEDED of each test binary so we can confirm the diagnosis on the next run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Switch the coverage build to run inside the upstream-recommended setup-ros-docker container image (ros-base variant) instead of the bare ubuntu-24.04 + setup-ros pattern. Most ros-base packages (rclcpp, std_srvs, ament_cmake, rosidl_typesupport_fastrtps_c/cpp, ament_package) come preinstalled in the image, so rosdep failures against the ros/rosdistro master branch no longer block the build. The remaining ros2_control packages that ros-base doesn't include are installed explicitly via apt to bypass rosdep entirely. This is an experiment to evaluate option C from the discussion. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The ghcr.io path I used does not exist; the actual tag scheme has a 'setup-ros-docker-' prefix in the package path and uses ':master', not ':latest'. Use the DockerHub tag instead (cleaner and verified). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The setup-ros-docker rolling-ros-base image was last pushed 2025-08-16 (9 months stale) — unacceptable for a Rolling-tagged image. The Docker Official ros:rolling-ros-base image is rebuilt regularly (last push ~2 weeks ago) and is what most ROS projects use. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The container experiment with ros:rolling-ros-base hit a target version mismatch (rosidl_buffer_backend) because the image is ~2 weeks old and incompatible with current Rolling. On Rolling specifically, mixing a prebuilt image with fresh apt-installs causes more problems than it solves. Go back to setup-ros on bare ubuntu-24.04 (everything installed fresh from current Rolling = internally consistent) and expand the apt-install list to also bypass rosdep for ros2_control packages (controller_interface, hardware_interface, parallel_gripper_controller), since rosdep against ros/rosdistro master cannot currently resolve these keys for noble. Combined with CMAKE_INSTALL_RPATH_USE_LINK_PATH from earlier in this branch, the test binaries should embed /opt/ros/rolling/lib in their RPATH and not rely on LD_LIBRARY_PATH propagation through colcon test. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Rolling officially moved to target Ubuntu 26.04 (resolute) on the 2026-04-28 rosdistro snapshot, so rosdep against ros/rosdistro master no longer resolves rolling keys on noble. Pin to the last snapshot that supports noble — mirroring the same workaround industrial_ci uses for the binary builds in this repo (ros-industrial/industrial_ci#933). With rosdep working again, drop the apt-install workaround for keys that rosdep can now resolve (controller_interface, hardware_interface, parallel_gripper_controller, ament_package — the last is transitively pulled in by ament_cmake-core anyway). Keep the explicit installs only for the genuine upstream packaging gaps that exist regardless of the rosdistro snapshot: - joint_limits is an undeclared runtime dep of hardware_interface - the rosidl_typesupport_fastrtps_{c,cpp} implementations are not pulled in by the rosidl_typesupport_c dispatch package Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A plain YAML scalar folds newlines to single spaces, so the previous
multi-line "run: sudo apt-get install -y \\\n pkg \\\n pkg" became
the single string "sudo apt-get install -y \\ pkg \\ pkg". Bash then
parsed "\\ " as an escaped space and prepended a space to each
package name (e.g., " ros-rolling-joint-limits"), which apt could
not resolve.
Switch to a literal block scalar ("run: |") so the newlines are
preserved and bash sees real line continuations.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The original PR's CMake/package.xml changes were based on a
misdiagnosis. The original error "No 'rosidl_typesupport_c' found"
came from rosidl_typesupport_c/cmake/get_used_typesupports.cmake
not finding any registered typesupport *implementation* — not from
CMake failing to find_package(rosidl_typesupport_c) itself. The
dispatch package was always being found; the implementations
(rosidl_typesupport_fastrtps_c/cpp) just were not installed.
The actual root causes (rolling moving off noble, upstream debian
packaging gaps) are addressed by the workflow changes
(ROSDISTRO_INDEX_VERSION pin and explicit apt-installs of
rosidl-typesupport-fastrtps-{c,cpp} and joint_limits). These
CMake/package.xml changes do not contribute to the fix:
controller_interface and hardware_interface already pull
rosidl_typesupport_c in transitively via their CMake configs.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Setting ROSDISTRO_INDEX_VERSION alone was not enough: rosdep update reads its sources from /etc/ros/rosdep/sources.list.d/20-default.list, which setup-ros writes pointing at ros/rosdistro master. The action-ros-ci rosdep update then re-fetched master and continued to return "No definition of [<key>] for OS version [noble]" for keys that rolling no longer declares for noble. Match industrial_ci's full approach (industrial_ci#933 and .github/workflows we already use): sed-rewrite the sources list file to point at the rolling/2026-04-28 snapshot before any rosdep update runs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The rosdistro Python library reads ROSDISTRO_INDEX_URL, not ROSDISTRO_INDEX_VERSION. industrial_ci uses _VERSION as an internal shorthand and translates it to _URL before invoking rosdep (industrial_ci/src/workspace.sh). Without _URL, the rosdep update on the previous run still queried master for the rosdistro index even though the sed-rewrite had updated the rosdep yaml URLs: Query rosdistro index https://raw.githubusercontent.com/ros/rosdistro/master/index-v4.yaml The keys controller_interface/hardware_interface that rolling no longer publishes for noble on master were therefore still missing from the in-memory index, and rosdep silently skipped installing them despite "All required rosdeps installed successfully". Switch the env var to ROSDISTRO_INDEX_URL with the snapshot URL expanded, so the rosdistro library queries the snapshot's index too. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix CI failure