Full rebuild September 2026 : bump ros2-distro-mutex to 0.21.0 and build number to 27 and switch to new pinning mechanism (take 2) - #41
Open
Tobias-Fischer wants to merge 204 commits into
Open
Conversation
Tobias-Fischer
force-pushed
the
codex/cross-distro-sync
branch
from
August 28, 2026 03:51
1e89074 to
d7cfa0b
Compare
- conda_build_config.yaml: add cmake 3.* workaround pin (avoids CMake 4 regression hitting ament packages on macOS/conda) - vinca.yaml: use conda-forge iceoryx 2.0.6 packages instead of ROS release copies (matches lyrical) - vinca.yaml: skip libpointmatcher (unreleased for rolling) so rtabmap can be added without breaking recipe generation - vinca.yaml: add rtabmap seed package (released for rolling) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rtifacts check_patches_clean_apply.py builds throwaway "<pkg>-check-patches[-<platform>]" packages into the same output/<platform> directory to verify patches apply. Those never have a matching recipes/ entry, so build_gap_report.py was reporting every one of them as a false "built but no recipe" gap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…inca_pinning.yaml, check_dependency_compat.py) Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ROS2-Rolling API drift
Adds local ros2-libg2o (Qt6) and ros2-cv-bridge (OpenCV5) recipes to replace
Rolling's remote-only builds, which were still Qt5/OpenCV4-linked and
genuinely incompatible with the rest of this channel's pins (not just the
resolvo mutex-misattribution bug also worked around here for
ros2-web-video-server). These two unblock rtabmap and web-video-server.
Also fixes, across a mix of category-level (osx exclusions, endian shims,
Boost.ASIO API migration) and Rolling-specific issues:
- mavlink/libmavconn/mavros/mavros-extras (endian shim + GeographicLib link)
- udp-driver, robotiq-controllers, microstrain-inertial-driver (partial):
ament_target_dependencies() was removed from ROS2 Rolling's ament_cmake_target_dependencies
entirely; replaced with a local link_ament_dependencies() macro using each
dependency's exported <pkg>_TARGETS variable
- robotiq-controllers: hardware_interface::LoanedCommandInterface::get_value()
replaced by get_optional<T>() in ros2_control's realtime-safety rework
- turtle-tf2-cpp, imu-transformer, web-video-server: tf2_ros/image_transport
APIs migrated from raw Node* / multi-arg interface calls to a single
NodeInterfaces bundle constructed from a Node reference
- vision-msgs-rviz-plugins: Qt5->Qt6 (find_package, qt6_wrap_cpp, explicit
Qt6::Core/Widgets + rviz_default_plugins linking) and the rviz_common
Display::update() float->std::chrono::nanoseconds signature change
- nlohmann-json-schema-validator-vendor: CMAKE_POLICY_VERSION_MINIMUM=3.5
for its ExternalProject_Add'd vendored source (CMake<3.5 removed)
- ublox-dgnss-node: --allow-multiple-definition linker flag unsupported on
macOS ld (progress fix; a real duplicate-symbol ODR issue remains)
- rmf-building-map-tools: numpy>=2.0 removed 2D-vector np.cross() support,
used by is_in_lift() -- replaced with the direct scalar cross-product
formula. Unblocks the whole downstream rmf-demos-maps chain.
- rmf-traffic: missing #include <cassert> across 11 vendored FCL headers +
1 own source file; missing Eigen3::Eigen link (was relying on a
build-path-relative ${EIGEN3_INCLUDE_DIRS} variable baked into the
installed target, breaking downstream consumers)
- rmf-traffic-ros2: custom FindLibUUID.cmake unconditionally required a
standalone libuuid (Linux-only; macOS provides uuid/uuid.h natively, no
separate library) -- also missing Eigen3::Eigen link
- rmf-websocket: Boost 1.90 no longer ships a boost_system CMake config
(header-only now); dropped the component + Boost::system linkage
- mujoco_3d_lidar/mujoco_ros2_control_plugins excluded on osx (no prebuilt
MuJoCo binary for macOS, matching the same exclusion already used for
mujoco_ros2_control/_demos)
- ros2-distro-mutex rebuilt at 0.20.0/build 26 to match vinca.yaml's already
-bumped run_constraints (vtk 9.7.0), which had never actually been
republished
ros-rolling went from ~150 missing packages (of 311 recipes) to 12 still
blocked, each a genuinely deep out-of-scope issue for tonight: avt-vimba-camera
and rclc-examples need real rclcpp/image_transport/rcl API ports;
microstrain-inertial-driver needs further NodeInterfaces + tf2/LinearMath
porting; ublox-dgnss(-node) has a real duplicate-symbol ODR bug beyond the
linker-flag guard; the rmf-websocket chain (rmf-websocket, rmf-task-ros2,
rmf-fleet-adapter(-python), rmf-reservation-node, rmf-visualization-floorplans/
-schedule) is blocked on websocketpp itself using removed Boost.ASIO APIs
(io_service) -- a third-party dependency incompatibility, not this repo's
source.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…les/rmf_fleet_adapter/rmf_visualization_floorplans API drift), exclude avt_vimba_camera on osx - ublox-dgnss-node: the --allow-multiple-definition linker flag guard alone wasn't sufficient -- the actual duplicate symbols (ubxKeyCfgItemMap, storage_size_bytes, operator<(ubx_key_id_t), get_polled_frame) are plain non-inline definitions in headers included by multiple translation units, a genuine ODR violation Linux's ld tolerates and Apple's correctly rejects. Mark them `inline` instead of relying on the linker flag. - rclc_examples: rcl_timer_callback_t gained a third (uintptr_t) parameter on Rolling; updated all 9 example timer callbacks across 6 files. - rmf_fleet_adapter: malloc_trim() is glibc-only, guarded with #if defined(__linux__); missing <algorithm>/<unordered_set> includes (9 files); two int64_t/size_t-vs-long/long-long template deduction mismatches in std::max() calls, where the distinct-on-macOS types (uint64_t is `long long` there, not `long`/`size_t` as on Linux) fail to unify; three ROS-message std::vector<uint64_t> fields passed where FleetUpdateHandle expects std::vector<std::size_t> (distinct types on macOS, not just width) -- construct an explicit converting copy instead. - rmf_visualization_floorplans: cv::Mat's std::vector<uchar> constructor doesn't accept rosidl's message-array Buffer<uchar,allocator<uchar>> wrapper type directly -- copy through an explicit std::vector first. - rmf_visualization_schedule: pinned openssl >=3.6.4 (overriding, not additive to, this repo's openssl 3.5.* variant) -- resolvo otherwise falls back to older ros2-cyclonedds/ros2-fastdds builds whose newest builds need it, hitting the already-documented mutex-misattribution bug. - avt_vimba_camera: Allied Vision only ships prebuilt Vimba SDK binaries (libVimbaC/libVimbaCPP) for Linux (x86_64/arm) -- confirmed no source fix is possible (rclcpp/image_transport API-migration patches got it to actually reach the link step, where it fails on ELF .so files built for the wrong OS entirely). Excluded on osx via vinca.yaml, matching the existing mujoco_vendor precedent. ros-rolling now builds all 311 recipes (previously ~150 missing) on osx-arm64. Two dependencies needed real fixes that don't belong in this repo: rmf_websocket (patched here for its own source's rclcpp::Node NodeInterfaces migration and Boost 1.90 boost_system removal) depends on conda-forge's websocketpp package, whose bundled Asio transport code uses boost::asio APIs (io_service et al.) removed in Boost >=1.87 -- reported upstream as a conda-forge/websocketpp-feedstock PR rather than patched locally in this repo. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ervice) websocketpp 0.8.2 calls boost::asio::io_service, which Boost 1.90 removed. Rather than patch websocketpp itself, define ASIO_STANDALONE and pin the standalone asio host/run dep to ==1.29.0 (the newest conda-forge build that still ships io_service.hpp), matching the fix RoboStack/ros-lyrical#41 already validated. Also opened conda-forge/websocketpp-feedstock#8 upstream for the same Boost.Asio compatibility gap, for consumers not using ASIO_STANDALONE. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…parity rolling's package count (155 unique / ~304 recipes) lags far behind humble (1105) and jazzy (1004) despite near-identical explicit seed counts. Root cause: robostack.yaml (rosdep-key -> conda-forge package mapping) is missing 29 entries that humble already has, so vinca's dependency expansion silently drops those transitive deps instead of erroring. Ported the missing entries from humble/robostack.yaml (adapting qml-module-qtquick-extras to rolling's Qt6 baseline). Also added 12 genuinely-missing top-level seeds found by diffing packages_select_by_deps against humble/jazzy: ntrip_client, rqt_image_overlay, and the full yasmin_* family (yasmin, yasmin_cli, yasmin_demos, yasmin_editor, yasmin_factory, yasmin_msgs, yasmin_pcl, yasmin_plugins_manager, yasmin_ros, yasmin_viewer), all verified present in rolling's rosdistro_snapshot.yaml. Fixed an unrelated pre-existing duplicate vision_msgs_rviz_plugins line while in the area. Added a comment separator before the linux-and-not-aarch64 webots_ros2/ zed_msgs block: vinca-sort-vinca-lists pools then-items across adjacent if-blocks that aren't separated by a comment, which would otherwise bleed webots_ros2 into the wrong platform scope on the next sort. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rqt_image_overlay hard-depends on ros_image_to_qimage, which has a repo entry in rolling's rosdistro index but no released version at all -- a genuine upstream gap, not a robostack.yaml mapping issue. Selecting it crashes vinca's dependency walk with "Package 'ros_image_to_qimage' ... has no version set". Drop it from the seed list until upstream tags a release. Also move two previously-hand-edited recipe.yaml overrides into patch/dependencies.yaml so they survive `vinca -m` regeneration instead of needing to be reapplied by hand every time: - rmf_fleet_adapter_python: add pybind11_json to host (used for nlohmann::json<->pybind11 conversions, missing from package.xml) - rmf_visualization_schedule: bump openssl to >=3.6.4 in host/run Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ng channel Bare "-c robostack-rolling" resolves to https://conda.anaconda.org/robostack-rolling/ by default, which has zero packages -- rolling publishes to https://repo.prefix.dev/robostack-rolling instead (already used correctly by the `build` and `build-one` tasks, and by `upload`'s own target). Every fresh package build against this task failed with "No candidates were found for ros2-ament-cmake *" (or whatever core dependency the solver happened to name first) since the real channel was never actually being searched. Match the other two build tasks' channel argument. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…n osx
Five independent macOS-specific build failures fixed, verified with
individual rebuilds against the current recipe set:
- urg_node: urg_c_wrapper.cpp calls read()/write() without <unistd.h>.
- microstrain_inertial_driver: tf2/LinearMath/*.h headers no longer exist
(only .hpp now); two make_shared<tf2_ros::{Static,}TransformBroadcaster>
calls passed a Node* where the NodeInterfaces bundle needs a reference.
- motion_capture_tracking: same NodeInterfaces bundle issue, one call site
(tf2_ros::TransformBroadcaster tfbroadcaster(node) -> (*node)).
- realsense2_camera: upstream CMakeLists.txt guards Linux-only GNU-ld
hardening flags (-z noexecstack/relro/now) with if(UNIX OR APPLE) --
APPLE also sets UNIX, so these ELF-only flags leaked onto the Apple
linker, which rejects -z outright ("ld: unknown option: -z").
- rmw_stats_shim: same category of bug, gating -Wl,--no-undefined (a GNU
ld long option) on "Clang" without excluding Apple's clang+ld64 pairing.
Also move mujoco_ros2_control(_demos) into the existing osx-exclusion
block (packages_select_by_deps, not packages_skip_by_deps, since these
are explicitly-selected top-level seeds and skip_by_deps only prunes
transitive expansion): mujoco_ros2_control hard-depends on
mujoco_ros2_control_plugins, which is already macOS-excluded because
mujoco_vendor has no prebuilt MuJoCo binary there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
pcl_conversions's remote build at the current build_number (25) was published against vtk-base 9.6.2.*, which conda-forge no longer carries -- this repo's mutex run_constraints now pin vtk 9.7.0.*. Bump its build_number override to 26 so skip_existing stops matching that stale remote build, forcing a fresh local build against the current pins. Separately, discovered that ~/.condarc's channel_priority: strict (or rattler-build's own default) causes spurious "no candidates" failures whenever the local output/ channel happens to carry ANY build of a package name (here: ros2-distro-mutex, present locally at build 26 from earlier work) -- strict priority then refuses ALL other-channel builds of that name, even ones a completely unrelated dependency needs at an older, perfectly valid version. This bit pcl_conversions's own test dependencies (which pull in most of the ROS2 core stack) and would bite any future build in the same situation, including the sanctioned `build`/`build-one`/`build_continue_on_failure` tasks, since the test phase always implicitly adds output/ as a channel to install the just-built package. Add --channel-priority disabled to all three. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ces API package.xml's <depend>cartographer</depend> resolves to the REAL released ros2-cartographer ROS package, but this repo's own add_host ALSO pulls in the conda-forge cartographer C++ library directly for the same name -- vinca doesn't dedupe these, so both ended up in host/run with conflicting lua pins (conda-forge cartographer wants lua 5.4.8, ros2-cartographer wants lua 5.5.0), making the recipe unsolvable. Drop the ROS-released one via remove_host/remove_run; the conda-forge add_host is what's actually meant to satisfy this dependency (same generate_dummy_package_with_run_deps duplicate-registration pattern as the pinocchio/hpp_fcl case documented elsewhere in this repo's history). Once that resolved, hit the by-now-familiar Rolling NodeInterfaces bundle API drift in cartographer_ros's own source: three tf2_ros construction call sites (node.cpp's TransformBroadcaster, node_main.cpp and offline_node.cpp's tf2_ros::Buffer, offline_node.cpp's StaticTransformBroadcaster) passed a raw Node*/shared_ptr<Node> where the bundle needs a reference -- add the missing dereferences. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…em_modes_msgs seed rosgraph_monitor, rviz_2d_overlay_plugins, sick_safetyscanners_base, spacenav, system_modes, trac_ik, and zed_msgs were all gated under if: linux (or, for zed_msgs, linux and not aarch64) in this repo's vinca.yaml despite jazzy already building every one of them on osx (its own vinca.yaml selects them under "not win"/"not linux"). Moved them into the not-wasm32-and-not-win block instead of duplicating them, and added a comment separator so vinca-sort-vinca-lists' known adjacent-if-block-merging bug doesn't scramble the boundary on the next sort (see build_feedback.md's vinca-sort-vinca-lists entry, and RoboStack/vinca#152 for the upstream fix). Also added system_modes_msgs as an explicit seed -- system_modes depends on it but it wasn't reachable any other way for this distro. Each of the 7 was individually verified via rebuild before being kept in this platform-loosened state; three needed additional fixes to actually build once genuinely attempted for the first time on macOS: - rosgraph_monitor: same "-Wl,--no-undefined is GNU-ld-only" pattern already fixed for rmw_stats_shim this session. - system_modes: the already-documented Rolling-wide ament_target_dependencies() removal (see build_feedback.md), fixed with the same local link_ament_dependencies() macro pattern. - sick_safetyscanners_base: the largest fix of the three -- Boost.ASIO API removals across 8 files: find_package(Boost COMPONENTS system) dropped (header-only now, matches the rtabmap/web-video-server/ cartographer_ros pattern), boost::asio::io_service -> io_context, io_service::work -> executor_work_guard<io_context::executor_type> (constructed via make_work_guard), boost::asio::deadline_timer -> explicit boost::asio::basic_deadline_timer<boost::posix_time::ptime> (the plain deadline_timer typedef is gated behind a macro this Boost build doesn't define, but the underlying template is still present and just deprecated-not-removed), address_v4::from_string -> make_address_v4, address_v4::to_ulong -> to_uint, plus two missing <boost/date_time/posix_time/posix_time_types.hpp> includes that used to arrive transitively via the now-gated deadline_timer.hpp. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Completeness fix found by a full key-diff sweep (not just the earlier targeted one): konsole, libblosc-dev, libopenexr-dev, libopenvdb-dev, python3-textual, python3-torchvision(-pip), python3-ultralytics-pip. None of these are currently referenced by any package reachable in rolling's selected set (verified against a fresh vinca -m dependency walk), so this has no effect on the current recipe count -- it's purely to keep robostack.yaml in sync in case a future seed addition needs one of them. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
linux-64: ros2-lttngpy fails CMake configure ("package lttng-ctl not
found") -- conda-forge only packages lttng-ust, not the separate
lttng-ctl control library, so this can never be satisfied by any
robostack.yaml mapping. lttngpy's own CMakeLists.txt already has a
DISABLED_DEFAULT option that's ON for WIN32/APPLE/ANDROID/BSD and OFF
(requiring lttng-ctl) everywhere else -- patch it to always be ON,
matching ros-jazzy's own lttngpy patch, which hit and fixed the exact
same issue.
linux-aarch64: ros2-rmf-traffic fails to compile with GCC ("'uint64_t'
does not name a type", cascading into ~15 further errors in the same
translation unit) -- GCC 15's leaner libstdc++ headers no longer
transitively provide <cstdint> the way clang/libc++ does, so this only
surfaced on Linux, never during this session's osx-arm64 testing.
Added the missing #include <cstdint> to all 11 first-party rmf_traffic
files that use fixed-width integer types without including it
directly.
win-64: `pixi run check-patches` fails on two unrelated, pre-existing
(not touched this session) patch-staleness issues from upstream source
drift, not a toolchain migration:
- ouster_ros's .win.patch is now fully redundant -- current upstream
CMakeLists.txt already has the exact MSVC/WIN32 compile-options and
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS handling the patch was adding.
Deleted the now-obsolete patch file entirely.
- plotjuggler's .win.patch's second hunk (inserting ${QT_LINK_LIBRARIES}
into `target_link_libraries(plotjuggler_base ...)`) no longer applies
-- upstream restructured plotjuggler_base's CMake target entirely
(no `${QT_LINK_LIBRARIES}` reference left near it at all). Removed
just that one obsolete hunk; the patch's other hunks (XCB linking,
QT_LINK_LIBRARIES trimming, protobuf API migration) still apply
cleanly and are untouched.
None of these three packages were built/tested locally against
linux-64/linux-aarch64/win-64 targets (no such environment available
here) -- fixes are based on direct source inspection (jazzy's proven
lttngpy patch, GCC's own documented header-pruning changes, and diffing
current upstream source against each patch's expected context).
osx-arm64 regression-tested for lttngpy and rmf_traffic; ouster_ros and
plotjuggler are skip-existing on osx-arm64 (already published at the
current build number) so could not be locally re-verified there.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…in patch PR #41's own CI run surfaced 3 more real issues past the first round of fixes: - osx-arm64/osx-64: "pcl 1.15.1 would require vtk-base >=9.4.2 ... ros2-distro-mutex 0.20.0 would constrain vtk 9.6.2, conflicts" -- the exact channel-priority-strict symptom already fixed in pixi.toml's build/build-one/build_continue_on_failure tasks earlier this session, except testpr.yml's "Build recipes" step calls `pixi run rattler-build build ...` directly with its OWN hardcoded args written in the YAML, never going through those pixi.toml tasks at all. Added --channel-priority disabled to the workflow step itself. - linux-64: past lttngpy, hit the same GCC15/leaner-libstdc++ missing-<cstdint> pattern as rmf_traffic, this time in rmf_task (14 first-party files using uint32_t/uint64_t directly without including it). Same fix, same pattern -- these two rmf_* packages evidently share the same coding style/vintage. - win-64: past the first plotjuggler.win.patch hunk, check-patches hit a SECOND stale hunk in the same file (ParserProtobuf/CMakeLists.txt's Protobuf detection) -- also fully obsolete, upstream rewrote Protobuf detection entirely via `if(TARGET protobuf::libprotobuf)` checks (verified Protobuf_LIBS, the variable this hunk sets, isn't referenced anywhere in the current file at all). Removed. Two more hunks in this same win.patch (error_collectors.cpp/.h) may or may not still apply under rattler-build's own (more lenient than git apply/GNU patch) patcher -- left alone pending real CI confirmation rather than guessing further, per this session's own established lesson that rattler-build's patcher tolerates things git apply/patch reject. rmf_task regression-tested clean on osx-arm64. testpr.yml and the plotjuggler win-patch fix can only be verified by real CI (no local Linux/Windows environment, and osx doesn't exercise the .win.patch variant at all). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ler win patch rmf_visualization_schedule uses websocketpp::config::asio directly and hits the same io_service-removed-by-Boost-1.90 issue already fixed for rmf_websocket: define ASIO_STANDALONE and pin asio ==1.29.0 (the newest build that still ships io_service.hpp). Verified building clean on osx-arm64. Also remove the error_collectors.cpp/.h hunks from ros-rolling-plotjuggler.win.patch: upstream plotjuggler now guards AddError/AddWarning vs RecordError/RecordWarning behind GOOGLE_PROTOBUF_VERSION, so the old hunk no longer matches and was failing win-64's check-patches. Confirmed obsolete via direct inspection of the pinned release tag's source. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…os::Buffer vinca.yaml's mutex_package.build_number was bumped to 26 (vtk 9.7.0.* instead of 9.6.2.*) in an earlier commit, but should_skip_mutex_package only compares against pkg_additional_info.yaml's per-package override (falling back to the top-level build_number: 25 default). Without an override entry here, it still matched the stale remote ros2-distro-mutex 0.20.0 rolling_25 build and skipped generating a fresh recipe entirely -- so every package needing pcl (which carries a soft vtk run_constraint via the mutex) resolved against the old vtk 9.6.2 constraint and failed to solve against the now-vtk-9.7.0-only pcl builds on conda-forge. Adding the distro_mutex override forces vinca to generate and build a fresh local rolling_26 mutex package instead. Verified end-to-end on osx-arm64: built the fresh mutex, then rebuilt ros2-pcl-conversions against it successfully. Also add a missing #include <tf2_ros/buffer.hpp> (and .h fallback) to septentrio_gnss_driver: geometry2's transform_listener.hpp only pulls in tf2/buffer_core.hpp, not tf2_ros/buffer.hpp, so tf2_ros::Buffer was never declared. Confirmed against ros2/geometry2's rolling branch source and verified the patch applies cleanly via rattler-build's own patcher. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Upstream's CMakeLists.txt selects an EXACT Python version per $ENV{ROS_DISTRO},
matching whatever Python Ubuntu ships for that distro's release (3.12 for
rolling). conda-forge's Python floats independently and is currently pinned
to 3.14 here, so the EXACT match fails against conda's Python and CMake
falls back to searching the system Python instead, finding Ubuntu's
/usr/include/python3.12 headers (incomplete without python3-dev installed,
missing the Debian multiarch pyconfig.h) rather than $PREFIX's actual
Python 3.14. Replace the whole distro-keyed EXACT-version chain with a
plain `find_package(Python 3 REQUIRED COMPONENTS Development)`, so it just
resolves to whatever Python is active in the build environment. Verified
via check_patches_clean_apply.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…20 concepts Second, unrelated failure in the same package after the tf2_ros::Buffer fix: the top-level CMakeLists.txt unconditionally does add_compile_options(-std=c++17), which lands after ament's own default -std=gnu++20 on the compile command line -- the last -std= flag wins, so every translation unit compiles as C++17. That breaks class_loader's interface_traits.hpp, which now uses C++20 concepts (requires/concept) and std::ranges, on rolling's current rclcpp_components. Drop the override and let ament's own C++ standard apply. Verified via check_patches_clean_apply.py. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sip: same fragility as humble/jazzy -- switch the exact "6.15.*" pin to
"<6.16" (see those repos' matching commits for the full story).
image_proc and depth_image_proc hit the same fresh OpenCV5 break as
image_geometry/apriltag/rqt_image_view earlier in this pass: dropped
aruco free functions (track_marker.{hpp,cpp}), old C-API constants
(CV_RETR_EXTERNAL, CV_CHAIN_APPROX_NONE, CV_THRESH_TOZERO_INV), and
cv::boundingRect moving under the new geometry module. Ported jazzy's
already-verified fix for image_proc as-is (applies cleanly against
rolling's actual release tag), and merged the same CV_THRESH_TOZERO_INV
rename into rolling's existing depth_image_proc patch (which was fixing
an unrelated Eigen3 CMake issue -- kept both).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fresh OpenCV5 fallout, two packages further along in the build than the previous pass reached: image_rotate's getRotationMatrix2D moved to the geometry module, compressed_image_transport still used the dropped CV_BGR2RGB-style C-API color codes. Ported jazzy's already-verified fixes for both as-is -- confirmed they apply cleanly against rolling's actual release tags. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same header-path break as image_geometry earlier in this pass: opencv2/calib3d/calib3d.hpp was removed in OpenCV 5 in favor of the flat opencv2/calib3d.hpp. Ported jazzy's fix; verified it applies cleanly against rolling's actual release tag, and confirmed via source inspection that this is the only calib3d reference in the package (no further OpenCV5 API changes needed here beyond the include path). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same old-C-API pattern as compressed_image_transport/rqt_image_view: CV_YCrCb2BGR was dropped in OpenCV 5. Ported jazzy's fix (single-line rename to cv::COLOR_YCrCb2BGR); verified it applies cleanly against rolling's actual release tag. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
traversaro
reviewed
Sep 10, 2026
| # websocketpp 0.8.2 feedstock renamed its own get_io_service() to | ||
| # get_io_context() somewhere between build 0 and build 8 of that exact | ||
| # version (verified by diffing the two builds' headers directly) -- it was | ||
| # never an asio-version issue, so no asio pin here actually addresses it. |
Member
There was a problem hiding this comment.
I am confused, based on this comment this needs to be removed?
traversaro
reviewed
Sep 10, 2026
Comment on lines
+330
to
+331
| add_host: ["openssl >=3.6.4", "asio <1.30"] | ||
| add_run: ["openssl >=3.6.4", "asio <1.30"] |
Member
There was a problem hiding this comment.
Can we drop the asio <1.30 here, given conda-forge/websocketpp-feedstock#8 ?
traversaro
reviewed
Sep 10, 2026
traversaro
reviewed
Sep 10, 2026
| +# BEFORE: a conda-forge spdlog package (pulled in transitively by some | ||
| +# other linked/found dependency) can end up ahead of our own explicit | ||
| +# include dirs, so <spdlog/spdlog.h> resolves to that *external* system | ||
| +# copy (built assuming external fmt) instead of our vendored one, while |
Member
There was a problem hiding this comment.
This is fihy, can't we unvendor spdlog here instead of forcing the vendored version?
traversaro
reviewed
Sep 10, 2026
Comment on lines
+41
to
+45
| # mujoco_vendor has no prebuilt MuJoCo binary for macOS, so mujoco_3d_lidar (which | ||
| # calls real MuJoCo API functions, unlike mujoco_ros2_control) can't build there. | ||
| - if: osx | ||
| then: | ||
| - mujoco_3d_lidar |
Member
There was a problem hiding this comment.
This is fishy, we should unvendor mujoco, why it is a problem if there is no mujoco binary on macOS?
traversaro
reviewed
Sep 10, 2026
traversaro
reviewed
Sep 10, 2026
traversaro
reviewed
Sep 10, 2026
traversaro
reviewed
Sep 10, 2026
traversaro
reviewed
Sep 10, 2026
traversaro
reviewed
Sep 10, 2026
Comment on lines
+12
to
+15
| # Build commands provide their channels with `-c`, so omit the inherited | ||
| # conda-forge-pinning channel_sources value from the rendered configuration. | ||
| channel_sources: null | ||
| channel_targets: null |
Member
There was a problem hiding this comment.
That is fishy, there is no support in vinca for channel_source: null, I had it only locally in a vinca copy.
Member
This is really big and full pof part that really sounds like AI hallucinations. Perhaps we could at least separate the full rebuild from adding new packages? In particular I am not understand from where all the changes in vinca.yaml are coming. |
Same upstream bug as humble/jazzy's matching fix (see humble's commit for the full diagnosis): g2o's solver_csparse target only exposes CSPARSE_INCLUDE_DIR via \$<BUILD_INTERFACE:...>, so rtabmap (a downstream consumer building against the installed g2o package) never learns where cs.h lives -- a hard failure under MSVC's stricter include isolation. Pre-emptive port ahead of rolling's own win-64 build reaching rtabmap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same two fixes as humble/jazzy today: 1. vinca's raw.githubusercontent.com package.xml fetches were completely unauthenticated (subject to GitHub's low shared anonymous rate limit), which caused a persistent 404 for the same URL across three consecutive full-matrix runs on humble/jazzy. Wire up GITHUB_TOKEN, which vinca already knows how to send (distro.py's _get_auth_headers) -- rolling's single-shot vinca call (no retry loop at all) is if anything more exposed to this than the other two repos. 2. This PR's build cache persists output/<platform> across every commit, so --skip-existing would reuse the libg2o built before the CSparse INSTALL_INTERFACE fix landed on this branch once rolling's win-64 build reaches rtabmap. Added it to the existing stale-cache-purge step ahead of that. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fix as humble/jazzy: RoboStack/vinca#156 fixes vinca's ambiguous raw.githubusercontent.com URL construction for ros2-gbp release tags, which resolves inconsistently across CDN edges and was the real root cause behind a persistent, non-transient "Failed to fetch package.xml" failure pattern (confirmed on humble/jazzy CI; not yet observed here, but rolling's own Generate recipes step has no retry loop at all so it's if anything more exposed). Pin to the fix commit directly (verified it contains this line's prior HEAD as an ancestor) rather than wait on review/merge. Revert to the plain RoboStack/vinca.git rev once that PR merges. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous commit pinned to a fork commit based on current RoboStack/vinca master, which includes the newer rosdistro-cache-snapshot feature (PR #146). Our already-generated rosdistro_snapshot.yaml predates that machinery and isn't compatible with it, causing a new failure. Re-pin to RoboStack/vinca@1f1dca5 (the last commit before that feature landed) with the raw.githubusercontent.com tag-URL ambiguity fix (RoboStack/vinca#156) cherry-picked on top, so we keep the actual fix without pulling in the incompatible snapshot changes. Per instruction: do not regenerate rosdistro_snapshot.yaml itself, since that would pull in new package versions and a fresh round of patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same wall as jazzy, first time reached now that recipe generation actually succeeds: "Generated workflow linux.yml is 546.7 KiB, exceeding the 500 KiB limit." batch_size defaults to 5; bump to 25, matching the fix already applied on humble. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fix as humble/jazzy: win-64 jobs have repeatedly gone completely silent for 10-20+ minutes at the exact same spot, linking libg2o's core library (many small .obj/.pdb file reads/writes right after a burst of LNK4197 duplicate-export warnings) -- exactly the I/O pattern real-time Defender scanning is known to silently stall on GH Actions Windows runners. A byte-level scan of the whole libg2o source tree found no invalid UTF-8 anywhere, ruling out a repeat of the earlier avt_vimba_camera-class encoding bug for this specific hang. Repeated cancel+retry cycles kept landing on the identical spot rather than clearing anything up. Exclude the checkout and C:\bld build directories from scanning before any heavy I/O begins. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…mera-class bug) Same root cause as the earlier avt_vimba_camera fix: urg_c (Hokuyo laser rangefinder driver, pulled in transitively via urg_node) ships all of its source in Shift-JIS encoding, not UTF-8. Compiling urg_sensor.h triggers -Winvalid-utf8 on its Japanese comments; the compiler echoes the raw invalid bytes into the diagnostic, and rattler-build's output reader hangs instead of erroring -- reproduced live: osx-64 sat silently at the exact same source line for 9.5+ minutes before I cancelled it, matching the "100% deterministic" hang signature from the original bug. Converts all 35 affected files from Shift-JIS to UTF-8 (comment-only, no functional change) rather than suppressing the warning, since the root problem is corrupted vendor data that -- as the original fix's own commit message anticipated -- could (and did) trip the same bug elsewhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Standardize on humble's post-review layout: add permissions block, pin setup-pixi/pixi versions, add the 3-attempt recipe-generation retry loop, short single-line comments, short-form channel args (-c conda-forge -c robostack-rolling instead of full prefix.dev URLs), dedupe the repeated git-maintenance-disable step, and drop the one-off cache-purge entry (superseded by newer cache saves). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The cached .conda artifact was only ~53KB (comparable moveit packages run 800KB-5MB), missing its installed cmake config -- moveit_setup_framework's find_package(moveit_ros_visualization) failed against it. Same recurring pattern: a cancelled run's cache-save step caught it mid-write. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same cleanup as humble/jazzy: dependencies.yaml comments down to one line each, and vinca.yaml multi-line comment blocks condensed to a single line -- vinca-sort-vinca-lists only treats a whole-line comment as a block separator, so a multi-line block gets scrambled across items once the list re-sorts. Preserves the comments that exist specifically to keep adjacent if/then blocks from being pooled together by the sorter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
changed the title
- Fix a real YAML bug: an indentation slip made 8 packages (rqt_mocap4r2_control, rqt_moveit, rqt_robot_dashboard, rqt_robot_steering, rqt_tf_tree, rslidar_sdk, rtcm_msgs, rviz2) fold into one bogus concatenated string value, silently dropping them from the package list entirely. Restored as proper items (the two with real Windows build problems, per humble/jazzy precedent, under "not win"; the rest unconditional). - Remove packages_remove_from_deps entries for iceoryx_binding_c/ hoofs/posh: a maintainer already removed these once (dab44f4, 2026-08-21) because generate_dummy_package_with_run_deps already devendors them properly; the cross-distro sync had reintroduced them. - Simplify dead/redundant selectors: "not wasm32" is always true for rolling (no wasm32 target platform ever evaluated here, verified against vinca's own v1_selectors.py), so drop it from all three conditions that had it; "not win and not osx" is exactly "linux". - Correct the asio upper bound from <1.30 to <1.33: traced the actual upstream removal of asio::io_service to chriskohlhoff/asio@49fcd034 (asio 1.33.0, not 1.30); conda-forge doesn't publish 1.30-1.35 so both bounds resolve identically today, but <1.33 is the accurate one. Checked humble/jazzy for the same issues: none of the above patterns are present there. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same grouping already done for humble/jazzy: rolling had accumulated three separate "if: linux" blocks and three separate "if: not win" blocks (from the cross-distro sync plus this session's incremental fixes), each scattered across the file instead of merged into one. Consolidated each condition into a single block, matching the already-clean structure the other two distros have. Verified zero behavior change: evaluated selectors for linux-64, win-64, and osx-64 before and after and confirmed byte-identical resulting package sets on all three. Also dropped 3 duplicate entries surfaced by the consolidation (rosidl_generator_dds_idl was a plain duplicate; teleop_tools and turtlebot3_gazebo each had one copy unconditional and one under "not win" -- confirmed via the same selector evaluation that the "not win" copy was already dead, masked by the unconditional one). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… on osx Three follow-ups from PR review, each verified locally before pushing: - rmf_websocket/rmf_visualization_schedule: drop the asio <1.33 pin. Migrated the patch from the deprecated asio::io_service API to io_context/asio::post/asio::dispatch (io_service's member .post()/ .dispatch() don't exist on io_context; verified by compiling the exact patched code patterns against real conda-forge asio 1.36.0 + websocketpp 0.8.2 build 8, both compiling and linking successfully). websocketpp's own get_io_service->get_io_context rename is already fixed upstream (conda-forge/websocketpp-feedstock#8). - ouster_ros: unvendor spdlog instead of forcing include-dir order to prefer the bundled copy. package.xml already declares <depend> spdlog</depend> (mapped to conda-forge spdlog+fmt in robostack.yaml) but the CMakeLists.txt never called find_package(spdlog) -- it just used the vendored thirdparty copy directly. Now removes the vendored copy at configure time and links spdlog::spdlog; logging.cpp's only vendor-specific include (spdlog/fmt/bundled/args.h, which is just fmt's own args.h repackaged) becomes a plain <fmt/args.h>. Verified by compiling the same dynamic_format_arg_store/vformat usage against real conda-forge spdlog+fmt, and confirmed the file(REMOVE_RECURSE) + find_package(spdlog REQUIRED CONFIG) CMake pattern actually configures and links via a standalone CMake test (had to add CONFIG explicitly -- a stale custom Findspdlog.cmake module vendored alongside the SDK sits on CMAKE_MODULE_PATH and would otherwise be tried first, add_subdirectory-ing the very directory just removed). - mujoco_3d_lidar: conda-forge now publishes libmujoco for linux/osx/ win (it didn't when the osx skip was added), exporting the exact same mujoco::mujoco CMake target name mujoco_vendor's own NEVER_VENDOR_IGNORE_SATISFIED_CHECK fallback path expects. The package's only dependency is mujoco_vendor (verified via its real package.xml/CMakeLists.txt), so added it to packages_select_by_deps outright (it was never actually reachable via dependency-closure from anything else, so the old osx skip_by_deps entry was dead either way) -- confirmed via a full local recipe regeneration that ros2-mujoco-3d-lidar is now actually generated (1841 -> 1843 recipes). mujoco_ros2_control_plugins stays excluded on osx/win -- that's a genuine, separate EGL-availability gap, not a MuJoCo one. All three verified via a full local check_patches_clean_apply.py run (131/131 patches applied cleanly) plus per-package targeted rebuilds. Co-Authored-By: Claude Sonnet 5 <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
3 participants
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.
Summary
Validation
Dependency
This branch is rebased onto #38 (Full rebuild August 2026 II + Add RoboPlan packages). Merge #38 first; this PR should be reviewed as the commits after that parent.