Full rebuild September 2026: bump ros2-distro-mutex to 0.10.0 and build_number to 20 + Sync cross-distribution Vinca package coverage - #420
Merged
Conversation
- Port pixi.toml structural changes from jazzy main: inline platform-based glibc (2.17), vinca as conda dep (rev 6aacb6f), pixi-build preview, PYTHONIOENCODING activation env; remove [system-requirements] and [pypi-dependencies] sections; add curl/go-yq/colordiff deps and conda-build-config-upstream-diff task - 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, remove Win32 long-paths registry edit, remove VINCA_CUSTOM_CMAKE_BUILD_DIR, fix duplicate git-maintenance step, move PYTHONIOENCODING to pixi.toml activation - Sync check_patches_clean_apply.py: narrow except to AttributeError, add git-cache retry on fetch failure - Update conda_build_config.yaml: graphviz→14, libxml2→2.14, libhwloc→2.13.0, add vtk 9.6.2 pin - Add new macOS-compatible patches and update existing patches for various packages (moveit, rtabmap, autoware, rviz, etc.) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The emscripten-wasm32 platform entry was incorrectly added to pixi.toml. It is a rattler-build cross-compilation target, not a pixi host platform; adding it causes pixi-build to fail resolving vinca (uv unavailable for emscripten). Remove it from platforms and keep vinca in [pypi-dependencies] (the pypi dep works fine for all non-cross-compilation platforms). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Update libprotobuf pin to 7.35.1 in vinca.yaml and conda_build_config.yaml - Add cv-bridge patch: fix OpenCV 5 version detection, remove dropped types_c.h headers, fix AccessFlag guard (#define was only skipped for opencv4, not opencv5) - Add image-geometry patch: rename calib3d→calib cmake component and opencv2/calib3d/calib3d.hpp→opencv2/calib3d.hpp for opencv5 - Convert iceoryx packages to conda-forge meta-packages (2.95.8) in pkg_additional_info.yaml; drop compiled iceoryx from ROS recipes - Skip pinocchio on macOS (coal-python 3.0.2 / libboost 1.90.* conflict) - Add patches: imu-transformer, magic-enum, motion-capture-tracking, moveit-ros-control-interface, sbg-driver, sick-scan-xd, swri-serial-util, web-video-server - Update slam-toolbox, libg2o, qt-gui-cpp patches Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…n checker - Port qt_gui_cpp/python_qt_binding/rqt_gui_cpp/rqt_image_view to PyQt6 (pyside2 has no python 3.14 build); qt_gui/rqt_py_common get analogous qt-main->qt6-main swaps. All patches target humble's own package versions, not borrowed from another distro's rosdistro_snapshot. - Port rtabmap's corelib to OpenCV5 (backport of introlab/rtabmap#1732) and disable its optional Qt-based GUI/tools/examples (WITH_QT=OFF) instead of porting them, since rtabmap_ros only needs the core SLAM library. - OpenCV5 API fixes: image-rotate, stereo-image-proc, nav2-waypoint-follower, compressed/theora image-transport, image-proc, apriltag-mit. - CMake<3.5 sweep across lanelet2, libnabo, libpointmatcher, motion-capture-tracking (including vendored deps/) and mrt-cmake-modules. - Bump hpp_fcl 3.0.2->3.0.4 and pinocchio 4.0.0->4.1.0 (libboost 1.88->1.90), remove the now-stale macOS pinocchio skip in vinca.yaml. - Fix cartographer's unpinned lua/gflags build_deps conflicting with the real conda-forge library; remove a stale clang<19 workaround on nav2_mppi_controller. - Bump vtk mutex pin to 9.7.0, mutex build_number to 21; raise glibc floor to 2.28 and refresh compiler pins in vinca_pinning.yaml. - Add check_dependency_compat.py: solves one fake package containing every non-ROS dependency plus the mutex constraints to catch pin conflicts before building anything; wire up as `pixi run check-deps` and document in AGENTS.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- mimick_vendor (linux/osx): CMake 4 removed support for the vendored
Mimick project's cmake_minimum_required(VERSION 2.8.12); pass
-DCMAKE_POLICY_VERSION_MINIMUM=3.5 to its ExternalProject_Add so it
configures anyway, as CMake's own error message recommends.
- nav2-waypoint-follower.win.patch: dropped a hunk that duplicated a
fix already applied by the base patch, which made git apply fail on
Windows CI ("could not find context").
- autoware-trajectory.win.patch: dropped a pretty_build.hpp hunk
written against a since-refactored version of the file that no
longer uses range-v3/tl::expected there, so it never applied against
the pinned release tag.
- check_patches_clean_apply.py: recipes/*/recipe.yaml only ever lists
the patches vinca resolved for whatever host platform generated it,
so a .win.patch/.osx.patch never shows up there when recipes were
rendered on Linux and this script silently never exercised it. Now
rescans patch/*.patch directly (vinca's own naming convention) and
builds one minimal test recipe per platform whose patch set differs,
so every platform-specific patch gets checked regardless of host.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- rosx-introspection.win.patch: the ros_parser.cpp hunks and the message_definition_cache.cpp #include<functional> hunk were already applied upstream in the pinned 2.3.0-1 release, so they no longer matched (one hunk hard-failed patch application on Windows CI; the functional include would have silently duplicated). Kept only the CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS knob, which is still needed and wasn't upstream, rewritten with correct context (the old hunk had a bogus line-7 header with no real context and only "worked" by luck via fuzzy matching). - testpr.yml: add a concurrency group so pushing a new commit to a PR cancels that PR's still-running check instead of piling up parallel runs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
foxglove/mcap v0.8.0's types.hpp uses uint16_t/uint64_t without
including <cstdint>, relying on a transitive include from <functional>/
<memory>/etc. GCC 15's leaner libstdc++ headers no longer provide that
transitively, so the very first error ("'uint16_t' does not name a
type") cascades into dozens of bogus "no member named ..." errors
throughout writer.hpp/writer.inl for the rest of the translation unit.
Adds patch/ros-humble-mcap-vendor.patch: a PATCH_COMMAND on the
FetchContent_Declare(mcap ...) call that applies a small nested patch
(mcap_cstdint.patch, created by the same diff) adding the missing
include to the vendored header, verified directly against the pinned
v0.8.0 tarball contents.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
get_executable_path() returns the Python interpreter as a native Windows path (backslashes). That path gets embedded verbatim into an install(CODE "execute_process(...)") string, which CMake re-parses as CMake syntax when it runs the generated cmake_install.cmake at install time — any path segment that happens to look like a backslash escape (e.g. "...\bld\..." parsing as \b) makes that second parse fail with "Invalid character escape", aborting the whole install step for every package that installs Python files via these macros (hit here via ament-cmake-test, but not specific to it). Ported the fix RoboStack/ros-rolling already carries for this same upstream ament_cmake_python bug: normalize the interpreter path to forward slashes before it's embedded, alongside humble's existing patch removing the redundant CMAKE_INSTALL_PREFIX prefix in the same functions. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as the mcap-vendor fix: DDSFilterCompoundCondition.hpp and DDSFilterValue.hpp use uint8_t/uint64_t without including <cstdint>, relying on a transitive include GCC 15's leaner libstdc++ no longer provides. Fast-DDS is a large codebase and this is the kind of bug that tends to recur across multiple files, so rather than chase it file by file across CI round-trips, force the include in for the whole target via -DCMAKE_CXX_FLAGS="-include cstdint" (unix-only: MSVC doesn't understand -include, and this bug is specific to GCC/libstdc++). Verified the platform selector resolves correctly by forcing vinca's target_platform to win-64, which correctly drops the flag entirely. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ting
The previous commit's -DCMAKE_CXX_FLAGS=-include cstdint got embedded
unquoted into the generated build_catkin.sh, so bash word-split it into
two separate argv entries at the space. CMake then saw CMAKE_CXX_FLAGS
set to just "-include" (with "cstdint" misparsed as a stray positional
source-dir argument), so every compile in the package invoked plain
"-include" with no filename — which then ate the next real flag off
the command line ("-o") as its argument, breaking even CMake's own
compiler sanity check ("-o: No such file or directory") and taking out
the whole ros-humble-fastrtps build, confirmed on both aarch64 and
linux-64 CI runs.
Embedding literal double quotes in the YAML value keeps
"-include cstdint" as one shell word after substitution. Verified with
shlex.split() against the actual regenerated build script line.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ConfigExtras.cmake requests Boost's "system" component, which no longer ships a package config in Boost 1.90 (Boost.System has been header-only for a while; 1.90 finally dropped the compatibility shim), so find_package(Boost REQUIRED ... system ...) fails outright once a package uses Boost's CONFIG mode. Confirmed on both aarch64 and linux-64 CI, both under ros-humble-moveit-core. The fix already existed for osx (ros-humble-moveit-core.osx.patch already dropped "system" from the component list) but was never ported to the other platforms, presumably because linux was still on an older libboost when that patch was written. Moved that hunk into a new platform-independent ros-humble-moveit-core.patch so every platform gets it, and dropped the now-redundant copy from the osx patch (applying it twice would fail: the "any" patch already removes the same line first). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same class of bug as the mcap-vendor and fastrtps fixes: RPS98's
multirotor_simulator (fetched via FetchContent) uses assert() inside
template functions in model.hpp without including <cassert>. GCC 15's
-Wtemplate-body flags this as an error ("no arguments to 'assert' that
depend on a template parameter, so a declaration ... must be
available") since it can no longer assume the include arrived
transitively. Forces the include via CMAKE_CXX_FLAGS, unix-only, using
the same quoting fixed in 7dac607 so the flag survives the generated
build script's shell word-splitting intact.
Verified the if/then selector and quoting directly against vinca's own
config loader (this package isn't in the locally-generated recipes/
tree, same gap check_patches_clean_apply.py's cross-platform rework
exists to close for patches).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The "Save build cache" and "Upload build cache as artifact" steps gate on steps.build-recipes.outcome, but the "Build recipes" step had no id: build-recipes set — so that context reference was always empty, and always() && (... == 'success' || ... == 'failure' || ... == 'cancelled') was always false. The cache was never being saved at all, regardless of outcome; this isn't specific to jobs cut short by the concurrency cancellation added in a915306, it just makes the effect more visible (every superseded run now rebuilds everything from scratch instead of resuming from a same-PR cache that was never written in the first place). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
python_qt_binding's SIP5+ pyproject.toml-based build path names the sip binding "lib@PROJECT_NAME@" (see pyproject.toml.in) so the importable Python module keeps its existing "lib"-prefixed name (e.g. libqt_gui_cpp_sip, used elsewhere in the codebase). On Unix, qmake's own shared-library convention then prefixes "lib" a second time onto that already-"lib"-prefixed target, producing "liblibqt_gui_cpp_sip.so" — but the custom_command declares its OUTPUT (and everything downstream, including qt_gui_cpp's own install() step) as the single-"lib" name. CI failed with "file INSTALL cannot find .../qt_gui_cpp_sip/libqt_gui_cpp_sip.so" for exactly this reason. Rather than rename the sip binding (which would change the Python import name other code relies on), copy the double-lib output to the expected single-lib name right after the pip install step. Guarded to Unix only: qmake doesn't add its own "lib" prefix on Windows, so the name it produces there already matches what's expected. Note: the added hunk had to match this patch file's existing `diff -ruN` (no `index` line) format exactly — an initial attempt using `git diff`'s `diff --git`/`index` style, appended as a second section for the same file, made rattler-build's patch application fail on an unrelated, earlier hunk in the same file with a confusing error. Consolidated into one correctly-formatted, contiguous section instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Amends bc1a83b, which diagnosed the wrong problem: the double-"lib" named artifact liblibqt_gui_cpp_sip.so never reaches the pip install target directory at all — PyQt-builder's own packaging step already renames it before wheeling it up. The actual mismatch is that the installed file carries a Python ABI tag (e.g. libqt_gui_cpp_sip.cpython-314-aarch64-linux-gnu.so), which doesn't match this macro's plain lib${PROJECT_NAME}${SUFFIX} expectation. Confirmed directly from the CI log's cp/qmake -install lines showing the actual chain of renames. Replaces the previous (ineffective, since its source file never existed) copy step with a glob for any lib${PROJECT_NAME}* variant PyQt-builder actually produced and copies that to the expected name — verified against a simulated ABI-tagged file locally. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rmw_fastrtps_cpp is not itself skipped on Windows, but its hard dependency rosidl_typesupport_fastrtps_c/cpp was — both skip-listed in packages_skip_by_deps (so no recipe gets generated) and stripped from dependency lists in packages_remove_from_deps. Its CMakeLists.txt unconditionally does find_package(rosidl_typesupport_fastrtps_c REQUIRED), so this guaranteed rmw_fastrtps_cpp could never configure successfully on Windows, confirmed by CI: "Could not find a package configuration file provided by rosidl_typesupport_fastrtps_c". We've likely never hit this until now because earlier Windows blockers (ament-cmake-python, mimick_vendor's CMake4 issue, etc.) kept CI from ever reaching this package. Unlike the neighboring ros_ign_image exclusion (which cites issue #68), these two carried no explanation, and none of jazzy/kilted/lyrical/rolling's vinca.yaml exclude them on Windows at all — this looks like a stale, humble-only workaround rather than a real platform limitation. Removing it so the next Windows run can show whether it actually builds there. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
9c968b2's fix was logically correct but still failed identically on CI (both aarch64 and, before that, on a wrong "double lib" theory in bc1a83b). The likely culprit: the inline `python -c "import glob, os, shutil; want = '...'; hits = [...]; ..."` command had multiple unescaped semicolons, which CMake's COMMAND argument handling can treat as list separators — silently truncating or mangling the script CMake actually hands to ninja, with no error surfacing since a truncated "import glob, os, shutil" alone is valid Python that exits 0 having copied nothing. That matches what we saw: the build proceeds past this step (ninja doesn't verify a custom_command's declared OUTPUT actually appeared) all the way to the later install() step, which is where the missing file finally surfaces. Sidesteps the whole class of CMake-string-escaping risk by moving the fixup into its own script, cmake/fixup_sip_module_name.py (mirroring this same file's existing cmake/sip_configure.py convention), invoked with plain positional arguments instead of an inline -c string. Registered in CMakeLists.txt's install(FILES ...) list alongside the other cmake/ helpers so it's actually present in the installed share/python_qt_binding/cmake/ directory qt_gui_cpp reads __PYTHON_QT_BINDING_SIP_HELPER_DIR from. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Explains why all three prior attempts (bc1a83b, 9c968b2, 801822b) at fixing qt_gui_cpp_sip's install failure had zero effect on CI despite each being progressively more correct: CI logs show "Skipping build for ros-humble-python-qt-binding-1.1.3-np2py314haae1a83_20" every time — rattler-build's --skip-existing reuses whatever build already exists under a given (name, version, build_string) in conda-forge/ robostack-staging regardless of patch content, since that identity hash isn't derived from patch state. An old, already-published build (predating any of this session's fixes) was being reused on every run, so qt_gui_cpp kept linking against the same broken sip_helper.cmake no matter what the patch file said. Bumping build_number forces rattler-build to treat this as a distinct, not-yet-built artifact. Should be reverted once the fixed build has actually landed in robostack-staging, to avoid carrying a permanent build number bump for what's really a one-time cache-bust. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…artifact" This reverts commit 4bde094.
- dependencies.yaml: trim long-prose comments to one line each. - testpr.yml: drop one-off package cache-purge lines (leave a commented template instead), shorten remaining comments. - rosdistro_additional_recipes.yaml: remove leftover wasm/emscripten entries (rmw_wasm_cpp, test_wasm, wasm_cpp) from the emscripten removal. - vinca_pinning.yaml: drop the channel_sources/channel_targets null override; re-render conda_build_config.yaml to match. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Removing this in the last commit broke the build: rattler-build build
commands already pass channels via -c conda-forge -c robostack-staging,
and rattler-build hard-errors if channel_sources is also set ("channel_sources
and channels cannot both be set at the same time"). Reproduced locally with
a minimal recipe and confirmed the fix (render-only succeeds again after
restoring the override). Keep the override, just with a one-line comment
this time instead of the original long-prose version.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…mera-class bug) Pre-emptive port of the same fix landing on jazzy/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 humble's own (older) urg_c release tag too. 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>
vinca-sort-vinca-lists only treats a whole-line comment as a block separator; a multi-line comment block gets scrambled across items once the surrounding lists get re-sorted. Condense every remaining multi-line comment to one line (or an inline trailing comment where it's attached to a single item), preserving the handful that exist specifically to keep adjacent if/then blocks from being pooled together by the sorter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ament_cmake, ros_environment, and ros_workspace were each listed twice (once in the core-packages list, once in the general alphabetical list). Harmless but confusing; drop the redundant copy. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Two compounding bugs in vinca-sort-vinca-lists silently defeated sorting across large parts of this file: 1. Any standalone " #" comment sitting between plain (unconditional) items starts a bogus internal accumulator that never resets. Every line after it -- including genuinely unconditional items -- gets swept into that accumulator instead of the real simple-items list. 2. Within that accumulator, only 6-space "then:"-indented lines get re-sorted (RE_THEN_ITEM requires exact 6-space indent); anything at 2-space just gets carried through verbatim and repositioned to the end of the file, unsorted. Together these meant: from the first stray comment or if-block onward, no later unconditional item was ever actually re-sorted -- verified empirically by deliberately introducing disorder into a "protected" region and confirming `sort --check` still reported OK. Fix: removed all standalone comments between plain items (folded the substantive ones into inline trailing comments on the item they describe, or the closest still-relevant one; dropped purely decorative section headers and stale disabled-package notes that no longer correspond to anything real); merged the two unconditional blocks (one before the if-blocks, one trailing after) into one, followed by all if-blocks, matching the fix already applied to rolling. 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
Author
|
@traversaro - human Tobi here. I think this is ready for review. It's a much bigger PR than I had anticipated. I'm also thinking that for the next round, I'd be keen to bootstrap most of the repositories from a shared CI template, so we can get rid of most duplicated files. |
Same gap as ros-rolling/ros-jazzy: liboctomap-dev shows up in Unsatisfied dependencies without this mapping. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ion)
The prior "Fix Japanese comments in urg-c package patch" cherry-pick
(rolling) only addressed backslash getting corrupted to the yen sign
(¥); humble's copy of 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, "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 (and the same bug independently confirmed to be the
root cause of nearly every non-infra CI failure across humble and
jazzy right now). 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/humble/urg_c/1.0.4001-4), 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>
Open3D's own CMake config calls find_dependency(TBB), but conda-forge's open3d package only depends on the runtime "tbb" lib, not "tbb-devel" (which provides TBBConfig.cmake) -- without it, find_package(Open3D) fails with "Could not find a package configuration file provided by TBB". Confirmed by creating a real environment with open3d + tbb-devel and successfully running find_package(Open3D REQUIRED); without tbb-devel the same configure fails with the exact CI error. Unrelated to the urg-c/roboplan/octomap work in this branch -- a separate pre-existing gap that surfaced once the broader rebuild scope reached this recipe for the first time in a while. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…pher dep removal Windows Defender exclusions/real-time-scanning-disable are already handled by GitHub's hosted runner image setup (Configure-WindowsDefender.ps1 in actions/runner-images), so this step was redundant. cartographer_ros can depend on both ros2-cartographer and cartographer 2.* without conflict; the remove_host/remove_run wasn't needed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
traversaro
reviewed
Sep 22, 2026
Comment on lines
+9
to
+12
| cartographer: | ||
| # Dummy package; drop unpinned lua/gflags, they conflict with the real cartographer's pins. | ||
| remove_host: ["lua", "gflags"] | ||
| remove_run: ["lua", "gflags"] |
Member
There was a problem hiding this comment.
I see this more and more, it is still not clear to me how unpinned deps can conflict with pinned ones.
traversaro
approved these changes
Sep 22, 2026
traversaro
left a comment
traversaro
left a comment
Member
There was a problem hiding this comment.
Ok for me, given the size of the PR I did not reviewed everything in detail. I would wait for ROSCon 2026 to end, and then I would merge, then we can iterate with more fixes.
…odules Port of RoboStack/ros-rolling#51 (without its pkg_additional_info.yaml build-number bumps): stop exporting the lib<pkg>__rosidl_generator_py library, which has unresolved CPython symbols, to C++ consumers of interface packages. The generated conversion code is compiled as an OBJECT library into each Python extension module, and conversion functions of nested types from other packages are looked up from those packages' Python message classes (_CONVERT_FROM_PY/_CONVERT_TO_PY). Adds the std_msgs C++-consumer regression test and a CI cache eviction for std_msgs so it is rebuilt and tested. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s rebuilt rosidl_generator_py's patch changed, but its build string didn't, so --skip-existing would reuse the cached, unpatched build (and with it rosidl_core_generators/rosidl_default_generators), and std_msgs would be rebuilt with the old generator. Evict them alongside std_msgs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Backport of upstream's `AND NOT APPLE` guard (already in jazzy's rcutils 6.x). On macOS the check finds conda-forge libgcc's libatomic via -L$PREFIX/lib, so rcutils exported `atomic` in its link interface; any CMake consumer then needs -L$PREFIX/lib to link, which the std_msgs C++-consumer test deliberately clears (ld: library not found for -latomic). Also evict rcutils from the PR cache so it is rebuilt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This comment was marked as resolved.
This comment was marked as resolved.
Member
|
As for RoboStack/ros-rolling#41 (comment), I would not include directly the changes in RoboStack/ros-rolling#51 . |
Merged
…RGETS Mirror the simplified fix from RoboStack/ros-rolling#51 (be116c63), replacing the earlier approach that compiled the Python bindings into the extension modules. The library is again a shared library linked through <pkg>_TARGETS__rosidl_generator_py, but it is exported via an installed export set included from a config extras file instead of ament_export_targets(), so it no longer ends up in <pkg>_TARGETS and C/C++ consumers of interface packages don't link it. It links Python::Module rather than libpython, since only Python extension modules link it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Resolve the vinca.yaml conflict with #423 and 428f229: this branch dropped the wasm32 blocks and folded "not wasm32" into the unconditional list, so add #423's zed_description there. 428f229 only removed a blank line in a block that no longer exists here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
Author
Done |
…tches Sync with the identical version already on jazzy's and rolling's cross-distro-sync branches: only count artifacts built with the current build_number (respecting the mutex's own build_number and per-package overrides from pkg_additional_info.yaml), ignore the throwaway *-check-patches* artifacts from check_patches_clean_apply.py, pick a deterministic display name for dual-named packages, and report missing recipes out of distinct packages. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Member
|
@Tobias-Fischer @wolfv @sea-bass @wep21 @mini-1235 @ruben-arts @baszalmstra @Timple @PeterMitrano @gftabor if there are no objections I plan to merge this PR this (European) morning. |
mini-1235
reviewed
Sep 29, 2026
mini-1235
left a comment
mini-1235
left a comment
There was a problem hiding this comment.
I took a quick look and left a comment (but not blocking this PR)
| go-yq = "*" | ||
| colordiff = "*" | ||
|
|
||
| [pypi-dependencies] |
There was a problem hiding this comment.
I think this can be reverted now (?)
Member
There was a problem hiding this comment.
Apparently this is a bit anomalous full rebuild, as it refresh the pinning, but no the snapshot, see https://github.com/RoboStack/ros-humble/blob/codex/cross-distro-sync/rosdistro_snapshot.yaml . I think we can merge as it is, and update to latest vinca and refresh the snapshot in a follow up full rebuild.
traversaro
changed the title
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
Build note
The RTAB-Map patch itself applies cleanly; the package build is currently blocked on macOS by the existing unconditional libgl-devel recipe dependency. This PR does not alter that unrelated platform policy.