ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Build failing because of dependency issue

asked 2016-10-24 18:13:33 -0600

asmodehn gravatar image

I currently have a build failing on the buildfarm.

The reason seems to be a version check on a dependency :

# BEGIN SUBSECTION: build binarydeb
04:36:43 Package 'ros-indigo-pyros' version: 0.2.0-0trusty-20161024-043014-0700
04:36:45 Invoking 'apt-src build ros-indigo-pyros' in '/tmp/binarydeb/ros-indigo-pyros-0.2.0'
04:36:48 I: Building in /tmp/binarydeb/ros-indigo-pyros-0.2.0 ..
04:36:49 dpkg-buildpackage: source package ros-indigo-pyros
04:36:49 dpkg-buildpackage: source version 0.2.0-0trusty-20161024-043014-0700
04:36:49 dpkg-buildpackage: source distribution trusty
04:36:49 dpkg-buildpackage: source changed by AlexV <>
04:36:49  dpkg-source --before-build ros-indigo-pyros-0.2.0
04:36:49 dpkg-buildpackage: host architecture amd64
04:36:49 dpkg-checkbuilddeps: Unmet build dependencies: ros-indigo-pyzmp (= 0.0.14)
04:36:49 dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
04:36:49 dpkg-buildpackage: warning: (Use -d flag to override.)
04:36:49 E: Building failed
04:36:49 Traceback (most recent call last):
04:36:49   File "/tmp/ros_buildfarm/ros_buildfarm/", line 133, in build_binarydeb
04:36:49     subprocess.check_call(cmd, cwd=source_dir)
04:36:49   File "/usr/lib/python3.4/", line 561, in check_call
04:36:49     raise CalledProcessError(retcode, cmd)
04:36:49 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-indigo-pyros']' returned non-zero exit status 1

But it doesn't make much sense to me since that pyzmp package v0.0.14 is available :

Any hint ?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2016-10-24 19:37:35 -0600

Dirk Thomas gravatar image

I would suggest to try a more relaxed version dependency:

Using version_eq is very uncommon therefore I would recommend to try replacing version_eq="0.0.14" with version_gte="0.0.14". If that works then using version_gte="0.0.14" and version_lte="0.0.14" might achieve the same thing.

Background: to each Debian package we append a timestamp when it was produced. Maybe that interferes with the equal check.

edit flag offensive delete link more


To test that timestamp thing, I just made another bloom release of the exact same version :

asmodehn gravatar image asmodehn  ( 2016-10-25 08:05:35 -0600 )edit

So it seems making a new bloom-release didn't help. It is documented in and should work. Let me know where I should open an issue. I can work around it later.

asmodehn gravatar image asmodehn  ( 2016-10-26 20:11:11 -0600 )edit

Question Tools



Asked: 2016-10-24 18:13:33 -0600

Seen: 176 times

Last updated: Oct 24 '16