Skip to content

Full rebuild Septmber 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 192 commits into
mainfrom
codex/cross-distro-sync
Open

Full rebuild Septmber 2026 : bump ros2-distro-mutex to 0.21.0 and build number to 27 and switch to new pinning mechanism (take 2)#41
Tobias-Fischer wants to merge 192 commits into
mainfrom
codex/cross-distro-sync

Conversation

@Tobias-Fischer

@Tobias-Fischer Tobias-Fischer commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Synchronizes portable CI/build tooling and the reusable cross-distribution workflow guidance.
  • Aligns released Vinca package seeds while retaining distro-specific platform selectors and release-owned settings.
  • Refreshes the async_web_server_cpp patch for its current Rolling release source.

Validation

  • Configuration sorting and whitespace checks pass.
  • Exact CI Vinca generation completed locally for linux-64, linux-aarch64, osx-arm64, osx-64, and win-64.
  • Patch application checker: 80 passed, 0 failed.

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.

@Tobias-Fischer
Tobias-Fischer force-pushed the codex/cross-distro-sync branch from 1e89074 to d7cfa0b Compare August 28, 2026 03:51
Tobias-Fischer and others added 25 commits August 28, 2026 14:00
- 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>
conda-forge published sip 6.16.1 on 2026-09-08, breaking ABI targeting
for packages like qt_gui_cpp_sip ("ABI v12 is being targeted but the
libqt_gui_cpp_sip module doesn't support it"). Already hit humble/jazzy's
CI (osx-arm64, linux-aarch64) via cache eviction; rolling builds
qt_gui_cpp through the same pyqt6/sip stack and carries qt_gui_cpp in
its rosdistro snapshot, so it's equally exposed once any platform's
cache for that package next evicts. Same fix as humble/jazzy: pin sip
to the 6.15 line in vinca_pinning.yaml and regenerate
conda_build_config.yaml via vinca-pinning-render.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@traversaro

Copy link
Copy Markdown
Member

@traversaro this is ready for review, too :)

Can we mention that this is a full rebuild in a the title with the mention at least to the increased mutex number? This simplifies discoverability of full rebuild PRs.

Comment thread patch/dependencies.yaml
Comment thread patch/dependencies.yaml
@Tobias-Fischer Tobias-Fischer changed the title Sync cross-distribution Vinca package coverage Full rebuild Septmber 2026 : bump ros2-distro-mutex to 0.21.0 and build number to 26 and switch to new pinning mechanism (take 2) Sep 9, 2026
@Tobias-Fischer Tobias-Fischer changed the title Full rebuild Septmber 2026 : bump ros2-distro-mutex to 0.21.0 and build number to 26 and switch to new pinning mechanism (take 2) Full rebuild Septmber 2026 : bump ros2-distro-mutex to 0.21.0 and build number to 27 and switch to new pinning mechanism (take 2) Sep 9, 2026
Tobias-Fischer and others added 5 commits September 10, 2026 07:50
…gged comment

- build_number 25 -> 27 (matching the reminder comment already in the
  file), mutex_package.build_number kept in sync at 27. Reminder
  comment now points at 28 for the next full rebuild.
