I have searched several posts in forum and stack exchange, which described how to build a deb package for a single project by bloom.
However, I want to build all deb packages for the full ROS2 distribution. I don’t think build each deb package from each project under src is a good way to do it.
I have built full ROS2 from source on debian 12 bookworm. So what is a good way to build the full distribution ? Anyone can give me some suggestions ? thanks.
The best supported way to build an entire ROS distribution currently is to set up your own instance of the ROS build farm. This is doable but daunting and the documentation can use improvement and updates. The entrypoint for setting up a build farm is GitHub - ros-infrastructure/chef-ros-buildfarm. You can open issues on that repository (preferred) or in the #infra-help channel on the official OSRF discord server if you get stuck.
There are other options with less initial configuration setup but I’m not sure that they’re suitable to building a complete distro (they could be, but I’ve never tried), one that was shared here previously is Packaging ROS with GitHub Actions: software release and blog post
I have built full ROS2 from source on debian 12 bookworm. So what is a good way to build the full distribution ? Anyone can give me some suggestions ? thanks.
Notably, bookworm is not currently a supported platform for any of the active ROS 2 distributions. Rolling is about to undergo a major platform migration to shift to Ubuntu Noble and I am planning to hoist it up to Bookworm at the same time. In order to build on bookworm before that transition, or for a distribution other than Rolling, you will need to run bloom (or more likely, our distribution migration tool) with your own forks of each release repository which would be quite cumbersome.
What’s your objective in building debs for the platform? Depending on your distribution needs, you could also archive a colcon install space after building from source and use that rather than setting up the full Debian pipeline.
I’ll also recommend the Mod team move this thread into the Build farm category.
1 Like
Thanks for your detailed answers.
I built ROS2 (iron) on an embedded platform which is shipped with a debian bookworm, I want to share ROS2 I built by debian packages ( ideally ) to other coworkers.
For now, I can only let them create a same user what I am using to build ROS2 ( to keep the same path set in setup.sh ) , and package the whole workspace as an archive. It is not a good way.
I’m not sure how the ROS buildfarm works, but maybe you can also create debian packages with aptly for example?
I built ROS2 (iron) on an embedded platform which is shipped with a debian bookworm, I want to share ROS2 I built by debian packages ( ideally ) to other coworkers.
Got it, thanks for sharing. I’ll provide the information below and you can decide whether sharing a colcon workspace, while not as clean, is at least significantly less effort.
There definitely is not a straightforward path to building your own rosdistro for a platform that is not supported by the official distribution but the broad strokes would be:
- Create your own organization on GitHub to host your forked build farm deployment configuration, rosdistro, ros_buildfarm configuration and release / gbp repositories.
- Fork ros/rosdistro to your new GitHub org and prepare the target distribution for a platform migration. You can follow the commit log in https://github.com/ros/rosdistro/pull/32036/commits to see how that was done. 3. Use the migration-tools to re-bloom every package in your source distribution for your updated configuration. The migration-tools themselves are stored in the rosdistro repo with their own readme.
- Run the migration, I’d advise pinning to a specific sync of Iron from the official distros in order to know that you’re at least running something that was coherent enough to sync.
- Configure your build farm cluster, and use a ros_buildfarm_config with your rosdistro index targeted to generate jobs on that cluster.
- After several rounds of builds you’ll have your distro in your testing repository and you can sync that to your main repository as needed. Because bookworm is not supported by Iron upstream, you’ll need to re-run the migration process every time that you want to incorporate changes in Iron or else bloom individual packages into your release repositories manually but I recommend tracking upstream closely with the migration tool rather than manually curating your own releases.
If you’re referring to https://aptly.info this is a tool for managing apt repositories which are collections of deb packages. It does not, to my knowledge, have any features which support the building of any individual deb packages. aptly’s place in this pipeline would be as an additional mirroring step to allow you to snapshot your main repository which would prevent you from losing old versions of packages during sync since the ros_buildfarm repository does not support including multiple versions of the same package in one distribution.
At Locus, we build a large subset of ROS1 and ROS2 into a single deb using GitHub - locusrobotics/tailor-distro: Measure twice, cut once.. You may find the python tools in that repository interesting.
2 Likes