I’m not entirely sure this already ‘deserves’ a post here, but I’m seeing increased build failures (and CI failures) for builds which use the ros-testing repository. Regular builds (ie: using the main ros repository) succeed.
In both cases errors about “broken packages” are reported. From the buildfarm build (log):
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
ros-kinetic-industrial-robot-client : Depends: ros-kinetic-actionlib but it is not going to be installed
Depends: ros-kinetic-industrial-utils but it is not going to be installed
Depends: ros-kinetic-robot-state-publisher but it is not going to be installed
Depends: ros-kinetic-urdf but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
I don’t know whether there are any other builds failing on the buildfarm, as I can’t get any tabs other than the manage tab to load.
The swarmros failure log seems to point to something having to do with Python 2 and rospkg, rosdistro and rosdep:
35 'Broken ros-kinetic-roslib:amd64 Depends on ros-kinetic-rospack [ amd64 ] < none -> 2.4.5-1xenial-20191214-014035+0000 > ( misc )'
02:16:20 36 ' Considering ros-kinetic-rospack:amd64 -1 as a solution to ros-kinetic-roslib:amd64 9998'
02:16:20 37 ' Reinst Failed early because of python2:amd64'
02:16:20 38 ' Reinst Failed because of python-rospkg-modules:amd64'
02:16:20 39 ' Reinst Failed because of python-rosdistro-modules:amd64'
02:16:20 40 ' Reinst Failed because of python-rosdistro:amd64'
02:16:20 41 ' Reinst Failed because of python-rosdep:amd64'
Yes. It looks like the recent release of python-rospkg is Broken on Xenial and Bionic
The following packages have unmet dependencies:
python-rospkg : Depends: python2 (< 2.8) but it is not installable
Depends: python2 (>= 2.7) but it is not installable
Depends: python-rospkg-modules (>= 1.2.7) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
I thought this was resolved with stdeb 0.9.0 but when looking closer I realized that rospkg is missing the necessary config option. I’ll get working on the fix and an updated release.
https://github.com/ros-infrastructure/rospkg/pull/204 makes the necessary configuration change and the 1.2.8 release is importing now I pulled it directly from the bootstrap repository to verify it’s installability on Ubuntu Xenial and it should be the same for other python 2 platforms.
I think you were a bit too quick at the draw . The import_upstream job which pulls packages from the bootstrap repository into the build farm repositories (all three of building, testing, and main at once) finished about 20 minutes ago as of this writing but the upload_main and upload_testing jobs to push from the build farm repositories to the primary repositories on packages.ros.org had not yet run.
Those jobs have now also run so it should be broadly available as of now.
Edit: could you trigger a build for the abb_driver release job I referenced in the OP? Afaict it should build, but of course I can’t trigger it.
Would there be a way to add some sort of testing for this to the rospkg repository (and other repositories with Python 2 & 3 packages)? This particular case would have been caught by a test which attempts to install the package on all supported platforms.
Perhaps this is already done and I just haven’t checked btw (in fact: I haven’t ).
It wouldn’t be a bad idea to add a canary installation attempt when we push new releases to the bootstrap repository but we don’t have an existing apparatus for doing so which means it’s not a small task to incorporate such a pre-flight check. Because the problem exists only with the release artifacts it’s not something that we could add to the current CI for these projects.
I’ve opened a round of PRs for the other ros-infrastructure packages making sure that they at least have the necessary config values. As our Ubuntu 20.04 environments stabilize these kinds of regressions should dissipate. At least for another two years.
These images are not trivially rebuildable. The simplest fix I can think of (if any needed) without relying on external infrastructure is to upgrade rospkg when entering the container (run an apt update && apt upgrade).
I did not get a chance to reproduce on arm64 but I’ve had no issue using the amd64 images recently. Can you provide a reproducible example of the issue you are facing ?
The last build of these images was 8 days ago, meaning they do not have the faulty release of rospkg installed (that was released 3 days ago and fixed with another release 2 days ago). So I suspect the problem you are facing may be a different one
. The import_upstream job which pulls packages from the bootstrap repository into the build farm repositories (all three of building, testing, and main at once) finished about 20 minutes ago as of this writing but the upload_main and upload_testing jobs to push from the build farm repositories to the primary repositories on 
).