- Restored a concise comment on cartographer_ros's dependencies.yaml
  entry explaining the remove_host/remove_run trick and the
  ceres-solver cpu pin -- this had been stripped in an earlier
  comment-cleanup pass, which is why it needed explaining again in
  review (traversaro, PR #41).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Your earlier conda_build_config.yaml `sip: 6.15` variant pin
(ecce9da) doesn't actually take effect: sip only comes in
transitively via pyqt-builder here, and variant pins only apply to a
package name that shows up directly in a recipe's own requirements.
Confirmed on jazzy (which has the identical pyqt-builder pattern) --
the CI run right after that same style of pin still resolved sip
6.16.1 and hit the identical ABI v12 failure. Verified the actual fix
mechanism via an isolated minimal recipe (pyqt-builder + sip 6.15.*
+ python, solved with `rattler-build --render-only --with-solve`):
it correctly resolves to sip 6.15.3 once the pin is direct.

Fixed by adding "sip 6.15.*" directly to qt_gui_cpp's and
python_qt_binding's add_host, same pattern as the existing
libboost/lua-style direct pins elsewhere in this file. Left the
conda_build_config.yaml variant pin in place too (harmless, and
covers any future recipe that does reference sip directly).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
packages_select_by_deps had three separate "if: linux" blocks and two
separate "if: not win" blocks scattered across the file. Merged each
condition down to one block, deduplicating one item that was already
listed in both "not win" blocks (rqt_robot_monitor) as a bonus find.
Re-sorted with vinca-sort-vinca-lists; verified via a real recipe
regeneration that the total generated recipe count is unchanged
(1821) and no orphaned-patch/sort issues were introduced.

One of the removed blocks had a comment explicitly there to work
around vinca's sort-tool bug for adjacent same/different-condition
blocks ("Comment separates this from the block above so
vinca-sort-vinca-lists doesn't pool their then-items together") --
with only one block per condition now, that workaround is no longer
needed anywhere in this file.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
image_geometry, apriltag_ros, and apriltag_mit all still find_package'd
the pre-OpenCV5 "calib3d" component/header layout, which conda-forge-pinning
just bumped libopencv to (5.0.0) for the first time this cycle ("Could NOT
find OpenCV (missing: calib3d)"). humble and jazzy already carry the real
fix for these three packages (calib3d -> calib+geometry); port it here
instead of pinning the whole distro back to OpenCV 4 -- verified each patch
applies cleanly against rolling's actual release tags. cv_bridge and rtabmap
already had their own OpenCV5 patches on this branch.

Also tighten rmf_websocket/rmf_visualization_schedule's "asio <1.30" pin to
"<1.28": standalone Asio 1.28.0 already removed the deprecated
get_io_service() aliases that websocketpp 0.8.2 (conda-forge's only version)
calls directly, so <1.30 still resolved to a broken 1.29.0.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…enCV5

Tightening the asio pin didn't fix rmf_websocket: I nearly overwrote the
already-committed boost->standalone-Asio migration patch on this package
while adding a fix for a *different*, additional regression -- recovered
and merged instead of clobbering it. Root cause of the still-failing build
("has no member named 'get_io_service'") is unrelated to asio's version:
diffing conda-forge's websocketpp 0.8.2 feedstock build 0 against build 8
shows its own transport/asio/endpoint.hpp renamed get_io_service() to
get_io_context() somewhere in that build history, independent of asio.
Patch the call sites instead and revert the asio pins back to <1.30 (the
value that was already correct before this investigation).

Also: rqt_image_view hits the same fresh OpenCV5 break as image_geometry/
apriltag (CV_GRAY2RGB/CV_BGR2RGB dropped from the old C API) -- ported the
same cv::COLOR_* fix humble/jazzy already carry, plus rolling's own extra
CV_BGR2RGB occurrence not present in their older package version.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note for MTC version 0.2.0 which just released last week, I had to do this for Windows on Lyrical:

RoboStack/ros-lyrical#41 (comment)

RoboStack/ros-lyrical@6127aa9

Tobias-Fischer and others added 4 commits September 10, 2026 17:32
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>
Comment thread patch/dependencies.yaml
# 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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am confused, based on this comment this needs to be removed?

Comment thread patch/dependencies.yaml
Comment on lines +330 to +331
add_host: ["openssl >=3.6.4", "asio <1.30"]
add_run: ["openssl >=3.6.4", "asio <1.30"]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we drop the asio <1.30 here, given conda-forge/websocketpp-feedstock#8 ?

+if(WIN32)
+ # py_binding_tools::py_binding_tools transitively pulls in conda's own
+ # (differently-versioned) system pybind11 include directory alongside
+ # this project's vendored smart_holder pybind11 fork. Angle-bracket

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like an hallucination, this project is not using the smart_holder pybind11 fork since last year: moveit/moveit_task_constructor#400 .

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually in the ros2 branch this only changed last week?

moveit/moveit_task_constructor@dbfe447

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it seems I was the one hallucinating, not the agent!

+# 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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fihy, can't we unvendor spdlog here instead of forcing the vendored version?

Comment thread vinca.yaml
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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fishy, we should unvendor mujoco, why it is a problem if there is no mujoco binary on macOS?

Comment thread vinca.yaml
# release copies.
- iceoryx_binding_c
- iceoryx_hoofs
- iceoryx_posh

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? We are properly devendoring this with generate_dummy_package_with_run_deps , there is no need to remove these package from deps.

Comment thread vinca.yaml
Comment on lines +265 to +275
- joint_state_publisher
- joy
- ament_flake8
- ament_lint
- ament_lint_common
- ament_pep257
- ament_pycodestyle
- autoware_adapi_v1_msgs
- autoware_adapi_version_msgs
- autoware_auto_msgs
- autoware_internal_debug_msgs

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This different indentation is hard to read.

Comment thread vinca.yaml
Comment on lines +327 to +331
- turtlebot3_gazebo
- urdf_launch
- yaml_cpp_vendor
- rqt_mocap4r2_control
- rqt_moveit

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why such indentattion?

Comment thread vinca.yaml

# Allied Vision only ships prebuilt Vimba SDK binaries (libVimbaC/libVimbaCPP)
# for Linux (x86_64/arm), not macOS -- no source-level fix is possible.
- if: not win and not osx

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I guess we should have if: linux?

Comment thread vinca.yaml
- if: not win and not osx
then:
- avt_vimba_camera
- if: not wasm32

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why wasm32 ?

Comment thread vinca_pinning.yaml
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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is fishy, there is no support in vinca for channel_source: null, I had it only locally in a vinca copy.

@traversaro

Copy link
Copy Markdown
Member

@traversaro this is ready for review, too :)

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants