Preparing for Dashing sync and patch release: 2020-07-20

We are preparing another Dashing sync and patch release.

There are currently no regressions in amd64 and arm64, (one regression is not a release blocker) and a few packages ready to sync.

Changes in the ROS 2 core since the last patch release are visible on the project board. Some of these changes have previously been included in syncs of the debian packages.

1 Like

Are you still accepting PRs to rosdistro for this sync?

Yes, we’ll accept PRs for this sync until the end of this week.

1 Like

Several regressions have been identified and are being tracked.

For some of the regressions it is possible that reverting to an earlier release will resolve the issue:

However a dependency of the serial_driver package has been removed from Dashing so it is no longer buildable. I plan to allow the package to be removed in this sync https://github.com/ros-drivers/transport_drivers/issues/14

To allow these regressions time to be addressed I plan to run the sync on Thursday rather than today. If you notice any other regressions during testing please open issues and note them here.

1 Like

https://github.com/ros/rosdistro/pull/25814 has been opened which proposes removing librealsense from Dashing entirely.

Issue with transport_drivers is being addressed.

1 Like

We’ve reverted to working releases for librealsense and behaviortree_cpp_v3 and are waiting on the fix for transport_drivers. I think at this point it’s fair to expect the sync to occur Tuesday next week rather than today.

1 Like

With the transport_drivers release and the revert to earlier versions of librealsense and behaviortree_cpp_v3 the only regressions are the source packages for the broken versions of those packages being reset back to their working versions along side the binaries.

With that in mind the sync should happen tomorrow morning with the patch release binaries being made available later that day.

As ever, if anyone using Dashing from testing identifies a problem which should prevent the sync please open an issue and link it here.

Windows Debug builds have had a new regression caused by a bump in the cmake version on that platform. It is resolved by this backport: https://github.com/ros/kdl_parser/pull/41

Thanks @mjcarroll for the fix and timely backport. The bugfix release has been merged and is building now on the build farm and another CI round for the release repos file is underway. If things look good on the build farm and in CI before I wrap up for the day I’ll start the sync tonight, however it’s more likely that the sync and patch release will come tomorrow.

The sync is out. With the patch release done my hope is that future syncs can get back on the two-week cadence. So we’ll plan for the next Dashing sync to be 2020-08-04.

1 Like

Something seems to have gone wrong with the sync of specific packages to https://packages.ros2.org, specifically with Dashing.

If I look at the package index at http://packages.ros.org/ros2/ubuntu/dists/bionic/main/binary-amd64/Packages and find the package ros-dashing-ament-cmake-export-definitions, it says that the version that’s available on the repo is 0.7.5. However, when I attempt to download/install that package from apt on Ubuntu Bionic, I get a 404 error. And, indeed, when I navigate to http://packages.ros.org/ros2/ubuntu/pool/main/r/ros-ardent-ament-cmake-export-definitions/, where the package should be, the only version shown is 0.4.0 (this is using the Oregon State University OSL mirror).

Edit: This is also the case for (at least) several ament- packages, several rosidl- packages, and ros-dashing-rmw.

Any idea what might have happened?

It looks like there are synchronization issues between the different replicas of packages.ros.org. We are investigating the issue and will escalate with our provider if necessary.

1 Like

Thanks for looking into it!

We were able to trigger an additional sync which has propagated out to all replicas. Before I can “close” this particular incident I need to verify that the Dashing snapshot for yesterday’s sync was made from an intact replica. I’ll update here when I find that out.

Sounds good. The replica that I’m using seems to be OK as I can now pull the correct package versions with apt. Thanks!

In fact the snapshot failed because it hit an inconsistent replica. I’ve just retriggered the snapshot process so once it is live it will definitely be valid.

1 Like