Repository navigation
Full Rebuild October 2026 + Sync cross-distribution Vinca package coverage - #271
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>
|
@traversaro @Tobias-Fischer I've just bumped to the most recent (October 5 2026) snapshot and synced with the above PR. Trying a full rebuild now, though I anticipate a few extra patches being needed due to the sync. Will babysit this PR today... |
b369d07 to
3ac2369
Compare
|
@traversaro one MuJoCo question: the |
|
@sea-bass - thanks a lot, I really appreciate it! Did you take a look at porting RoboStack/ros-rolling#51? |
As you prefer. At the moment there is no |
|
Also, we just got mujoco 3.15 on conda-forge: conda-forge/mujoco-feedstock#137 . |
Yes, I think I did it! |
|
Was chatting with my colleague and we determined it's OK to just have the latest conda-forge version come in here, and we should make sure to periodically update |
|
@Tobias-Fischer the changes in RoboPlan in switching to conda-forge's |
41f7549 to
8eca1c2
Compare
|
... and we are good to go now! @Tobias-Fischer @traversaro |
…r rattler-build 0.76 - jazzy: refreshed patches and snapshot from ros-jazzy main (sea-bass's updates), py_trees 2.6.0, librealsense 2.58.3, rtabmap tests off, EGL for mujoco_ros2_control_plugins, ros2_easy_test; kinematics_interface and warehouse_ros_sqlite patches dropped (already upstream) - 40 hand-edited patches were malformed (blank context lines without the leading space, stale hunk counts, format-patch signatures, a hunk without changes), which rattler-build 0.57 tolerated and git / newer rattler-build reject. Normalized and checked against each package's release source; three were regenerated from it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| # Reminder for next full rebuild, the next build number should be 26 | ||
| build_number: 25 | ||
|
|
||
| mutex_package: | ||
| name: "ros2-distro-mutex" | ||
| version: "0.16.0" | ||
| version: "0.19.0" |
There was a problem hiding this comment.
I hadn't checked this before as I was just amending the PR, but we seem to have skipped ahead 4 build numbers and 3 mutex versions? Was this intentional or copy-pasta from other distros?
There was a problem hiding this comment.
Ah, probably copy+paste .. doesn't harm though, does it?
Summary
Validation