[Bug]: Build failure on ROS 2 Rolling Buildfarm

[Yadunund]

Before proceeding, is there an existing issue or discussion for this?

• I have done a search for similar issues and discussions.

OS and version

Ubuntu 24.04

Open-RMF installation type

Source build

Other Open-RMF installation methods

No response

Open-RMF version or commit hash

main

ROS distribution

Rolling

ROS installation type

Source build

Other ROS installation methods

No response

Package or library, if applicable

No response

Description of the bug

See https://build.ros2.org/view/Rbin_uN64/job/Rbin_uN64__rmf_building_sim_gz_plugins__ubuntu_noble_amd64__binary/179

Steps to reproduce the bug

See https://build.ros2.org/view/Rbin_uN64/job/Rbin_uN64__rmf_building_sim_gz_plugins__ubuntu_noble_amd64__binary/179/console

Expected behavior

No response

Actual behavior

No response

Additional information or screenshots

This package and deps will be removed from the buildfarm to unblock the Rolling sync.

No response

[luca-della-vedova]

This seems to be due to the Qt5 -> Qt6 migration. I would suggest tackling this closer to the next ROS release that will have Jetty as a default Gazebo version, right now it's more likely that people will be building this branch on jazzy or kilted rather than rolling.

[mxgrey]

I'm inclined to agree that the vast majority of people using the main branch will want to work off of jazzy or kilted distros rather than rolling.

However I'm getting spammed with build failure notifications from both GitHub and the build farm. What if we create a rolling branch for rmf_simulation that takes care of the migration to Qt6 and whose CI targets rolling. Then we remove rolling from the CI for main, and we retarget the build farm to use the rolling branch for the rolling distro?

It would diverge from the branch policy that we're using with all the other repos, but I think the exception may be justified because of how disruptive the Qt migration is.

[luca-della-vedova]

There is an option that has been floating my mind for some time that we can also consider.
We have Qt dependencies for out GUI plugins, of which we have 3:

• LightTuning to add and edit lights. I would actually consider removing this since it was a very niche plugin and part of its functionality has been since added to gz-sim Add Light Usercommand and include Light parameters in the componentInspector gazebosim/gz-sim#482
• ToggleFloors to hide / show floors in multifloor buildings. This is a lot more necessary and should be ported.
• ToggleCharging to enable / disable battery drain and change charging behavior, as above it is very useful.

Since the last two plugins are very straightforward (theyr are pretty much a set of checkboxes) I wonder if there is a way to have them compatible with both Qt5 and Qt6, maybe the qml syntax didn't change too much for basic applications and for the source code we could use a CMake check for the version that propagates a define to the source code, together with #ifdef directives.
Again I haven't looked at it but this could be a possible route to avoid disrupting any workflow or changing our branching conventions

[mxgrey]

I'm not familiar with what's needed for migrating from Qt5 -> Qt6, but if there's a path that allows both to be supported without much trouble then that's definitely the way to go.

Pinging @arjo129 and @sauk2 in case there's any insight we can glean from the Gazebo PMC.

[sauk2]

Based on the migration guide - https://gazebosim.org/api/gui/10/migration_qt6.html, users with custom GUI plugins may need to make some updates, but if we don’t have many, the migration should be quick and easy.

[arjo129]

Code-wise migrating from Qt5->Qt6 should be fairly trivial. I think there may need to be minor changes to the QML, but this should be relatively trivial.

I did a quick check, Qt6 is available on Ubuntu Jammy Jellyfish so this should allow us to backport to humble. That being said the bigger issue is gazebo itself. Gazebo on Humble does not support Qt6, so if we want to keep our promise of having main build all the way back to humble, that may not be a possibility without significant CMake-foo.

[mxgrey]

Besides the difficulty of the migration, is there a way to migrate that maintains backwards compatibility with Qt5?

Gazebo on Humble does not support Qt6, so if we want to keep our promise of having main build all the way back to humble, that may not be a possibility without significant CMake-foo.

We only keep that promise for the core libraries. For the simulation and demo libraries we're only maintaining compatibility back to jazzy.

[arjo129]

I'm not sure we have a good way of keeping full backward compatibility between Qt6 and Qt5. We would have to break backward compatibility with Jazzy during this migration.

One could potentially inject a version check in the CMake for the gazebo version and then include the appropriate Qt versions, but this is not a good idea as it injects unnecessary build overhead - not to mention the QML for Qt5 and Qt6 is ever so slightly different.

The general approach in the ros/gazebo ecosystem is to use a bot like mergify to make sure PRs get backported. FWIW, the migration would touch very few files (mostly our toggles and the lighttuning plugin).

That being said, Qt5 is EOL, so we should do the migration for future proofing.

[luca-della-vedova]

I gave a spin to porting ToggleFloors and ToggleCharging to Qt6 and it was actually very straightforward.
I didn't need to change anything in the code itself, all that was needed was a minor update to the qml files to deal with the new leading underscore pointed in the gazebo migration guide, as well as removing an import directive that doesn't work anymore.
I have to look on whether it's possible to change the value of QML at runtime, worst case we can just duplicate it and change in the CMakeLists which qml file gets used depending on which Qt version is being compiled against.

The main remaining question is how to do it at the package.xml / CMakeLists level.

I have seen conditional depends in the past in ros_gz in the package.xml but they seem to be gone now and I'm not sure how they would play with the buildfarm.
A possibility could be to install both qt5 and qt6 then, at the CMakeLists level, check what Gazebo version is installed and use the right Qt version.
Another solution could be to remove the direct Qt dependency altogether and just rely on the fact that gz-gui itself depends on Qt and will pull in the correct version when installed. We could then check the gz-gui version found and set the Qt version to find accordingly.