Moveit: Initial Indigo release from ros-planning/moveit repo

[v4hn]

• [x] Wait for public sync --> Done on Aug 25 http://discourse.ros.org/t/new-packages-for-indigo-2016-08-25/458
• [x] #121 (changes ABI)
• [x] #63 (changes ABI)
• [x] #187 (addresses unintuitive behavior of the new author feature in msa)
• [x] #221 (continuation of #187)
• [x] #188
• [x] #148
• [x] #144
• [x] #232 --> Closed
• [x] #273
• [x] #283 --> Closed
• Version should be bumped since there's ABI changes.
• [x] soname https://github.com/ros-planning/moveit/issues/100#issuecomment-248757905
• [x] Remove existing release entry from rosdistro/indigo/distribution.yaml --> https://github.com/ros/rosdistro/pull/13442
• [x] Update changelog https://github.com/ros-planning/moveit/issues/100#issuecomment-268446976
• [x] Saucy on ROS buildfarm #389

---

What's the state of the next indigo release?
Will we have the release out tomorrow? (I presume not)
Are we in a situation where we want to have the release?

Do we want to wait for a backported version of #63 to address safety?

If this affects indigo-devel too, this is a regression we shouldn't release into indigo.

@130s @davetcoleman @rhaschke

[130s]

Yeah, I'm about to work on this. I leave up to you guys about the mentioned concern, so please share any thoughts on it.
If everything goes fine we may have debs ready on shadow-fixed.

[v4hn]

As we are currently unsure about the ABI stability of the release, I'm actually not keen to see this released by tomorrow...
Better safe than sorry.
Anyone else?

[davetcoleman]

I agree with @v4hn that we've had no soak time and, if we were to release indigo today, there is a chance we'd break our stable LTS on a day when hopefully lots of people will be using them. Let's wait a few days.

[de-vri-es]

Just a heads up, #77 (cherry-picked from #70) introduces one API change that should be reverted before the indigo release. See also #98.

The specific change was here: https://github.com/ros-planning/moveit/pull/77/files#diff-76b7a92f6aeeed9e7bba70df54cce8a7L101

The typedef ObjectConstPtr was fixed to actually be a pointer-to-const, but it appears in the public API in a number of places, so should be left as it was for Indigo.

Pull request coming in later today. Update: PR now available at #104

[davetcoleman]

The revert has been merged, thanks @de-vri-es for the quick response

[jspricke]

See #121 for ABI problems.

[130s]

• [x] Wait for public sync --> Done on Aug 25 http://discourse.ros.org/t/new-packages-for-indigo-2016-08-25/458
• [ ] #121
• [ ] #63?
• [ ] #187

