Full Rebuild September 2026 + Sync cross-distribution Vinca package coverage - #271
Open
Tobias-Fischer wants to merge 65 commits into
Open
Full Rebuild September 2026 + Sync cross-distribution Vinca package coverage#271Tobias-Fischer wants to merge 65 commits into
Tobias-Fischer wants to merge 65 commits into
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Port pixi.toml structural changes: update vinca rev to 6aacb6f, inline platform-based glibc, pixi-build preview, PYTHONIOENCODING activation env (structural changes already in main, ensuring rev sync) - Sync .github/workflows/testpr.yml: add permissions block, upgrade setup-pixi to v0.10.0 (pixi v0.75.0), add 3-attempt recipe-generation retry loop, fix delete-outdated-cache-entries exit bug, move PYTHONIOENCODING to pixi.toml activation - Sync check_patches_clean_apply.py: narrow except to AttributeError, add git-cache retry on fetch failure, fix sys.exit always returning 2 - Normalize AGENTS.md: use $DISTRO placeholder instead of ros-jazzy- hardcoded prefix in all examples Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
pixi.lock was stale after removing the corrupted .pixi/envs/default (pyparsing namespace-package corruption) and running pixi install fresh. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Update build_gap_report.py (cross-distro sync) - Update libg2o, python-qt-binding, qt-gui-cpp patches - Refresh pixi.lock Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The "Save build cache" step gates on steps.build-recipes.outcome, but the "Build recipes" step had no id: build-recipes set, so that context reference was always empty and the always() && (...) condition was always false. The cache was never being saved regardless of outcome. Mirrors the same fix applied to ros-humble. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…zy macOS build Ports the OpenCV5, CMake4, and dependency-config unification work already landed on humble, and adds fresh fixes surfaced while getting jazzy's macOS build to complete cleanly: - OpenCV5 API migration across ~15 packages: legacy CV_* color/type macros -> cv::COLOR_*/cv::* equivalents, calib3d -> calib/geometry component split, removed C-API headers (types_c.h etc.), and the free cv::aruco::detectMarkers()/estimatePoseSingleMarkers() functions replaced with the ArucoDetector class (image-proc, image-rotate, cv-bridge, image-geometry, compressed-image-transport, rqt-image-view, theora-image-transport, grid-map-cv, apriltag-mit, moveit-ros-perception, rtabmap). - Legacy EIGEN3_INCLUDE_DIR (unset by modern Eigen3Config.cmake) replaced with the Eigen3::Eigen target across the autoware osqp/qp/kalman-filter chain, plus an fmt::fmt link fix for autoware-ekf-localizer. - Boost modernization: dropped the no-longer-resolvable "system" component from find_package(Boost COMPONENTS ...) and ported boost::asio::io_service -> io_context / boost::filesystem::complete|extension -> absolute()/ path::extension() (libpointmatcher, sick-safetyscanners-base). - libnabo: C++14 bump for modern Eigen, numpy>=2.0 header path, missing <cassert>, and OpenMP linked explicitly for clang (plus find_dependency in its exported Config.cmake so consumers pick it up too). - libg2o: switched host Qt dependency from qt-main (Qt5) to qt6-main to match the rest of the Qt6 stack and unblock rtabmap's PCL/VTK requirement. - vinca.yaml: closed the largest gaps in jazzy's package coverage versus humble's meta-package tree, bumped vtk to 9.7.0 to match humble. - Added check_dependency_compat.py (pre-build pin-conflict solver) and vinca_pinning.yaml, matching humble's tooling. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Resolved conflicts by hand: - pkg_additional_info.yaml/vinca.yaml: several hunks were additive on both sides at the same insertion point (new package entries); kept the union, de-duplicated, and re-sorted with `pixi run sort`. Kept our newer hpp_fcl/pinocchio/visp version bumps (with their libboost/conda-forge compat comments) over main's older overrides. - pixi.toml: kept the pinned vinca rev plus curl/go-yq/colordiff (used by check_dependency_compat.py); took main's setup-pixi bump. - pixi.lock: regenerated with `pixi lock` against the merged pixi.toml instead of hand-merging the generated lockfile. - testpr.yml: combined both branches' cache-cleanup steps. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…onstraints Already-built packages pin ros2-distro-mutex 0.16.* jazzy_*; bumping to 0.17.0 (matching the pattern already used on kilted) makes sure a stale mutex build isn't silently resolved once vtk 9.7.0 lands in the run_constraints, instead of the constraint mismatch surfacing later as a confusing solver failure. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Avoid multiple pushes racing multiple full CI matrices in parallel; same concurrency group already added to ros-humble's testpr.yml this session. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…o-mutex 904749d bumped ros2-distro-mutex 0.16.0 -> 0.17.0 for the new vtk 9.7.0 run_constraint, but ros2-ros2cli and ros2-rosidl-cli are already published on robostack-jazzy with build_number 22, hard-pinned (via run_exports) to ros2-distro-mutex 0.16.*. vinca's already-built check only compares each package's remote build_number against this per-package override (or the global default), so it kept treating both as current and never regenerated recipes for them -- even though their published build's mutex pin is now unsatisfiable, breaking the whole solve for anything that depends on them (e.g. ros-jazzy-rosidl-generator-type-description -> ros2-rosidl-cli). This isn't the local-cache class of staleness (a testpr.yml cache-bust can't touch an already-published remote artifact); bumping the per-package build_number is the mechanism vinca provides for forcing a specific package's republish without touching the global counter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of issue as 3dc6b32 (ros2cli/rosidl_cli), but a local-cache staleness rather than a published-remote one: ros2-ros-workspace's cached artifact is already at build_number 22 (matching current), so vinca's already-built check treats it as current, but that cached build predates 904749d's ros2-distro-mutex 0.16.0 -> 0.17.0 bump and is hard-pinned to the now-unsatisfiable old version. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… C:\bld\...
ament_python_install_package()/ament_python_install_module() embed a raw
Windows path (with backslashes, from get_executable_path() and
CMAKE_INSTALL_PREFIX) directly into an install(CODE "...") string. That
string gets written verbatim into cmake_install.cmake and re-parsed as CMake
source at install time, where CMake's own string-escape rules choke on
whatever backslash-letter sequence the path happens to contain -- in this
case "\b" from this workflow's C:/bld/win-64 build root ("Invalid character
escape '\b'", first hit by ros2-ament-cmake-test). Convert both paths via
file(TO_CMAKE_PATH ...) before embedding, the standard fix for this class of
CMake footgun.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same pattern as ddbda94 (ros2-ros-workspace). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…tex bump Individually cache-busting each affected package (ddbda94, 71ff3ad, and now ros2-ament-cmake-core) as it surfaced was turning into unbounded whack-a-mole -- this is a systemic issue (any package cached/published at build_number 22 with the pre-904749dd mutex pin baked in), not isolated bugs in each one. The comment already left at this line anticipated exactly this ("next build number should be 23"). This is a full-rebuild-triggering change: every package in the distro will rebuild fresh once its cached build_number no longer matches, so this CI run will take considerably longer than the incremental --skip-existing runs tonight. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
crop_foremost.cpp used the legacy C-API CV_THRESH_TOZERO_INV macro, which OpenCV5 dropped in favor of the cv::THRESH_TOZERO_INV enum value. Same class of legacy CV_* macro removal already hit elsewhere this cycle (CV_GRAY2RGB in rqt_image_view). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
disparity_node.cpp included the old-style <opencv2/calib3d/calib3d.hpp> path; OpenCV5 only ships the flat <opencv2/calib3d.hpp> header. Same class of header-layout change already hit elsewhere in image_pipeline this cycle. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mcap_vendor FetchContent's mcap v1.3.1 (foxglove/mcap); its types.hpp uses uint16_t/uint64_t/etc without including <cstdint>, which GCC 15's leaner libstdc++ headers no longer pull in transitively. It's a downloaded tarball, not a git checkout, so force-include the header via CMAKE_CXX_FLAGS instead of source-patching, same approach used for as2_platform_multirotor_simulator. Separately, ros2-control-msgs failed on win-64 with sensor_msgs's cmake config missing, despite ros2-sensor-msgs being present locally -- its cached .conda was only ~25KB (implausibly small for a message package), suggesting a prior interrupted/cancelled build (many superseding pushes via the concurrency group this cycle) got cached in a corrupt state. Cache-bust it to force a fresh rebuild. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same depthai-core-release tag (2.31.1-1) as humble, hitting the identical two-layer CMake4 floor violation: its own top-level cmake_minimum_required(VERSION 3.4), and Hunter's subprocess-spawned cmake invocation. Port both fixes over: bump the version, set CMAKE_POLICY_VERSION_MINIMUM as a real env var before HunterGate (env vars propagate to the child process; a -D cache arg would not), and proactively add the same additional_cmake_args cache arg for cmake/CMakeRC.cmake's separate same-process include() later in the file (confirmed necessary for this exact source on humble). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same depthai-ros-release tag (2.12.2-1) and identical CMakeLists.txt as humble's depthai_bridge (confirmed via diff) -- hits the same OpenCV major-version-pin, calib3d->calib+geometry component split, and hardcoded opencv_calib3d link library issues. Port the same patch over verbatim. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…al source) Same depthai-ros-release tag (2.12.2-1) and identical CMakeLists.txt as humble's depthai_examples (confirmed via diff). Port the same fix over. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same pattern as ros2-sensor-msgs: ros2-rcl failed to find rcl_interfaces's cmake config despite it being present in the local channel, and its cached .conda was also only ~25KB. Force a fresh rebuild. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…om source Building from ROS source fails to find Simde (its vectorization backend) via find_package. Same fix already applied on humble: skip the source build and generate a dummy package depending on the conda-forge proxsuite release directly (also more up to date than the ROS-packaged version). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Third instance of the same ~25KB corrupt-cache pattern: ros2-hardware-interface failed to find control_msgs's cmake config despite it being present in the local channel. Force a fresh rebuild. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fixes as humble (identical upstream source, ros2-gbp/libg2o-release): qt isn't declared in package.xml and CMakeLists.txt's find_package(QGLViewer) is optional, so the qt host dep is dead weight that conflicts with vtk's now-Qt6-only build (vtk 9.7.0 pinned here too). Also add -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=ON for csparse_extension's win-64 LNK1181 (no import .lib generated without it). Root-caused and verified by a peer session fixing the identical issue on rolling. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fix the user already applied on ros-humble (c9a28f31): GCC 15's leaner libstdc++ headers no longer pull in <cstdint> transitively, so msgpack11.hpp's uint8_t/uint16_t/uint32_t/uint64_t usages fail with cascading "does not name a type" / template-argument errors. Verified identical upstream source between humble and jazzy's pinned tags (both release/*/sick_scan_xd/3.9.0-1) before porting; patch applies cleanly and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
target_compile_options() unconditionally passes -Wno-error=maybe-uninitialized (a GCC/Clang-only spelling), which MSVC's cl.exe rejects outright: "error D8021: invalid numeric argument '/Wno-error=maybe-uninitialized'". Guard it with if(NOT MSVC). Verified patch applies cleanly against the pinned release tag and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
interpolation_utils.hpp uses std::to_string/std::invalid_argument but never includes <string>; GCC/libstdc++ pulls it in transitively via <stdexcept>/<vector>, MSVC's STL doesn't, causing cascading C2039/ C3861/C2512 errors. Same fix already applied identically on ros-humble (pre-existing patch, same upstream source/line numbers) -- ported the identical one-line fix here. Verified applies cleanly against the pinned release tag and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…der (win-64)
bt3_recorder links against ${BEHAVIOR_TREE_LIBRARY}, which only adds
ZMQ_INCLUDE_DIRS as PRIVATE, so they don't propagate. Works by
accident on Unix (the conda prefix's include dir is already on the
default search path there) but not on MSVC: "error C1083: Cannot open
include file: 'zmq.h'" via the vendored cppzmq wrapper. Add the
include dirs directly to bt3_recorder's own target. Same one-line fix
already exists in ros-humble's (much larger, different-tag) patch for
this package -- applied just this piece here since jazzy pins a
different upstream tag/repo and CI's actual error was purely the
missing include path, not the more extensive vendored-zmq.hpp issues
humble's patch also addresses. Verified applies cleanly and passes
check-patches; may need further porting from humble's patch if CI
surfaces additional issues.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Fixed the ZMQ include-path issue for bt3_recorder, but CI progressed to a second failure in the same package: it uses its own BUILD_UNIT_TESTS CMake option (default ON) instead of the standard BUILD_TESTING that rattler-build already passes as OFF, so its test suite always gets compiled -- failing with "Cannot open include file: gtest/gtest.h" (the ament_cmake_gtest path here doesn't get the FetchContent-provided gtest include dir). We only need the library artifact, not its tests; pass -DBUILD_UNIT_TESTS=OFF explicitly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
node.cpp's object file exceeds MSVC's default section-count limit due to heavy Boost/Eigen/protobuf template instantiation: "error C1128: number of sections exceeded object file format limit". Same fix already applied on ros-humble (identical upstream CMakeLists.txt context); appended as a new hunk ahead of the existing CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS/glog-version hunk in the same file. Verified against the pinned release tag and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ion limit) ros_filter.cpp's object file exceeds MSVC's default section-count limit due to heavy Eigen template instantiation: "error C1128: number of sections exceeded object file format limit". Same fix already applied for cartographer_ros's node.cpp on both distros this session; added as a new hunk ahead of the existing _USE_MATH_DEFINES/ WINDOWS_EXPORT_ALL_SYMBOLS hunk in the same file. Verified against the pinned release tag and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… (win-64) freetype 2.11.1's cmake_minimum_required(VERSION 2.8.12) is below CMake 4's floor of 3.5, failing freetype_vendor's ExternalProject configure step: "CMake Error at CMakeLists.txt:112 (cmake_minimum_required)". Same fix already applied to this exact file for the ogre_vendor sub-build (OGRE_CMAKE_ARGS); added the equivalent for freetype_vendor's own CMAKE_ARGS list. Verified applies cleanly and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Added the usual /bigobj fix for clearpath_diagnostic_updater.cpp's
MSVC section-count limit (same as cartographer_ros and
robot_localization this session). While doing so, discovered and
fixed a latent bug in the existing patch file itself: it was in
git-format-patch/mbox style (From/Date/Subject header + a bare "---"
body separator) immediately followed by a real diff header, which
rattler-build's patch-apply tool misparsed as a single malformed hunk
(confirmed via check-patches: "Failed: 1", "could not find context in
target file" -- even though `git apply --check` had reported this as
fine, since git apply is more lenient about this than the real patch
tool). Rewrote the whole file in the same plain "diff --git" style
used by every other patch in this repo, which both `git apply --check`
and check-patches now agree on ("Failed: 0").
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The "Build recipes" step's raw log is often tens of thousands of lines; finding the actual failure means fetching and grepping the whole thing by hand. Tee the build output to a file, extract a compact diagnostic excerpt (the last ~20 error/failure markers with surrounding context, plus the recipe heading they belong to) into the job summary, and upload the full log as an artifact for when more context is needed. Ported from a peer session's identical addition on ros-rolling (already independently verified there), adapted to this repo's own "Build recipes" step structure and channel URLs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The file was named ros-jazzy-sick-scan-xd.osx.patch, but the package's
actual resolved build name is ros2-sick-scan-xd (per jazzy's dual
package_name_mode) -- and since ros2-sick-scan-xd.patch ALSO exists as
its own separate file, vinca's add_package_name_variants() cross-link
(a setdefault) never merges the two: the "ros2-sick-scan-xd" dict key
already existed on its own before the variant-linking step runs, so
the osx-specific patch list from the "ros-jazzy-sick-scan-xd" key was
never attached to it. Confirmed via vinca's actual patch-scanning
logic and empirically: regenerating osx-64 recipes showed only
ros2-sick-scan-xd.patch in the "patches:" list, never the .osx.patch,
despite the file existing on disk this whole time.
Concretely this meant the CMakeLists.txt's unconditional
"-fno-var-tracking-assignments" (GCC-only flag) was never actually
stripped for macOS builds, and Apple's clang rejected it outright
("error: unknown argument"), reached now that CI has progressed this
deep into the win-64/osx-64 fix chain this session. Renaming the file
to match the real resolved package name is sufficient -- no source
content change needed, the existing patch already deletes the whole
offending CMake block. Verified via check-patches ("Failed: 0") and
via a small standalone script replicating vinca's exact patch-dict
construction, confirming no OTHER orphaned platform-patch exists on
either distro right now.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… visibility (win-64) LINK : fatal error LNK1189: library limit of 65535 objects exceeded. Root cause: our own existing win.patch's `set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)` blanket-exports every symbol, including every member of every ros_gz_bridge::Factory<ROS_T, GZ_T> class template instantiation -- one per bridged ROS<->GZ message type pair across 14 message packages -- which explodes past MSVC's import-library member-count limit. This is a known, already-fixed upstream bug: gazebosim/ros_gz#930 (merged 2026-08-21) replaces the blanket export with explicit GenerateExportHeader-based visibility (ROS_GZ_BRIDGE_VISIBLE) on just the actual public API. Backported that fix: 18 of 22 upstream-changed files applied cleanly via `git apply --reject`; CMakeLists.txt and convert/ros_gz_interfaces.hpp needed manual reconciliation against our older pinned tag (1.0.23-1 predates even the introduction of the original WINDOWS_EXPORT_ALL_SYMBOLS line, so upstream's own diff removing it didn't have a matching context to remove -- our version never had it upstream at all, only via our own patch). Kept our existing /bigobj addition, just dropped the WINDOWS_EXPORT_ALL_SYMBOLS line and added the 18-clean-file visibility plumbing plus the two manually-reconciled files. Verified the full combined patch applies cleanly against a fresh pristine clone and passes check-patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…heck vinca.yaml comments: packages_select_by_deps's if-wrapper (primary way to exclude a package's own recipe), packages_skip_by_deps (transitive pull-in only, does not stop direct selection), and packages_remove_from_deps (a third, independent way to fully exclude a package's own build via resolve_pkgname()/should_skip_pkg -- which also inseparably strips it from other recipes' deps) are easy to conflate; this came up repeatedly this session, including a mechanism that was initially mis-explained. Verified against the vinca revision pinned in pixi.toml. check_orphaned_platform_patches.py replicates vinca's exact patch-glob + add_package_name_variants() logic to catch a real bug class: a platform-specific patch silently never wired into any recipe because its filename uses a different name-prefix than another patch for the same package (setdefault() in add_package_name_variants is a no-op once either prefix already has its own entry). Wired into `pixi run check-patches` via a new check-orphaned-patches task dependency so it runs on every PR. Running it here found a real (if currently low-impact) instance: ros-jazzy-apriltag-ros.patch was never applied (package_name_mode: both always resolves apriltag_ros's own patch lookup to the ros2- prefix), and had been fully superseded by ros2-apriltag-ros.patch's OpenCV5 fix; its only content was an APPLE-only guard, moot anyway since apriltag_ros only builds on linux. Deleted the dead file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Follow-up to aa7eb95 (which only committed the dead-patch deletion) -- this adds the actual check_orphaned_platform_patches.py script, wires it into `pixi run check-patches` via pixi.toml, and adds the explanatory vinca.yaml comment blocks on the three exclusion mechanisms (packages_select_by_deps / packages_skip_by_deps / packages_remove_from_deps) described in that commit's message. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Timer.h's non-POSIX (i.e. Windows) branch includes <boost/timer.hpp> and typedefs the deprecated boost::timer (v1). As of Boost 1.90 (pinned via libboost 1.90.* in vinca.yaml's mutex run_constraints), that header hard-errors (C1189) unless BOOST_TIMER_ENABLE_DEPRECATED is defined. Replaced the typedef with a minimal std::chrono-based struct that keeps the same interface (default-construct starts, restart(), elapsed()), avoiding the boost dependency entirely rather than just suppressing the deprecation warning. Verified via `pixi run vinca --platform win-64` + `python check_patches_clean_apply.py --recipe ros2-libpointmatcher` (patch applies and rattler-build's patch phase passes). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…counter Follow-up to 70c52ec (boost::timer fix unblocked compilation, surfacing this next error). MSVC's classic /openmp (OpenMP 2.0 subset) requires a parallelized for-loop's index variable to have signed integral type; sparsetv.hpp and SpectralDecomposition.cpp use std::size_t loop counters in all 13 of their #pragma omp parallel for loops (GCC/Clang's OpenMP 3.0+ support allows unsigned there, so this only ever surfaced on win-64). Changed each to std::ptrdiff_t (matching Eigen::Index's own default type, so the tensors(i)/col(i) indexing stays natural) with an explicit static_cast on the nbPts bound. Verified via `check_patches_clean_apply.py --recipe ros2-libpointmatcher`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ult override The shared vinca-generated bld_ament_cmake.bat build script passes -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=ON as a CACHE default for every ament_cmake package. The earlier GenerateExportHeader fix only removed this package's own `set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)` line, but simply removing it leaves that cache default in effect (a plain set() only shadows a cache variable if it actually executes) -- silently re-enabling blanket symbol export and reintroducing the exact LNK1189 problem this whole fix chain was meant to solve. Added an explicit set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS OFF) right where the old ON used to be, which does override the cache default. Found while diagnosing why humble's identical fix still failed on PR #420 (humble additionally had a legacy base patch redundantly setting the same variable, deleted there in a separate commit -- jazzy never had that second patch). Verified via `python check_patches_clean_apply.py --recipe ros2-ros-gz-bridge` (passes). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…tibility __PRETTY_FUNCTION__ is a GCC/Clang-only builtin (used in 6 RCLCPP_DEBUG calls purely for the function name); MSVC has no such identifier, causing C2065 "undeclared identifier" (hit on PR #271's win-64 job). Added a portable ROS2_PPS_PRETTY_FUNCTION macro (__FUNCSIG__ on MSVC, __PRETTY_FUNCTION__ elsewhere) and swapped all 6 usages. New patch file (no existing patch for this package on jazzy, unlike humble's older 1.0.5 release which already carries an RCLCPP_VERSION_MAJOR compat shim touching the same file -- same fix merged into that patch there). Verified via `check_patches_clean_apply.py --recipe ros2-persist-parameter-server`. Also added a win-64 cache-bust for ros2-ros-gz-bridge in testpr.yml: --skip-existing matches on name+version+build_number, not patch content, so a previously-cached (pre-fix) .conda for this package could otherwise silently mask whether the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS fix (37393b9) actually works, since it would never be exercised by a fresh build. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rosbag2_performance_benchmarking_msgs' generated Python extension
("_s") rosidl typesupport target hits MSVC error C1083 "Cannot open
compiler generated file: ''" on win-64 -- reproduced consistently
across two separate CI runs (a genuine rerun, not just a retry of the
same job), ruling out a one-off flake. This is a known rosidl/
ament_cmake codegen race between the main C library target and its
Python extension sibling both consuming the same generated .c file
without a proper build dependency edge -- the identical error
signature already excluded on ros-humble for iiwa14_moveit_config.
Verified via vinca's own dependency-closure resolver that
rosbag2_performance_benchmarking (the tool) is the ONLY thing that
depends on rosbag2_performance_benchmarking_msgs, so moving the tool
itself into an "if: not win" block (rather than the msgs package)
cleanly and completely excludes both with no other collateral impact.
Confirmed via full recipe regeneration: win-64 drops from 1647 to 1643
recipes (exactly these packages) with no dangling references, while
linux-64 still builds all four (ros-jazzy-/ros2- x tool/msgs) normally.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Root-caused the 'No candidates were found for libdc1394 *' solve failure on PR #271's win-64 job (previously flagged as background task_7ffbed8a after ruling out robostack.yaml's libpcl-all-dev mapping, rtabmap's own package.xml, and conda-forge's pcl/vtk metadata as the source -- all correctly eliminated, since none of those were actually it). The real source: patch/dependencies.yaml's `rtabmap: add_host` entry (a manually-curated list of extra host deps beyond what package.xml declares) lists "libdc1394" as a plain, unconditional string -- found by instrumenting vinca's actual generate_output() call chain directly, since static config inspection alone couldn't locate it (this mechanism reads patch/dependencies.yaml, not robostack.yaml or pkg_additional_info.yaml, and isn't obviously discoverable by name). Confirmed via conda-forge's win-64 repodata that libdc1394 has zero published builds there (libusb and ceres-solver, the other two additions, are both fine). rtabmap's own CMakeLists.txt already treats DC1394 as fully optional (`option(WITH_DC1394 ... ON)`, `FIND_PACKAGE(DC1394 QUIET)`, every use guarded by `IF(DC1394_FOUND)`), so it builds fine without it. Wrapped it in the same Jinja `${{ 'x' if <cond> }}` conditional-list-item pattern already used for libgl-devel/libopengl-devel in that same list: `${{ 'libdc1394' if not win }}`. Verified via full recipe regeneration on both win-64 (renders as a literal conditional, correctly omitted there) and linux-64 (still included). Also kept a small robostack.yaml hardening (libdc1394-dev now maps to an empty list on win64 rather than [libdc1394]) as defense in depth, in case any other package.xml ever declares it directly via rosdep -- harmless but wasn't the actual fix here. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Past the libdc1394 fix (76bf93d), win-64 progressed deep into rtabmap's own build and hit error C3861: 'CoInitialize': identifier not found in both app/src/main.cpp and tools/DatabaseViewer/main.cpp. Both already correctly guard the call with #ifdef WIN32, but neither includes <objbase.h> (or anything that transitively pulls it in on this build's include chain) -- CoInitialize is declared there. Added the missing include, guarded the same way as the call site. Verified via `check_patches_clean_apply.py --recipe ros2-rtabmap`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Past the rtabmap fixes, win-64 got much further (rtabmap itself archived successfully) and hit a new failure: error C2061 'timeval' undeclared / C2065 'timeout' undeclared in Exceptions.h's timeout_error(const std::string&, timeval) constructor overload. struct timeval is a POSIX/BSD sockets type with no automatic declaration on Windows (needs winsock2.h there, sys/time.h on Unix -- neither is included). Rather than adding a platform-specific socket header (risky: winsock2.h/windows.h have strict inclusion-order requirements, and this header doesn't control what else gets included before it in a given translation unit), traced every call site: all three throw sites (UDPClient.cpp, TCPClient.cpp x2) actually pass sick::types::time_duration_t (= boost::posix_time::time_duration), matching the OTHER timeout_error overload a few lines below. The timeval-taking overload is entirely dead code, never constructed anywhere in the package -- deleted it instead of trying to make an unused signature portable. Verified via `check_patches_clean_apply.py --recipe ros2-sick-safetyscanners-base`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Past the sick_safetyscanners_base fix, win-64 progressed further and hit LNK1181 "cannot open input file 'mode.lib'" linking mode_monitor/mode_manager against the mode library. mode is a SHARED library with no explicit dllexport annotations; on Windows, MSVC does not generate an import library (.lib) at all for a DLL that exports zero symbols, so any downstream target linking against it fails to even find the .lib file. Added set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) to auto-export everything (mode is a small, 5-source-file library, well under the 65535-object import-library limit that made this same fix unsuitable for ros_gz_bridge earlier in this session). ros-humble already carries this exact fix (patch/ros-humble-system-modes.win.patch, identical one-line diff, from an earlier session) -- confirms this is the right approach; jazzy just never had it since system_modes had presumably never been reached on jazzy's win-64 build before. Verified via `check_patches_clean_apply.py --recipe ros2-system-modes`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
visp's upstream package.xml declares <depend>zbar</depend> unconditionally, which resolved through robostack.yaml's flat zbar mapping into ros2-visp's generated host/run deps. zbar has zero win-64 builds on conda-forge, so the solve failed with "No candidates were found for zbar *". The real external visp conda-forge package (which our dummy ros2-visp metapackage wraps via a run constraint) has no zbar dependency on win-64 either, per its own win-64 repodata — so excluding zbar there is correct, not just a workaround. Matches humble's existing per-platform zbar mapping, which already excludes win64 (and linux-aarch64, unrelated to this fix). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tobias-Fischer
commented
Sep 7, 2026
Tobias-Fischer
left a comment
Tobias-Fischer
left a comment
Contributor
Author
There was a problem hiding this comment.
Comments for Claude
Tobias-Fischer
changed the title
Cosmetic-only cleanup per PR review: shorten/remove overly detailed inline comments added during recent fix commits (kept the substance, dropped the narration), and drop the now-unnecessary per-package cache-delete entries in testpr.yml (each one addressed a since-fixed one-off issue). Moved the "3 ways to exclude a package" reference block from vinca.yaml into AGENTS.md, condensed. Also dropped the now-redundant ros2cli/rosidl_cli per-package build_number overrides in pkg_additional_info.yaml now that the global build_number is already 23. Verified zero effect on generated output: recipes regenerated for win-64 and linux-64 are byte-identical to pre-change, sort/orphaned- patch checks pass. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Both were still built from ROS source (ros2-gbp/*-release). Switch to
dummy metapackages depending on conda-forge's own cyclonedds and
libiceoryx-binding-c/hoofs/posh, matching the pattern already used on
humble (iceoryx) and rolling (both).
cyclonedds excludes win-64: conda-forge's win-64 channel only has
cyclonedds 0.5.0, 0.6.0 and 11.0.1, not the 0.10.x series ROS is
pinned to and rmw_cyclonedds_cpp was built against (11.0 changed
enough that "too much changed since 0.10 to list it all" per
upstream's own release notes, and rmw_cyclonedds_cpp's unpinned
find_package(CycloneDDS) would configure but isn't verified to
compile against it). win-64 keeps building cyclonedds from source
exactly as before. iceoryx needed no such exclusion -- 2.95.8 is
available on every platform including win-64, and humble already
proves the vendored-cyclonedds + dummy-iceoryx combination builds
cleanly on win-64 today.
Removed the now-dead ros-jazzy-iceoryx-{binding-c,hoofs,posh}.win.patch
files: real Windows build fixes for the vendored source, but iceoryx
no longer builds from source on any platform so they can never be
applied again.
Verified via recipe regeneration: iceoryx is a dummy package on every
platform (including win-64); cyclonedds is a dummy package everywhere
except win-64, which is untouched (still the vendored build).
check_orphaned_platform_patches.py and check_dependency_compat.py
show no new issues.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…e too My previous commit (7b82476) kept cyclonedds vendored on win-64, believing conda-forge's win-64 channel only had 0.5.0/0.6.0/11.0.1. That was a version-sort bug in my own verification (lexicographic string sort put "0.10.5" before "0.5.0", so truncating to the last few sorted entries silently dropped it) -- 0.10.5 is in fact published for win-64, matching every other platform. Removing the unnecessary platform exclusion; cyclonedds is now a dummy metapackage on all platforms uniformly, same as iceoryx. Verified via recipe regeneration: win-64 now produces the same dummy package (cyclonedds >=0.10.5,<0.11.0a0 run constraint) as every other platform. check_orphaned_platform_patches.py and pixi run sort --check both clean. 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
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation