xref:

• Fix ROS 2 build when ZeroMQ or SQlite3 include are not in the default include path BehaviorTree/BehaviorTree.CPP#911
• Avoid to include windows.h in realtime_helpers.hpp ros-controls/realtime_tools#255
• Add missing link of mock_components to hardware_interface ros-controls/ros2_control#1992
• Add Windows support ros/filters#81
• Add Windows support ros/diagnostics#426
• Remove custom logic to skip configuration of gripper_controllers on Windows or macOS ros-controls/ros2_controllers#1471
• Remove use of boost from polygon_filter ros-perception/laser_filters#209
• Define _USE_MATH_DEFINES in joint_soft_limiter.cpp to ensure that M_PI is defined ros-controls/ros2_control#2001
• Add support for Windows ros-perception/perception_pcl#474
• stomp: Fix passing different types to std::min in cost_functions.hpp moveit/moveit2#3244
• Explicit convert from std::filesystem::path to std::string for Windows compatibility moveit/moveit2#3249

Ok, I had to skip plotjuggler and gtsam as they were not building, but moveit and navigation are now building ok (locally).

Side-remark: I think the snapshot should be a config parameter in the vinca.yaml, not a command line argument. What do you think?

More annoyingly it doesn't seem to work properly ;)

Side-remark: I think the snapshot should be a config parameter in the vinca.yaml, not a command line argument. What do you think?

Ok!

Side-remark: I think the snapshot should be a config parameter in the vinca.yaml, not a command line argument. What do you think?

Ok!

Done in RoboStack/vinca#70 . The pixi's PR environment is already using RoboStack/vinca#70 .

This PR also fixes prefix-dev/pixi#2910, as done for ros-humble in RoboStack/ros-humble#244 .

So I just realised: the issue with having a single pkg_additional_info.yaml is that the "default" build numbers vary between different platforms, and we are now rebuilding new packages for some platforms. Not sure what the best way forward is .. the easiest would be to have a separate section within each vinca.yaml that contains the build number bumps, but I am not sure how clean this is. Or we have to make sure to have the build_numbers in sync in the future. Note that this is a bigger problem for e.g. noetic where the build_numbers vary a lot more than here.

So I just realised: the issue with having a single pkg_additional_info.yaml is that the "default" build numbers vary between different platforms, and we are now rebuilding new packages for some platforms. Not sure what the best way forward is .. the easiest would be to have a separate section within each vinca.yaml that contains the build number bumps, but I am not sure how clean this is. Or we have to make sure to have the build_numbers in sync in the future. Note that this is a bigger problem for e.g. noetic where the build_numbers vary a lot more than here.

Yes, that is the reason why I used an high number for build number on humble, and add a comment as remainder for the next build number. My idea was to align the build numbers in the next rebuild.

The CI seems happy.

Amazing work @traversaro thanks a lot!