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.