There is currently one regression and 121 packages ready to sync. Except for fixes for the regression, I plan to start holding packages Wednesday, June 10, with a sync later next week.
@smac The one regression in Melodic right now is in slam_toolbox. How would you like to fix that; a revert to an earlier version, or a fix forward?
Please comment here if there are any other outstanding issues I should know about before performing the sync.
@clalancette I noticed that along with a stream of build failures -> successes that have been oscillating in the build farm this week so I didn’t think much of it. There have been no PRs since the last sync so I’m not sure why this is failing.
Here is an example job, anything stick out to you as a problem? http://build.ros.org/job/Mbin_uB64__slam_toolbox__ubuntu_bionic_amd64__binary/46/consoleFull I don’t see anything here actionable. The only 2 things I can find are some pthread not found error which I’ve seen in other jobs before and some Assertion failed: GTEST_LIBRARIES (value is '') which nothing has changed in relation to.
Agreed on fixing it, but its not clear to me what’s wrong to fix.
That does appear to be the case, but a question is why does this cause an issue now? There have been 2 (maybe even 3) releases in Melodic since that was added without a failure over the last 9 months since gtest was introduced.
Looking through that list of triggers it looks like there were a couple of recent releasese.
tfoote@snowman4:/tmp Last: [0] (0s Seconds)
$ grep Msrc_uB triggers.txt | sort | uniq
Started by upstream project Msrc_uB__catkin__ubuntu_bionic__source build number 7
Started by upstream project Msrc_uB__message_filters__ubuntu_bionic__source build number 7
Started by upstream project Msrc_uB__python_qt_binding__ubuntu_bionic__source build number 7
Started by upstream project Msrc_uB__rosbag_storage__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__rosbag__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__rosbash__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__rosclean__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__roscpp__ubuntu_bionic__source build number 6
Started by upstream project Msrc_uB__roslaunch__ubuntu_bionic__source build number 6
Started by upstream project Msrc_uB__roslib__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__rosmake__ubuntu_bionic__source build number 6
Started by upstream project Msrc_uB__rosmaster__ubuntu_bionic__source build number 7
Started by upstream project Msrc_uB__rosmsg__ubuntu_bionic__source build number 7
Started by upstream project Msrc_uB__rosnode__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__rosservice__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__rostopic__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__roswtf__ubuntu_bionic__source build number 5
Started by upstream project Msrc_uB__topic_tools__ubuntu_bionic__source build number 5
tfoote@snowman4:/tmp Last: [0] (0s Seconds)
$ grep Msrc_uB triggers.txt | sort | uniq | wc -l
18
Which appears to follow the following releases:
Looking at the changelogs the change that looks to touch this code path most closely related to the failure:
Awesome, for my future ability to debug issues like this myself, how do I get to a place to be able to search for these triggers – or is this part of the internal OR toolset? Is there some documentation surrounding this?
Adding dependencies I don’t think should solve the problem. If by the time that the catkin package is found CMake hasn’t deduced that C++ is a language, then it won’t include gtest.
I copy and pasted the body into triggers.txt and above you can see my invocations of grep, sort, and uniq to filter them down. Then I just cross referenced those source builds to the changes in the rosdistro. And then browsed through the changelogs. Nothing magic, but a bunch of manual work.
Mhm this is fun. I’m also staring at the costmap_2d test setup and I can’t find a place where we deviate.
Edit: I’m just disabling tests for melodic for now. There’s only a few tests for some experimental features not used in the main nodes. Its not worth blocking the rest of the package for. I’ll see if this reappears in Noetic and I’ll fix there if necessary & reenable tests in melodic.
Also based on the build output gtest is certainly installed:
-- Found gtest sources under '/usr/src/googletest': gtests will be built
My best guess is that the add_subdirectory() call including a separate CMake project which finds catkin itselfmight be the culprit. I would suggest to make sure thatfind_package(catkin REQUIRED)` is called before that in the main CMake file.