search

ros / rosdistro

This repo maintains a lists of repositories for each ROS distribution
Other
926 stars 2.55k forks source link

ROS Noetic November 2020 Regressions #27401

Closed sloretz closed 3 years ago

sloretz commented 3 years ago

There are a lot of regressions in Noetic, and it's been a while since it had a sync. I think the following would get back to a sync'able state:

Ubuntu Focal amd64

Ubuntu Focal arm64

Ubuntu Focal armhf

Debian Buster amd64

Debian Buster arm64

bmagyar commented 3 years ago

I probably missed the announcement that added Debian builds to the requirements for a distro release. I'd be happy to run pre-release tests for debian too, could you please point me to a script generator for that?

tylerjw commented 3 years ago

I can look into why fcl isn't building. I was actually about to bloom moveit again yesterday (1.1.2) for Noetic but was stopped by a regression inside moveit.

If it makes sense to get a sync done in the short term, you can go ahead and back out what version moveit is at. I didn't realize there was anything wrong with fcl.

I also have another package that keeps failing on buster that I can't seem to figure out. I might just make a PR to remove it from rosdisyro for Noetic.

rhaschke commented 3 years ago

Hi @sloretz, looking into the failing FCL build for ARM architectures, I noticed that your update to disable sse optimizations isn't yet applied: 

00:57:18 cd /tmp/binarydeb/ros-noetic-fcl-0.6.1/obj-aarch64-linux-gnu/src && /usr/lib/ccache/c++  -Dfcl_EXPORTS -I/tmp/binarydeb/ros-noetic-fcl-0.6.1/obj-aarch64-linux-gnu/include -I/tmp/binarydeb/ros-noetic-fcl-0.6.1/include -isystem /usr/include/eigen3 -isystem /opt/ros/noetic/include  -g -O2 -fdebug-prefix-map=/tmp/binarydeb/ros-noetic-fcl-0.6.1=. -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC   -std=c++11 -W -Wall -Wextra -Wpedantic -fPIC -fvisibility=hidden -mfpmath=sse -msse -msse2 -msse3 -mssse3 -o CMakeFiles/fcl.dir/broadphase/broadphase_SSaP.cpp.o -c /tmp/binarydeb/ros-noetic-fcl-0.6.1/src/broadphase/broadphase_SSaP.cpp
00:57:18 c++: error: unrecognized command line option ‘-mfpmath=sse’
00:57:18 c++: error: unrecognized command line option ‘-msse’
00:57:18 c++: error: unrecognized command line option ‘-msse2’
00:57:18 c++: error: unrecognized command line option ‘-msse3’
00:57:18 c++: error: unrecognized command line option ‘-mssse3’

I don't yet understand why. Did I make a mistake in the release, such that the release doesn't comprise your commits?

rhaschke commented 3 years ago

I pulled the debian source package and indeed it doesn't comprise the latest release state. Looking into the debian source build job, I noticed that the correct source branch is checked out: Invoking 'git clone --branch debian/ros-noetic-fcl_0.6.1-2_focal --depth 1 --no-single-branch https://github.com/ros-gbp/fcl-release.git /tmp/sourcedeb/source'

but subsequently, also an older tarball is downloaded: Downloaded original tarball 'http://repositories.ros.org/ubuntu/building/pool/main/r/ros-noetic-fcl/ros-noetic-fcl_0.6.1.orig.tar.gz' to '/tmp/sourcedeb/source/../ros-noetic-fcl_0.6.1.orig.tar.gz' Shouldn't the debian source package built from the branch? What's the role of the tarball?

Note, as the upstream package doesn't yet have a new release tag, I created the new ROS release 0.6.1-2 from a git commit SHA.

sloretz commented 3 years ago

but subsequently, also an older tarball is downloaded: [...] Shouldn't the debian source package built from the branch? What's the role of the tarball?

I'm not sure what the role of the older tarball is, (it seems to come from https://github.com/ros-infrastructure/ros_buildfarm/pull/374 ) but it looks like the output of the source job includes the updated code. One of the outputs of the job is an archive /tmp/sourcedeb/ros-noetic-fcl_0.6.1-2focal.debian.tar.xz which has a file debian/patches/debian-changes-0.6.1-2focal containing the changes between 0.6.1-2 and the original 0.6.1.

sloretz commented 3 years ago

I probably missed the announcement that added Debian builds to the requirements for a distro release.

Oops, Debian Buster is only Recommend Support for ROS Noetic. I chose to revert ros_controllers because ros-noetic-desktop-full depends on it, and it seems likely to be noticed since that's the recommended metapackage to install.

I'd be happy to run pre-release tests for debian too, could you please point me to a script generator for that?

I'd recommend installing the python3-ros-buildfarm package and running the Debian Buster dev job locally. For ros_controllers the commands to do the Debian Buster amd64 dev job locally appear to be

mkdir /tmp/devel_job
generate_devel_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml noetic db ros_controllers debian buster amd64 > /tmp/devel_job/devel_job_db_noetic_ros_controllers.sh
cd /tmp/devel_job
sh devel_job_db_noetic_ros_controllers.sh
sloretz commented 3 years ago

@rhaschke I opened a pull request to solve the fcl issue: https://github.com/flexible-collision-library/fcl/pull/514 . Mind making another release when it lands?

This time I verified it fixes the issue using the generate_release_script.py docker images. I saw CMake does think the host supports SSE2, and checking compiler support directly does fix the build.

tylerjw commented 3 years ago

Thank you for fixing fcl. :grinning:

We are currently dealing with some unrelated unstable testing issues in MoveIt. Once we resolve those issues I'm happy to make a Noetic release of MoveIt also after FCL is released.

rhaschke commented 3 years ago

Sure, I will prepare a new release as soon as the PR is merged. Thanks for working on this!

hidmic commented 3 years ago

@sloretz can we call this done?

sloretz commented 3 years ago

It almost can be closed. ros_controllers has since been re-released and appears to be building. moveit is still rolled back to 1.1.0. I opened a PR to re-release it in #28486

DLu commented 3 years ago

Now is it done?

torgeirl commented 3 years ago

As far as I can tell there are still issues the appeared with this regression, that are unsolved. For instance, Gazebo is no longer are able to run turntable.urdf.xacro in ROS simulations.

torgeirl commented 3 years ago

As far as I can tell there are still issues the appeared with this regression, that are unsolved. For instance, Gazebo is no longer are able to run turntable.urdf.xacro in ROS simulations.

Not sure what got addressed the last few weeks, but at least the issue I referenced has recently been resolved. :tada:

sloretz commented 3 years ago

I think this can be closed :tada: