osrf
GUI docker images only available for amd64 and not arm64v8
Hello,
from time to time I am heading into this issue.
I was lead here by this post: https://discourse.openrobotics.org/t/ros-jazzy-docker-images/37879
My platform: arm64v8 Problem: for this platform, no suitable docker images are hosted for the GUI variants. What images are concretely affected: https://hub.docker.com/r/osrf/ros/tags?name=jazzy-des
Currently, I am in need to build these images myself in order to get this project to run: https://github.com/drfenixion/freecad.robotcad/issues/105
Thank you!
Bit of a work-around, but sloretz/ros_oci_images does publish arm64 builds of ros:jazzy-desktop-full (as ghcr.io/sloretz/ros:jazzy-desktop-full).
This is very important. osrf/ros needs keep up to date with ros official repository, which indeed supports multiple platform. Moreover, it states the following.
The rest of the common meta-packages such as desktop are hosted on repos under OSRF's Docker Hub profile here. These meta-packages include graphical dependencies and hook a host of other large packages such as X11, X server, etc. So in the interest of keeping the official images lean and secure, the desktop packages are just being hosted with OSRF's profile.
@alvgaona took me some time to understand what you wrote there. But now I start to understand it. Yes the osrf/ros and the ros repositories are not identical in terms of multiple platform support.
How can we address this? Is this just a setting in the build farm or is it possible to address this issue via a PR?
Thank you both for your support!
@alvgaona took me some time to understand what you wrote there. But now I start to understand it. Yes the
osrf/rosand therosrepositories are not identical in terms of multiple platform support.How can we address this? Is this just a setting in the build farm or is it possible to address this issue via a PR?
Thank you both for your support!
As far as I know this repository should be able to build and release the Docker images built in linux/arm64. Should not be that hard to do. I have built mine myself with a straightforward Dockerfile, but I'm not sure exactly about how the structure of OSRF release is set up; maybe it is just a matter of CI builds.
I think it is just a CI runner thing.
Running this on arm just works out of the box: (thanks to the multi-arch base images from the ros repo)
https://github.com/osrf/docker_images/blob/0038f1c3a11aa0fc573d698b39ab5c204aad5a40/ros/jazzy/ubuntu/noble/desktop/Dockerfile
Link is from the discourse post above.
@gramss it should not be a big lift. The GH workflows are using an action called docker/build-push-action to build and push the images. It's just a matter of adding the platforms value, and adding the QEMU action. At least that's how I've done it in one of my repos: https://github.com/alvgaona/ros-docker-images/blob/main/.github/workflows/ros_ci.yaml#L44
Not only the trigger_nightly, trigger_devel, and trigger_testing should be modified but ros2_ci as well.
I'm slightly confused why you'd build things yourself if the repository I linked earlier already has these images available.
I'm slightly confused why you'd build things yourself if the repository I linked earlier already has these images available.
Regardless, it'd be nice to have arm64 images in this repo rather.
I'm slightly confused why you'd build things yourself if the repository I linked earlier already has these images available.
Sorry, I did this as a workaround in the past before I found and you wrote your answer. And just used this argument to confirm that there should be no blocking points in building the images multi-aarch.
I even put it in the original issue that I needed to built it myself and wrote this issue in the hope to solve it for others properly in the future.
My point is the same as @alvgaona , that this should be part of the official repo.
Finding some "random" repo that might have this inside is not a best practice / long term solution for me.
I agree in general, but calling @sloretz random is a bit much perhaps :)
He also announced that repository and those images on Discourse some time ago.