MoveIt! is currently unreleased because the build farm requires the Ubuntu Wily builds to pass, and there is a different version of liburdfdom in Wily than Xenial that we did not test for. I just attempted to create a new Travis job to provide testing coverage of Wily for MoveIt, but I see that the official Ubuntu Docker images no longer provide an image for Wily and neither does the ROS/OSRF images. How are we suppose to test MoveIt! on Wily if Wily is end of life and we have no Docker container to use? Why is ROS still supporting Wily anyway? This seems like a big waste of robotic developer resources since no one should be using this outdated OS. At the very least, allow us to release MoveIt! into Xenial but not Wily.
According to @tfoote “There’s one or two changes we need to make to the buildfarm to support turning it off but we have not had time to make the upgrades.”
If you need docker images for Wily we have them available for all ROS supported architectures here: https://hub.docker.com/u/osrf/ They are all available and in use on the buildfarm. You can also use VMs or straight installations.
Although there are one or two changes necessary, they’re kind of fundamental where we need to restructure how the debian packages are structured and hosted. The tool we use for repository maintenance reprepro only supports one version of any given package. If we want to drop support for wily we will end up with packages of different versions with the same name for different platforms. However the underlying orig.tar.gz is not platform specific and will clash. There are likely changes needed both to bloom as well as the ros_buildfarm usage of reprepro. Without fixing this some new releases to ROS packages in xenial will break old packages in Wily that are in the archive but no longer reproducible since we will have turned off the buildfarm. Our estimates for the fix to this start at a couple of weeks of development.
I’ve created a Docker Ubuntu Wily test environment for MoveIt! but there continues to be various tests that fail in Wily but are fine in Xenial. In addition OMPL doesn’t build on Wily as we’ve been discussing here because of tests that behave differently than Xenial. We also spent a lot of time fixing differences in URDFDom on Wily, as I mentioned earlier. MoveIt! continues to be blocked from being released into Kinetic because of obscure Wily problems that matter to no one because Wily is end of life. This is a huge waste of time!
Is there no way to release for Kinetic and ignore breakages in Wily? Asking us to support that platform is a huge burden for volunteer developers trying to release a framework with many dependencies.
stop building for those platforms by the end of this month.
@davetcoleman I couldn’t agree more to what you said. The current situation:
wastes lots of effort on the maintainer side
wastes lots of resources on the buildfarm
wastes effort on the administrative side to monitor those platforms
results in many needless notification emails for jobs which will likely never work
@Vincent_Rabaud Yes, the release policy is still up to date.
Some technical background:
Consider the following case where a version 1.0.0-0 has been released into e.g. Wily and Xenial. Then we stop building for Wily since it is EOL. If a maintainer now wants to release a Debian increment only (version 1.0.0-1) the process fails. The reason is that bloom creates a new source archive but that can’t be imported into the apt repo because Wily still needs the old archive from deb inc 0. Instead bloom needs to generate a diff for the delta between deb inc 0 and 1 (see the existing ticket when creating debian incs bloom should create diff.tar.gz files instead of regenerating orig.tar.gz · Issue #150 · ros-infrastructure/bloom · GitHub).
An idea to work around it for now (disclaimer: I haven’t tried doing this, it is only a mind game atm):
If this fix is not implemented in bloom I could imagine a partial workaround. The problem only happens on Debian increments. Once the patch / minor / major version changes the two source archives are separate. So if Wily would be disabled (without fixing bloom) the next release of any package needs to be a non deb inc. I am not sure how we could enforce this. But I would expect the new release (aka the sourcedeb job) to just fail repeated until a proper non deb inc release is being made. After that the package can level in any way again.
The reason is that bloom creates a new source archive but that can’t be imported into the apt repo because Wily still needs the old archive from deb inc 0.
But what if we’ve never released our package(s) into Wily? In that case there should be no problem. I’m not actually asking to stop support Wily for a package that was previously supported on it - in MoveIt!'s case we’ve never been able to support Wily and we never want to. So this case you present does not seem to apply to us.
Indeed, for your package there is not technical problem. And it is not good that you are being restricted because of the other packages. Until that the above is being addressed you sadly have to live with the daily emails of all the failing jobs. (I tried pushing for disabling the EOL distros multiple times over the course of the year but with no success so far.)
The emails don’t bother me - a smart gmail filter fixes that easily. But its still not clear to me if we are being restricted from buildfarm syncs because of Wily - it appears so
See 
)…