(I've copy-pasted this to the top https://github.com/ros-planning/moveit/issues/100#issue-172498940 so that we could better keep track of the status)

What else?

[davetcoleman]

Looks good to me

[130s]

Might be a little early to discuss, but because the next release for Indigo will most likely include ABI change, ideally the version number reflects that to show the incompatibility between previous release. Usually AFAIK this is done by incrementing major/minor version.

• Earlier we agreed that the next Indigo release will take 0.7.3 while 0.8.x for Jade and 0.9.x for unreleased-yet Kinetic.
• Bumping minor version would make 0.8.x, which is taken by Jade release series.

Should the next Indigo be 0.9.x, and the Kinetic be 0.10.x?

[mikeferguson]

It's still < 1.0, so per ROS guidelines, ABI is not guaranteed anyways. I'd say leave it as 0.7.3.

[v4hn]

In my opinion, this whole "we are not 1.0 yet" point is a huge farce.
MoveIt is one of the biggest promoters of ROS, it has been used by many groups for _years_ but nobody should rely on _anything_ being stable?
Whatever.

I agree with @mikeferguson though, we misuse the version notation anyway. The notation is not meant to support multiple branches of the software as we have them with different ROS distributions, where we make ABI and feature changes within each branch. Thus, I'd just stay with 0.7.3 too.

[v4hn]

From my point of view https://github.com/ros-planning/moveit/issues/121 has been addressed now,
as good as we can and are willing to. I checked the bullet item in the top post.

[v4hn]

187 is a block too.

We don't want our users to live with unintuitive behavior of the new author-information field in the setup assistant.

[mikeferguson]

@v4hn -- the thing about 1.0 is that you've reached a point where (A) APIs have gone a complete review process and (B) the system is fairly stable and bug-free. We've never actually done an extensive review of the APIs, yes, we've reviewed things here and there along the way, but not in the way that ros_comm or navigation stack did when they approached 1.0. Since there is a very limited amount of unit/functional testing in the moveit codebase, we are also consistently finding bugs, many of which actually impact API/ABI.

I didn't suggest that "nobody should depend on anything be stable" -- I think the line we are walking right now, that we're only breaking the API/ABI for those cases where it is needed to fix bugs makes sense, but does not warrant changing the version number every time, since we would also have to bump jade/kinetic to make it clear that they are "newer"

And at some point, we really should do a 1.0 review early enough to bump a future version to 1.0, while fixing some of the deficiencies of the API (there have been a number raised over time that have not be fixed because of the difficulty of having those breaks)

[davetcoleman]

Bumping minor version would make 0.8.x, which is taken by Jade release series.

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

We really should do a 1.0 review early enough to bump a future version to 1.0, while fixing some of the deficiencies of the API

I have long been a fan of the Gazebo approach to breaking API - do not be afraid to increment major versions when necessary, but be strict about only breaking API between major versions. Between ROS Indigo and Jade, Gazebo released 2.2, 3.0, 4.0, and 4.0 (cite @scpeters).

I would prefer we head in the direction of releasing 1.0 so that we can begin making bigger breaking changes in 2.0. I have a hard time picturing what a 1.0 review would look like that - MoveIt! is so large and its use cases so varied that I'm not sure who could go through and say what needs to be changed, and who has those resources. Though I do personally have strong opinions about rewriting KinematicsBase and the the MotionPlanningPlugins pipeline, those changes are better targeted at 2.0 IMHO. In other words, I think we're basically already at 1.0 - we could just call that the Kinetic release.

[mikeferguson]

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

Yep -- very much a requirement.

[130s]

Is it really a requirement that each branch have different version numbers? Does bloom not work otherwise?

Yep -- very much a requirement.

I'm not aware that it's a requirement but here's what I figured personally.

It would be difficult to keep track of which version is made from which branch, if multiple releases are made from multiple different branches using the same version scheme (e.g. same major & minor version). For instance, following could happen: 0.0.1 is for indigo-devel, 0.0.2 is for kinetic. At the next release round, 0.0.3 is indigo, 0.0.4 is kinetic. It _could_ still be possible but messy.

For the major version we can discuss in the next maintainer mtg.

[v4hn]

A definite "no" to using the same minor version number to refer to commits from different branches.

[davetcoleman]

I don't understand why https://github.com/ros-planning/moveit/pull/221 is critical for the next indigo release. As far as I can tell we're ready for the next indigo release, whenever @130s has the time.

[130s]

I don't understand why #221 is critical for the next indigo release.

@v4hn claimed https://github.com/ros-planning/moveit/issues/100#issuecomment-244365559

[v4hn]

@davetcoleman I don't think #221 in particular is required, but we might want to resolve the following issue we have right now:

• Somebody opens an existing moveit config
• They have to enter the missing author information because it is mandatory
• They generate the package's files but do not check .setup_assistant (this is unchecked if they touched the file)
• next time they have to enter the author information again because it is not stored in .setup_assistant (even if they regenerated package.xml)

@rhaschke's proposed change #221 is much more general and solves this issue as a special case.

Personally, by now I think it would be enough to generate the .setup_assistant unconditionally, although I believe I disagreed with this approach earlier.
All the information currently in that file is loaded on startup, so even if you edited the file by hand it will be regenerated with the edited values.

[v4hn]

w.r.t. the indigo release: I would like to see the following requests merged before releasing.

• #188 (minor safety check)
• #148 (streamline the ApplyPlanningScene service)
• #144 (I know I know, I'm sorry, it's on the top of my list, right after sorting out my personal life)
  If someone wants to move this forward they can look into how #201 relates to this change. This bug report seems to be the exact thing we _don't_ want with an indigo release
• possibly #42 to make some long-time MoveIt users happy :)

Also because we very recently merged #63 and hopefully merge #144 we definitely need at least a week for testing before we release.

[davetcoleman]

...https://github.com/ros-planning/moveit/pull/42 is def. not high priority in my mind. If we keep hoping for all new PRs to be merged in we won't ever get a release out. Its been a full 3 months, new features can always get in next month.

[v4hn]

...#42 is def. not high priority in my mind.

No it's not, that's why I prepended "possibly". It's just not much work either. :)

If we keep hoping for all new PRs to be merged in we won't ever get a release out. Its been a full 3 months, new features can always get in next month.

I agree. If you're fine with having another indigo-release without the ExecuteTrajectory Action Server, #144 could stay out of the release too.

The point about time for testing remains.

Also you and @rhaschke noticed a flaky test (that has likely been there for a long time and succeeded as false-positive before, but I didn't check).
Now #232 is proposed again. This will break ABI changes again. So if we leave this out of the next indigo-release (where we break ABI in multiple places anyway for safety reasons), then I would like to have sonames in the next release so that we can mark new ABI changes afterwards.
This release should definitely be the last time we need to send mails out to users to tell them that they have to recompile their code or weird things might happen.

[rhaschke]

I think #232 should be considered for the release. Having the new trajectory validation in place (#63), user might be annoyed if execution fails because planning in first place didn't use an up-to-date robot state for the starting pose. #232 was started to review here, but was depending on #63, which is now merged.

[130s]

I'm not disagreeing with anything, just wanted to give an input. Just to be clear with a risk of being pedantic, making a release:

• by itself does not necessarily get the released stuff out to the users (it's what they call "public sync" when normal users will have an access to the released software).
• does allow users to access the binary via a proving ground so-called shadow-repo.
  
  
  
  • I want a name for this period for the convenience. Maybe "shadow-time" (in contrast to soak time)?
  
  

That said, now that Indigo public sync cycle just got kicked off, which means sync _can_ happen within a week as announced, we either make a release NOW and ask to push forward the sync (for a few or more days), or wait for the next sync cycle.

[v4hn]

That's a really good point! I didn't consider shadow-time.
This is because I indeed tend to consider the release as "get the released stuff out to the users".
Directly after the release happened rosinstall_generator <package> will return the new version, right?
Thus, shadow-time only influences the deb packages provided by osrf.
Everyone who directly uses rosinstall (possibly not using Ubuntu) will circumvent the shadow-time.

I know it's lame, was planned differently earlier, and I would like to have more releases too, but I would like to release after the next sync.
Also with consideration to #232 and the resulting ABI breakage.
As @rhaschke stated above, #63 provides the safety mechanism for a problem with the plan/execute API, but it does not resolve the problem itself. #232 tries to resolve this, so this is worth waiting imo.

[130s]

Directly after the release happened rosinstall_generator will return the new version, right?
Thus, shadow-time only influences the deb packages provided by osrf.

Oh yeah, correct. My comment in https://github.com/ros-planning/moveit/issues/100#issuecomment-248896591 only applies to binary built on ros buildfarm.

[davetcoleman]

I'm not sure where the best place to note this is, but just wanted to point out that for the next release moveit_robots has been split from master to two branches indigo|kinetic-devel and bloom will need to be updated

[v4hn]

273 is relevant for the indigo release too.

[rhaschke]

273 is relevant for the indigo release too.

I would not introduce SO names into Indigo. This is a LTS release.

[v4hn]

On Fri, Oct 14, 2016 at 08:29:34AM -0700, Robert Haschke wrote:

I would not introduce SO names into Indigo.
This is a LTS release.

What is your reasoning for this?
We break (broke) ABI in indigo.
If we'll see another indigo release after this one (I suppose we will), we will likely break ABI again.
If we don't add SONAMES in the indigo branch, this would mean we will silently break user setups again.

This is why I consider it relevant for the next indigo release.

[davetcoleman]

It seems we are assuming sonames are a mission-critical feature, but I think we've lost perspective that most (all?) of ROS does not use them, MoveIt! has never used them, and we've always just broken ABI. Its not the worse thing in the world to run a single command to rebuild the work space, if you are building from source you are probably a developer so are probably already doing that.

But of course sonames are nice to have.

[jspricke]

They are surely not mission-critical, but adding them makes breaking the API explicit which is really nice. +1 for adding them.

[rhaschke]

Introducing sonames is a fundamental change to the way we deploy libs. I do see the motivation for this. But as Dave said, ROS users are not necessarily used to it. Hence, I would vote to not introduce this change in Indigo (in the middle of an existing release). Doing it in Kinetic, users are transitioning anyway, and thus do expect such changes. I think, that we tried to keep the ABI changes in Indigo as small as possible, so that normal users will not even notice. However, introducing sonames, will definitely break their existing installation from now to then.

[davetcoleman]

I don't have a strong opinion on merging this into indigo either way, I just wanted to point out we were assuming sonames were too big a deal.

will definitely break their existing installation from now to then.

When you say it will "break", is the fix to simply run catkin build on the whole indigo work space again?

[130s]

AFAIK lots of goodies mentioned in the 2nd MoveIt! community mtg are not yet available in Indigo binary, which the majority of ROS-MoveIt! users might be still on. It'd be great if we can move on soon.
Looks like the only blocker is #144.

[davetcoleman]

+1

[v4hn]

Looks like the only blocker is #144.

There is still the matter of sonames. If we don't introduce them now in indigo, there's no sense in doing it later on either.

@rhaschke told me that his lab does automatic updates and thus he might end up with a broken workspace one morning even though there might not have been any breaking ABI changes. This is what happens if we change the sonames with each release.

These are the options I see:

• leave things as they are and don't change ABI. In many cases this means, don't backport changes to indigo anymore.
• add sonames and bump them with each release. This is what we do with kinetic now and it ignores @rhaschke's use-case.
• add sonames but track ABI-changes by hand. I'm willing to do that for further releases into indigo.
  Thus we could change ABI and mark breakage, if we can't or don't want to avoid it.
  I don't want to do that with our main development branch (currently kinetic) though.
  Would that be a valid way out @rhaschke ?

that we tried to keep the ABI changes in Indigo as small as possible, so that normal users will not even notice

Just to be clear about this: _There is no "as small as possible"_. If we break ABI we break ABI and this can introduce breakage. MoveIt is really unforgiving with this though, because we don't compile with visibility=hidden. (something we might want to consider in the future)

[130s]

@rhaschke Would you give us any feedback to the previous post https://github.com/ros-planning/moveit/issues/100#issuecomment-259989295 ?

[davetcoleman]

I don't have a strong opinion, but I'd vote for "add sonames but track ABI-changes by hand" - seems like the best of both worlds.

[130s]

Indigo release has been stale since 6 months ago. I'm eager to make a release once more before the year ends. Let's move forward with "add sonames but track ABI-changes by hand" option (voted twice so far, while other options with 0 vote).

...but sorry I don't know what to do with that option. @v4hn @davetcoleman ?

[v4hn]

Ok, I'll provide a pull-request for that in the forseeable future.

[130s]

We're ready to make a release AFAIK. Maintainers please hold changes to indigo-devel before a new release is made.

[130s]

Release requested https://github.com/ros/rosdistro/pull/13444

One issue remaining is that I couldn't update changelogs...For some reason catkin_generate_changelog fails like the following. Hoping that once the first release from this moveit repo is done the command would become functional, I rather went ahead made a release.

$ cd ros-planning/moveit
$ catkin_generate_changelog 
Found packages: chomp_motion_planner, moveit, moveit_commander, moveit_controller_manager_example, moveit_core, moveit_experimental, moveit_fake_controller_manager, moveit_kinematics, moveit_planners, moveit_planners_chomp, moveit_planners_ompl, moveit_plugins, moveit_ros, moveit_ros_benchmarks, moveit_ros_benchmarks_gui, moveit_ros_control_interface, moveit_ros_manipulation, moveit_ros_move_group, moveit_ros_perception, moveit_ros_planning, moveit_ros_planning_interface, moveit_ros_robot_interaction, moveit_ros_visualization, moveit_ros_warehouse, moveit_setup_assistant, moveit_simple_controller_manager
Querying commit information since latest tag...
ERROR: Could not fetch latest tag:
fatal: No tags can describe '746dbf9dcc663751e8b2eb3d68b09c080101dcd8'.
Try --always, or create some tags.
$ git describe
fatal: No tags can describe '746dbf9dcc663751e8b2eb3d68b09c080101dcd8'.
Try --always, or create some tags.
$ git tag
0.8.3
0.9.1
0.9.2
0.9.3

[130s]

To make a release request, I had to remove released entries for the packages within this repo https://github.com/ros/rosdistro/issues/13442 because bloom required so.

Problems rise though: At this instantaneous moment, https://github.com/ros/rosdistro/issues/13442 is merged and https://github.com/ros/rosdistro/pull/13444 is not yet merged. Thus there are no entries for the packages in this repo so that rosdep can fail so does apt-get install ros-indigo-moveit-X (X can be any name of those packages).

There still seem to be DEBS built previously on repositories.ros.org (e.g. moveit_core). So the issue is the missing entries in rosdistro.

As soon as https://github.com/ros/rosdistro/pull/13444 gets merged and binaries are built, those packages should become available again. I don't know though if public sync is necessary for those who use public repo to be able to obtain moveit-X debs again.

At this moment I'm not sure the impact of this (I haven't seen any users yelling on answers yet) so will wait for https://github.com/ros/rosdistro/pull/13444 to be merged.

@tfoote @dirk-thomas if you have any suggestion to shorten the "downtime" for MoveIt! indigo debs, please let us know.

I apologize for any inconvenience due to my hasty release action.

Future note for replacing rosdistro entry
Maybe I should've replaced the entry within a single commit, instead of opening 2 different PRs where one to remove the current entries and the other to add new entry. This way the entry for the existing packages (e.g. moveit_core) would have never been gone from rosdistro.

[v4hn]

On Wed, Dec 21, 2016 at 04:49:29AM -0800, Isaac I.Y. Saito wrote:

Future note for replacing rosdistro entry
Maybe I should've replaced the entry within a single commit, instead of opening 2 different PRs where one to remove the current entries and the other to add new entry. This way the entry for the existing packages (e.g. moveit_core) would have never been gone from rosdistro.

Yes, it would have been a good idea to provide the change together with the new release in one pull request.

I apologize for any inconvenience due to my hasty release action.

Well, only now I'm looking into whether indigo-devel is "ready for release" from my point of view.
So at least we might want to do a follow-up release if I find problems.

[ipa-mdl]

Something did break.
For some reason http://build.ros.org/ seems to be down.
http://repositories.ros.org/status_page/ros_indigo_default.html (from 7 hours ago) does not list moveit packages anymore.

Not sure if this was just bad timing ;)

Travis jobs start to fail..
Examples:
https://travis-ci.org/ros-industrial/industrial_ci/jobs/185750071
https://travis-ci.org/ipa320/cob_robots/builds/185693319

[dirk-thomas]

@130s As mentioned by others before: making the changes in a single PR avoids the in between state.

@ipa-mdl The Jenkins master hanging is unfortunate but unrelated to any user actions. Jenkins memory usage simply increases over time for such a large scale deployment and at some point hits the wall. While we are trying to improve things over time it still happens every now and then. I have restarted the master and it should pick up the backlog of jobs.

[v4hn]

Ok, I've looked through the logs of abi-compliance-checker between the previous release and current head.

There are two clear ABI breaks, but we agreed to allow them earlier.
One is https://github.com/ros-planning/moveit_core/pull/295, the other is https://github.com/ros-planning/moveit/pull/223.
Both are not nice and we should tell users, but they are mostly used internally and the benefits outweigh the breakage.

I believe rather few users have code that plans with both Joint & Position/Orientation constraints around (it's horribly slow and unreliable due to rejection sampling), and it was actually broke before, but with #188 it does not "seem to work but is horribly slow" anymore, but instead prints a lot of red lines saying

IKConstraintSampler received dirty robot state, but valid transforms are required. Failing.

https://github.com/ros-planning/moveit/pull/384 fixes this and I would have liked to see that as part of the release.

Also, I found that the newly resurrected chomp interfaces and the old benchmark_gui fail to install their headers correctly, but that's not too important. We should really get on with getting our build-system lint-free. :)

[davetcoleman]

@130s thanks for working on this, I know the first release from the consolidated repo is tricky

[130s]

https://github.com/ros/rosdistro/pull/13458 Released 0.7.4 with fixes #387 merged in. Fingers crossed same as the first Jade and Kinetic release from this consolidated repo...

Prerelease test for Trusty passed. For Saucy it failed at the very early stage like below, which I don't feel like tracking down now (looks to me like non-moveit issue. And,...Saucy?).

$  generate_prerelease_script.py   https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml indigo default ubuntu saucy amd64   moveit   --level 0   --output-dir ./
:
Step 15 : RUN echo "2016-12-22 (+0000)"
 ---> Using cache
 ---> 8fd50777fea0
Step 16 : RUN for i in 1 2 3; do apt-get update && apt-get install -q -y python3 && apt-get clean && break || sleep 5; done
 ---> Using cache
 ---> be1c966614a4
Step 17 : RUN python3 -u /tmp/wrapper_scripts/apt.py update-install-clean -q -y git python3-apt python3-catkin-pkg python3-empy python3-rosdep python3-rosdistro wget
 ---> Running in b1057f3d962c
/bin/sh: 1: python3: not found
Removing intermediate container b1057f3d962c
The command '/bin/sh -c python3 -u /tmp/wrapper_scripts/apt.py update-install-clean -q -y git python3-apt python3-catkin-pkg python3-empy python3-rosdep python3-rosdistro wget' returned a non-zero code: 127

[gavanderhoorn]

awesome work @130s :sparkles:

[130s]

Indigo Trusty 64b build seems to be ready in shadow-fixed http://repositories.ros.org/status_page/ros_indigo_default.html?q=moveit

[gavanderhoorn]

Could this be the first 'victim' of the SONAMES that were added?

[v4hn]

On Fri, Dec 23, 2016 at 02:20:25AM -0800, G.A. vd. Hoorn wrote:

Could this be the first 'victim' of the SONAMES that were added?

Yes, they didn't recompile their workspace (in this case specifically the fanuc_lrmate200id_manipulator_moveit_ikfast_plugin) after updating moveit.
Incidentally, they are not the first ones being surprised by this, but I can't find the previous thread right now.
Be prepared to see some more of these questions in the future.

However this is not relevant for the indigo release (we didn't change sonames there (yet)), so it does not relate to this thread.

[130s]

Some packages haven't been built yet for Saucy (again, S.a.u.c.y?) but the last build timestamp (e.g. moveit_ros_planning_interface) seems to be Dec 22, yesterday, so I assume it's just a matter of time before the next build jobs get started by @thesantaclause.
HHD everyone!

[130s]

Quick update; Saucy build seems to fail for moveit_kinematics. Seems to me there are multiple errors, at

 00:04:03.955   CMake 2.8.12 or higher is required.  You are running version 2.8.11.2

and

00:04:03.964 E: Building failed
00:04:03.967 Traceback (most recent call last):
00:04:03.967   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 133, in build_binarydeb
00:04:03.967     subprocess.check_call(cmd, cwd=source_dir)
00:04:03.967   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
00:04:03.968     raise CalledProcessError(retcode, cmd)
00:04:03.968 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-moveit-kinematics']' returned non-zero exit status 1

(2nd error seems similar from what I got from prerelease test https://github.com/ros-planning/moveit/issues/100#issuecomment-268826497)

http://build.ros.org/view/Ibin_uS64/job/Ibin_uS64__moveit_kinematics__ubuntu_saucy_amd64__binary/4/console

1.1. build binarydeb
:
00:04:03.527 if [ -f "/opt/ros/indigo/setup.sh" ]; then . "/opt/ros/indigo/setup.sh"; fi && \
00:04:03.527    dh_auto_configure -- \
00:04:03.527        -DCATKIN_BUILD_BINARY_PACKAGE="1" \
00:04:03.527        -DCMAKE_INSTALL_PREFIX="/opt/ros/indigo" \
00:04:03.527        -DCMAKE_PREFIX_PATH="/opt/ros/indigo"
00:04:03.941    mkdir -p obj-x86_64-linux-gnu
00:04:03.943    cd obj-x86_64-linux-gnu
00:04:03.943    cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/indigo -DCMAKE_PREFIX_PATH=/opt/ros/indigo
00:04:03.955 CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
00:04:03.955   CMake 2.8.12 or higher is required.  You are running version 2.8.11.2
00:04:03.955 
00:04:03.955 
00:04:03.956 -- Configuring incomplete, errors occurred!
00:04:03.957 dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/indigo -DCMAKE_PREFIX_PATH=/opt/ros/indigo returned exit code 1
00:04:03.958 make[1]: *** [override_dh_auto_configure] Error 2
00:04:03.958 make[1]: Leaving directory `/tmp/binarydeb/ros-indigo-moveit-kinematics-0.7.4'
00:04:03.961 make: *** [build] Error 2
00:04:03.961 dpkg-buildpackage: error: debian/rules build gave error exit status 2
00:04:03.964 E: Building failed
00:04:03.967 Traceback (most recent call last):
00:04:03.967   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 133, in build_binarydeb
00:04:03.967     subprocess.check_call(cmd, cwd=source_dir)
00:04:03.967   File "/usr/lib/python3.3/subprocess.py", line 547, in check_call
00:04:03.968     raise CalledProcessError(retcode, cmd)
00:04:03.968 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-moveit-kinematics']' returned non-zero exit status 1
00:04:03.968 # END SUBSECTION
00:04:03.968 
00:04:03.968 --------------------------------------------------------------------------------------------------
00:04:03.968 `apt-src build ros-indigo-moveit-kinematics` failed.
00:04:03.968 This is usually because of an error building the package.
00:04:03.968 The traceback from this failure (just above) is printed for completeness, but you can ignore it.
00:04:03.968 You should look above `E: Building failed` in the build log for the actual cause of the failure.
00:04:03.968 --------------------------------------------------------------------------------------------------
00:04:04.026 
00:04:05.486 Build step 'Execute shell' marked build as failure
00:04:05.488 [ssh-agent] Stopped.
00:04:05.529 [description-setter] Could not determine description.
00:04:05.565 Sending e-mails to: [email protected] [email protected] [email protected] [email protected]
00:04:05.619 Warning: you have no plugins providing access control for builds, so falling back to legacy behavior of permitting any downstream builds to be triggered
00:04:05.620 Finished: FAILURE

[130s]

0.7.5 release requested https://github.com/ros/rosdistro/pull/13481

[130s]

0.7.5 still fails to build on buildfarm for __Saucy__ but only moveit_setup_assistant. Hope #389 fixes it.

[130s]

From https://github.com/ros-planning/moveit/pull/389#issuecomment-269346138 by @v4hn

Didn't we discuss Saucy-support before in some thread?

We did for Wily for Kinetic but I can't remember for Saucy.
I asked on answers if there's a way to make a release ignoring EOL distros.

[davetcoleman]

This is the same discussion as https://discourse.ros.org/t/drop-support-for-wily/727 - @tfoote already explained what is holding back discontinuation, though I don't 100% understand why a workaround can't be found.

[130s]

A sync is planned to happen soon. If we can't make a new successful release by then, I assume the following will happen:

• packages that are already successfully built on buildfarm will be synced.
• failing packages that have already been successfully released before (ie. moveit_setup_assistant) remain as older version.
• failing packages that have never been released (ie. moveit) won't be synced.

I guess the above is fine (not ideal though) but if not then please leave comments in the linked discussion.

[130s]

At last all green after 0.7.6 release https://github.com/ros/rosdistro/pull/13512 !
Still not available in shadow-fixed yet but it will be soon.

[130s]

Publicly synced. Now you can install ros-indigo-moveit. Thanks all who helped development on this ticket actively/passively!