ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

Adding Debian as a Tier 2 platform

Following up from some comments during the last TSC meeting and this ancient thread, I’d like to check what tasks need to be done to get Debian Buster as a Tier 2 supported platform for ROS 2 Eloquent.

In particular what infrastructure do we need to set up and what do we need to provide to where for the binary packages to be made available?

1 Like

This would be a good starting point @gbiggs.

I am working with @gbiggs for Tier 2 support.

I installed and ran ROS 2 Eloquent with Buster.
So next , I want to create a CI for Buster.

I think the following two are important for Tier 2 support, is it correct?

  1. Create a Debian Agent with ROS Buildfarm and test it with the same frequency as other Tier1 and Tier2.
  2. Provide support for CI failures.

First of all, we plan to build and verify Master, Agent (added Debian), and Repo on private servers.
What should we do as the next step?

And what support should we do for CI failures?


What are your thoughts on this @nuclearsandwich? I know back in July you worked on Tier 2 support for armhf.

1 Like

I was discussing this with @tfoote just now and we think that for the moment it would be okay if you added a Debian Buster build to via pull requests to as the shortest path to shareable results. To make developing that PR easier it might make sense to set up a local CI clone which would require at least two virtual machines, one for the master and one for the agent.

Linux builds on and ros_buildfarm are run inside Docker containers, so it is not necessary for either setup to have agents running Debian natively and I’d expect there to be some problems doing so since the configuration management for buildfarm_deployment and the instructions available for setting up infrastructure all assume Ubuntu 16.04.

@miker256 this article uses ROS from Buster repositories and is not going to be much use when supporting mainline ROS 2 development on Debian Buster since they’ll need tool versions from our repositories not Debian’s.

armhf required additional agents because none of our existing agents, which are amd64 and arm64, had support for the armhf instruction set. Adding support for Debian builds is a matter of configuration, either forking or adding a config file to (this route also has binary release requirements, see



Thanks for the response.
We will start building the Debian agent with Docker and incorporating it into Buildfarm.

I have an additional question.

If PR is merged, Debian will be added to ros2/ci. What’s the difference between Tier1 and Tier2?

Thanks for the detailed response, @nuclearsandwich.

Support tiers are defined in REP-2000.

ros2/ci has many different job types
Right now support tiers describe what may block a release, automated testing frequency requirements, and, on platforms where per-package binaries are available, what type of binaries we provide. In the past it’s been easier to add additional nightly jobs for tier 2 platforms rather than create a separate periodic job type. But only the Tier 1 platforms are triggered as part of a pull request review process and even with nightly jobs running that does not mean that our on-call build farmer is required to respond to issues on other platforms. Once the jobs are running on CI we’ll expect that the community members who want to support Debian will do the work of checking the periodic jobs and getting them on par with the other platforms.

I understand the difference. Thank you for the detailed explanation @nuclearsandwich.

We prepared the buildfarm using virtual machines, and create a job using, but I have one question.

The sub-module included in seems to be private.
Now, comment out the part of the Dockerfile that adds the license and run the job with the option not to use Connext. Do we have to contract and prepare our own RTI Connext DDS license?

The logic in ros2/ci has two options to use Connext:

  • either install the Debian package available (which implies accepting the embedded license) or install Connext on macOS / Windows machines
  • or build Connext from source (that is what the osrf/rticonnextdds-src repo is for). Since this repo is private you would need to talk to RTI if you want access to their sources in a similar way.

Sticking to just the first option is probably fine for you.

Thank you for your response. @dirk-thomas
I will try the first option in my local environment.

We modified the Dockerfile and finished testing with jenkins. The build was successful, but some test fail. The test summary is as follows.

Summary: 268 packages finished [1h 4min 57s]
   6 packages failed: ros2action ros2component ros2doctor ros2node ros2service ros2topic
   11 packages had stderr output: ament_lint osrf_pycommon pendulum_control rcl rclcpp rclpy rcutils rqt rviz_default_plugins rviz_rendering test_rclcpp
   9 packages had test failures: rclcpp ros2interface ros2msg ros2param ros2pkg ros2srv rviz_default_plugins rviz_rendering sros2

Should we fix all these errors before sending PR to ros2/ci?

Please try another build with the latest state. I would assume most of these errors should have been resolved by now.

Please feel free to create the PR whenever you are ready. Once that is the case we will kick off some jobs anyway to check their status.

Thank you for answering. @dirk-thomas

When I tried from the latest commit, test results have been improved.
There are still some errors, but it seems to be caused by the version difference of apt package.

I also created a PR.
Please let me know if there is any additional work.