Full Rebuild September 2026 + Sync cross-distribution Vinca package coverage - #271
Open
Tobias-Fischer wants to merge 101 commits into
Open
Tobias-Fischer wants to merge 101 commits into
Tobias-Fischer wants to merge 101 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>
RoboStack/vinca#156 fixes the real root cause of today's persistent, non-transient "Failed to fetch package.xml" failures: vinca's raw.githubusercontent.com URLs for ros2-gbp release tags (e.g. "release/jazzy/controller_interface/4.47.0-1") use the short <ref> form, which is ambiguous about where the slash-containing ref ends and the path begins, and resolves inconsistently across CDN edges -- confirmed the exact same URL 404s from GitHub Actions runners while working fine everywhere else (curl, a direct git clone of the tag). This was mistaken for a rate-limit issue in a previous commit; adding GITHUB_TOKEN auth didn't fix it because the problem was never about authentication. Pin to the fix commit directly (verified it contains this line's prior HEAD as an ancestor, so nothing else changes) rather than wait on review/merge. Revert to the plain RoboStack/vinca.git rev once that PR merges. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous commit pinned to a fork commit based on current RoboStack/vinca master, which includes the newer rosdistro-cache-snapshot feature (PR #146). Our already-generated rosdistro_snapshot.yaml predates that machinery and isn't compatible with it, causing a new failure. Re-pin to RoboStack/vinca@1f1dca5 (the last commit before that feature landed) with the raw.githubusercontent.com tag-URL ambiguity fix (RoboStack/vinca#156) cherry-picked on top, so we keep the actual fix without pulling in the incompatible snapshot changes. Per instruction: do not regenerate rosdistro_snapshot.yaml itself, since that would pull in new package versions and a fresh round of patches. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Now that recipe generation actually succeeds (previous commit), the build gets far enough to hit vinca-gha's generated linux.yml size check for the first time this session: "Generated workflow linux.yml is 659.0 KiB, exceeding the 500 KiB limit." Same fix already applied on humble -- batch_size defaults to 5, bump to 25 to reduce per-job YAML overhead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fix as humble: win-64 jobs have repeatedly gone completely silent for 10-20+ minutes during rattler-build's recipe enumeration (a pure local YAML-parse, zero network calls) -- exactly the I/O pattern real-time Defender scanning is known to silently stall on GH Actions Windows runners. Repeated cancel+retry cycles kept landing on the identical "Finding outputs from recipe" spot rather than clearing anything up. A byte-level scan of the whole libg2o source tree ruled out the other known cause of a deterministic win-64 hang (an invalid UTF-8 byte, as previously found and fixed for avt_vimba_camera on rolling). Exclude the checkout and C:\bld build directories from scanning before any heavy I/O begins. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Now that the Defender exclusion is letting win-64 jobs actually get through recipe generation and into real building, a genuine failure surfaced: nav2_rviz_plugins' find_package(nav2_route) failed against a ~38KB cached ros2-nav2-route artifact missing its installed cmake config -- the same recurring corruption signature as moveit-core/nav2-behavior-tree earlier, almost certainly from one of today's many win-64 job cancellations catching a cache-save mid-write. Purge it so it rebuilds clean. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…mera-class bug) Same fix as rolling: urg_c (Hokuyo laser rangefinder driver, pulled in transitively via urg_node) ships all of its source in Shift-JIS encoding, not UTF-8. Compiling urg_sensor.h triggers -Winvalid-utf8 on its Japanese comments; the compiler echoes the raw invalid bytes into the diagnostic, and rattler-build's output reader hangs instead of erroring -- confirmed live on rolling's osx-64, sitting silently at the exact same source line for 9.5+ minutes, matching the deterministic hang signature from the earlier avt_vimba_camera fix. Converts all 35 affected files from Shift-JIS to UTF-8 (comment-only, no functional change); verified this exact patch applies cleanly against jazzy's own urg_c release tag (identical to rolling's). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same recurring pattern as moveit-core/nav2-route: ros2-polygon-msgs (~24KB) missing its installed cmake config, causing polygon_utils' find_package(polygon_msgs) to fail. Almost certainly another casualty of this session's many win-64 job cancellations. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Standardize on humble's post-review layout: a separate sort-check job, pinned setup-pixi/pixi versions, the 3-attempt recipe-generation retry loop, short single-line comments, and no per-repo one-off cache-purge entries (the underlying corrupted/stale artifacts have long since been superseded by newer cache saves). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two win-64 hang-mitigation experiments, scoped to jazzy where the hangs have been most persistent: bump the runner image (newer image, reworked storage/virtualization) and layer disabling Defender's real-time monitoring outright on top of the existing path exclusions (wrapped so a hosted runner blocking this via tamper protection doesn't fail the job). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…isabled windows-2025 doesn't ship the VS2022 toolchain our build hardcodes (rattler-build's generator is "Visual Studio 17 2022"), so every recipe failed immediately with "could not find any instance of Visual Studio" -- what looked like a hang was actually many small per-recipe failures the log hadn't caught up displaying yet. Keep the Defender real-time-monitoring-disable experiment, which is runner-image-independent. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same cleanup as humble: rename the 13 remaining ros2-*.patch files to the ros-jazzy- prefix used by the other 212 patches (vinca discovers either prefix identically via add_package_name_variants, so this is purely cosmetic -- verified with pixi run check-patches, all 133 recipes still apply cleanly). Shorten dependencies.yaml comments to one line each. Condense vinca.yaml's remaining multi-line comment blocks to a single line -- vinca-sort-vinca-lists only treats a whole-line comment as a block separator, so a multi-line block gets scrambled across items once the list re-sorts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Listed twice (once unconditionally, once under the RoboPlan section). Harmless but confusing; drop the redundant copy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same fix as humble/rolling: standalone comments between plain items and a trailing unconditional block placed after an if-block both defeat vinca-sort-vinca-lists silently (its internal accumulator never resets once triggered, and only exact 6-space "then:" items get re-sorted inside it -- verified by confirming irobot_create_* was sitting unsorted in this exact trap). Folded the substantive standalone comments into inline trailing comments on the item they describe (or dropped one that didn't describe anything specific); merged the two unconditional blocks into one before all if-blocks. Verified zero behavior change: evaluated selectors for linux-64, win-64, and osx-64 against the prior committed version and confirmed identical resulting package sets on all three before and after. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
@Tobias-Fischer we just discovered an issue with RoboPlan packages ABI stability (see open-planning/roboplan-ros#68 and RoboStack/ros-lyrical#47 for more details) Would it be possible to blow away all the Otherwise I can always just do a follow-on with a partial rebuild... up to you On a separate note, Jazzy just had a sync yesterday (September 11, 2026), so I don't know if we'll need to regenerate a snapshot here anyhow... |
Same gap as ros-rolling: liboctomap-dev shows up in Unsatisfied dependencies without this mapping. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
roboplan_* just switched from dummy run-deps-only metapackages to real source builds. The PR-scoped build cache still holds artifacts from when these were dummies, and --skip-existing would happily reuse them, silently skipping the real build/test this change is meant to exercise. Evict them so the next testpr run actually rebuilds them from source. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
|
Request: Don't yet bring in the RoboPlan commits. I'm going to be cutting a new release (hopefully) today that fixes ABI incompatibility between the dummy conda packages and the "true" ROS ones, rather than change how they are built. But if this branch will stick around unmerged for a bit, I can make the modifications myself when the time comes. |
Contributor
Author
|
Ok no problem @sea-bass. Does that mean we’ll go back to the dummy packages? |
…ion)
The prior "Fix Japanese comments in urg-c package patch" cherry-pick
only addressed backslash getting corrupted to the yen sign (¥); this
patch's raw content went through the same JIS X 0201/ASCII encoding
mismatch for tilde (~) as well, corrupted to U+203E OVERLINE (‾).
This wasn't just cosmetic: it silently corrupted a genuine unchanged
code line in urg_sensor.c's diff context/replacement,
"value &= ~0x3f;" -> "value &= ‾0x3f;", which is a hard C syntax error
("stray '\342' in program") -- confirmed as the actual cause of
ros2-urg-c's build failure in CI. check-patches never caught this
since it only validates that a patch applies, not that the result
compiles.
Verified by cloning the real urg_c source (release/jazzy/urg_c/1.0.4001-6),
applying the patch, and compiling every affected .c file directly --
0 errors (remaining unrelated errors are from platform-specific files
missing headers in this minimal ad-hoc compile, not the codebase).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
Exactly! |
Resolvo mutex-misattribution bug: solving irobot_create_gz_plugins' environment picks ros2-gz-gui-vendor/ros2-ros-gz's stale remotely- published build (mutex 0.16.*, long since removed from the channel -- no candidates exist) instead of the current one (mutex 0.17.*, matching this repo's mutex_package version), even though a matching-mutex build of both already exists (confirmed built earlier in the very same CI job). Same failure mode and same fix pattern as the cartographer_ros/ yasmin_pcl pcl-conversions pin: pin the two unconstrained bare deps to an exact version + build_number-suffixed build string so resolvo can't consider the orphaned old build. Unrelated to the urg-c/roboplan/octomap work in this branch -- a separate pre-existing gap in the gz-vendor family that surfaced once the broader rebuild scope reached irobot_create_gz_plugins for the first time in a while. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…rrent build" This reverts commit daf8556.
moveit_ros_warehouse's find_package(warehouse_ros) fails on win-64 with "Could not find a package configuration file provided by warehouse_ros", even though ros2-warehouse-ros is a declared host dep -- the build log shows it being skipped (reused from the PR-scoped build cache) rather than rebuilt, at the current build_number (23). Likely corrupted by an interrupted/cancelled run earlier this session (this branch's win-64 jobs were cancelled and rerun several times). Same failure mode as ros-rolling's existing moveit_ros_visualization cache-eviction entry; confirmed win-64-specific (the other four platforms build ros2-warehouse-ros/moveit_ros_warehouse without this error). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
irobot_create_gz_plugins fails to solve because resolvo picks a stale ros2-gz-gui-vendor/ros2-ros-gz build requiring the long-removed ros2-distro-mutex 0.16.* instead of the current 0.17.* one. The freshly-built 0.17 packages already exist in the same run's output channel, so the stale 0.16 copies most likely came from this PR's own GH Actions build cache, persisted from before this repo's mutex bump. Evict them so only the current build remains -- reverts the earlier exact-pin workaround (which pinned around the symptom rather than the actual stale-cache cause) in favor of just rebuilding the vendor packages fresh, matching the roboplan_* and warehouse_ros cache evictions above. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The ros2-gz-gui-vendor/ros2-ros-gz eviction alone didn't fix irobot_create_gz_plugins: ros2-gz-common-vendor (which pulls in a bare, unconstrained ffmpeg host dep from its own package.xml) was still being skipped/reused from a build that predates this repo's conda_build_config.yaml bump to libopencv 5.0.0 / libprotobuf 7.35.1 / ffmpeg 9. A fully protobuf-7-compatible chain already exists on conda-forge today (libopencv 5.0.0 -> ffmpeg 9.0.x -> libopenvino 2026.3.1 -> libprotobuf 7.35.1, confirmed via direct channel queries) -- gz-common-vendor just needed to actually rebuild against the current variant config instead of reusing its stale artifact. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…traints The actual, distro-wide root cause of irobot_create_gz_plugins (and likely other libopencv/ffmpeg/gz-vendor consumers) failing to solve: libopencv/ffmpeg builds needing libprotobuf 6.x still coexist in the channel alongside protobuf-7-compatible ones, and resolvo doesn't reliably pick the compatible combination on its own even though one exists (confirmed directly: libopencv 5.0.0 -> ffmpeg 9.0.x -> libopenvino 2026.3.1 -> libprotobuf 7.35.1 is already published). Pinning libopenvino-tensorflow-frontend >=2026.3.1 (the actual carrier of protobuf-7 support in this chain) as a mutex run_constraint forces this centrally for every consumer, the same mechanism already used for libboost/pcl/gazebo/libprotobuf -- rather than pinning each affected downstream package's exact build individually as new ones are discovered (reverted approach from earlier today). Version bump 0.17.0 -> 0.18.0 forces a fresh mutex publish so this constraint actually takes effect, per the established precedent for run_constraints changes in this repo's history. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…, bump build_number for full rebuild Same corrections as ros-rolling: 1. The >=2026.3.1 floor was too strict: >=2026.3.0 already carries libprotobuf 7.35 support (verified directly), and on osx-arm64/win-64 today's only published protobuf-7-compatible libopencv build pins ffmpeg to a version that requires exactly 2026.3.0.x, which the >=2026.3.1 floor excluded entirely -- confirmed via direct dry-run solves per-platform. 2. Also pin libopencv/py-opencv >=5.0.0 directly: resolvo has repeatedly failed to propagate the openvino constraint transitively through ffmpeg -> libopencv on its own in the actual CI runs, even though a compatible combination exists. 3. Bumped build_number 23->24: mutex version alone doesn't force a rebuild of unrelated packages like ros2-ros-workspace that still reference the old ros2-distro-mutex 0.17.* and don't otherwise change. A full build_number bump forces every package to republish against the current mutex version, matching this repo's own historical precedent for run_constraints changes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
My first attempt at this fix (aa16de5, mutex version 0.18.0, run_constraints pinning only libopenvino-tensorflow-frontend >=2026.3.1) got far enough in its CI run (35490729546) to actually publish a real ros2-distro-mutex-0.18.0 build before I corrected the constraint in the very next commit (5132499) -- which reused the SAME version number "0.18.0" for the corrected content. Since packages match the mutex by "0.18.* jazzy_*" (not by build string), resolvo could pick EITHER the old wrong build or the new correct one, and the current full-rebuild run (35492632746) hit exactly this ambiguity: the conflict tree showed two different "would constrain" outputs for the same "ros2-distro-mutex 0.18.0" label, one with the old too-strict >=2026.3.1-only constraint and one with the corrected >=2026.3.0 + libopencv/py-opencv constraints. Bumping the version to a genuinely new number (0.19.0) that was never published under any prior content eliminates the ambiguity. Also bumping build_number again (24->25): packages already built in the cancelled run under build_number 24 still embed a dependency on the old "0.18.*" mutex and would otherwise be wrongly skip-cached as already-built once vinca regenerates them referencing 0.19.* instead. Lesson for next time: bump the mutex version on every actual change to run_constraints content, including quick follow-up corrections to a same-day fix -- never reuse a version number across two different sets of constraint content, even briefly. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation