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
Conversation
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>
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>
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. |
…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>
There was a problem hiding this comment.
note for MTC version 0.2.0 which just released last week, I had to do this for Windows on Lyrical:
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>
| # 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. |
There was a problem hiding this comment.
I am confused, based on this comment this needs to be removed?
| add_host: ["openssl >=3.6.4", "asio <1.30"] | ||
| add_run: ["openssl >=3.6.4", "asio <1.30"] |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
That sounds like an hallucination, this project is not using the smart_holder pybind11 fork since last year: moveit/moveit_task_constructor#400 .
There was a problem hiding this comment.
Actually in the ros2 branch this only changed last week?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
This is fihy, can't we unvendor spdlog here instead of forcing the vendored version?
| # 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 |
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?
| # release copies. | ||
| - iceoryx_binding_c | ||
| - iceoryx_hoofs | ||
| - iceoryx_posh |
There was a problem hiding this comment.
Why? We are properly devendoring this with generate_dummy_package_with_run_deps , there is no need to remove these package from deps.
| - 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 |
There was a problem hiding this comment.
This different indentation is hard to read.
| - turtlebot3_gazebo | ||
| - urdf_launch | ||
| - yaml_cpp_vendor | ||
| - rqt_mocap4r2_control | ||
| - rqt_moveit |
|
|
||
| # 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 |
There was a problem hiding this comment.
So I guess we should have if: linux?
| - if: not win and not osx | ||
| then: | ||
| - avt_vimba_camera | ||
| - if: not wasm32 |
| # 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 |
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.
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>
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.