[TASK] Update to Ubuntu 26.04 LTS (Resolute Raccoon)

[mmmarinho]

Add version for Ubuntu resolute

Link: https://documentation.ubuntu.com/release-notes/26.04/

List of tasks

• Update PPA in launchpad.net
  • Update libdqrobotics (@mmmarinho). Solved in 674eae4.
  • Update dqrobotics-interface-json11 (@mmmarinho)
  • Update dqrobotics-interface-qpoases (@mmmarinho)
• Update PyPI https://pypi.org/project/dqrobotics/ (@mmmarinho)
• Update Actions
  • Python (@mmmarinho). This depends on how quickly the 26.04 image will be available.
• Update https://github.com/Adorno-Lab/docker_recipes (@juanjqo) (Or transfer the docker image to dqrobotics to track it here)

Tasks pending adoption, otherwise optional

• Update PPA in launchpad.net
  • dqrobotics-interface-coppeliasim
  • dqrobotics-interface-coppeliasim-zmq
  • dqrobotics-interface-cplex

[mmmarinho]

PPA Progress

amd64 failing: https://launchpadlibrarian.net/855664069/buildlog_ubuntu-resolute-amd64.libdqrobotics_20.04.0-0~202505300421~ubuntu26.04.1_BUILDING.txt.gz

Relevant chunk below. Compatibility with newer versions of launchpad.net lost?

Command: dpkg-buildpackage --sanitize-env -us -uc -mLaunchpad Build Daemon <buildd@lcy02-amd64-069.buildd> -b -rfakeroot
dpkg-buildpackage: info: source package libdqrobotics
dpkg-buildpackage: info: source version 20.04.0-0~202505300421~ubuntu26.04.1
dpkg-buildpackage: info: source distribution resolute
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
rm -f build
rm -rf build_dir
 debian/rules binary
# nothing to be done
cd build_dir; cmake -P cmake_install.cmake
/bin/sh: 1: cd: can't cd to build_dir
CMake Error: Not a file: cmake_install.cmake
CMake Error: Error processing file: cmake_install.cmake
make: *** [debian/rules:19: binary-arch] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2
--------------------------------------------------------------------------------
Build finished at 2026-04-07T12:28:46Z

[juanjqo]

Hi @mmmarinho and @bvadorno.

I think the Docker image for DQ Robotics should be moved from Adorno-Lab/docker_recipes to a DQ Robotics workspace. What do you think? If you agree, may I create the dqrobotics/docker repository for this purpose?

Kind regards,

Juancho

[bvadorno]

Thanks, @mmmarinho. Updating the PPA is substantial housekeeping.

I am not planning on supporting dqrobotics-interface-vrep/coppeliasim going forward. Anyone please feel free to adopt this if they want.

Just for the sake of completeness, could you include a link to the alternative? Does it already include a deprecation message indicating that it's been phased out?

[ ] Same for dqrobotics-interface-cplex as I don't suppose we have much of a user base.

We've used it a lot in the past. Again, could you please include a link to the alternative? Does it already include a deprecation message indicating that it's been phased out?

Many thanks,
Bruno

[bvadorno]

Hi @mmmarinho and @bvadorno.

I think the Docker image for DQ Robotics should be moved from Adorno-Lab/docker_recipes to a DQ Robotics workspace. What do you think? If you agree, may I create the dqrobotics/docker repository for this purpose?

Kind regards,

Juancho

If it's of interest to the general community, yes, you may. However, the documentation needs improvement because it's impossible for anyone who doesn't already know the repository's purpose to understand what it is for.

Kind regards,
Bruno

[mmmarinho]

Hi Bruno,

Just for the sake of completeness, could you include a link to the alternative? Does it already include a deprecation message indicating that it's been phased out?
We've used it a lot in the past. Again, could you please include a link to the alternative? Does it already include a deprecation message indicating that it's been phased out?

Thanks for the reply. Please let me split the answer for readability.

Looking for maintainers

For the two packages I mentioned, I wouldn't say they are "deprecated" yet. It will depend on what happens now. If there's a decision to deprecate them we could archive the repository (see cpp-interface-vrep ) and add a similar deprecation message.

The code for these two packages should be working fine (until shown otherwise) and if someone can maintain them, it wouldn't be a problem. I'm not a good candidate because I'm not using them. It could be a good time for someone to step up for some of these if they are actively using them.

• cpp-interface-cplex. Last updated 4 years ago. Likely to be working. We would need someone to set up a GitHub actions workflow with CPLEX to make this more easily maintainable.

• cpp-interface-coppeliasim-zmq Unfortunately for me (and many of us) it's not fit for purpose. As I have flagged it over a year ago ([BUG] Performance issues with ZMQ cpp-interface-coppeliasim-zmq#4) and we have observed in a few projects, the performance is not scalable. It could be useful in some cases so it could be maintainable if someone is willing and available to do it.

Alternatives

Alternative for cpp-interface-cplex.

• The one I can maintain is cpp-interface-qpoases. I would say this package is a "proper" alternative for dqrobotics-interface-cplex with a more permissive license. It might be useful to maintain dqrobotics-interface-cplex if anyone wants to compare solvers for example. Functionality-wise we are well served by cpp-interface-qpoases.

Alternative for cpp-interface-coppeliasim-zmq

• The one I can maintain is sas_robot_driver_coppeliasim. In contrast with the above, I would not call this a "proper" alternative. sas_robot_driver_coppeliasim needs sas and by consequence ROS2, so it is less general than cpp-interface-coppeliasim-zmq. However, it's a price to pay to have a scalable interface.

Adopting a package

Apologies if we already formalised this somewhere. I'm supposing we didn't yet. To give an idea of what I mean by "adopting", this is different from coding the functionality of the package (although preferably the person would do both). It's mostly:

• Making sure it's compiled properly in the PPA and is sufficiently tested. See the debian folder in the respective repository and its launchpad.net page.
• Making sure it's compiled properly in the GitHub actions (when applicable) and sufficiently tested. This is more pressing for the Python version. This means maintaining the GitHub workflow and the PyPI page.

Workload

Unfortunately there is always a few problems to solve when updating the package to compile in a new version of Ubuntu/Python. A taste of the load:

• Every two years we have a new Ubuntu LTS
  - The GitHub actions image lags behind by an un specified amount, usually waiting for Azure availability.
• Every year a new Python version.
  - Update pybind11 if needed
• Launchpad.net is difficult to work with but stable.
• GitHub actions is an easy system to work with but changes frequently and workflows break.

Honorable mention

The repository below was archived about one year ago. It implemented the remoteAPI which has been deprecated by Coppelia Robotics.

• cpp-interface-vrep

Kind regards,
Murilo

[mmmarinho]

Edit: solved in 674eae4

Some information on this before I lose track.

PPA Progress

amd64 failing: https://launchpadlibrarian.net/855664069/buildlog_ubuntu-resolute-amd64.libdqrobotics_20.04.0-0~202505300421~ubuntu26.04.1_BUILDING.txt.gz

It's not clear why launchpad.net is not calling build for me now. It is still calling it normally in the older versions of Ubuntu.

This might be related to either a change in dpkg-buildpackage or how it's called (although it looks the same):

• In Noble:
  • Command: dpkg-buildpackage --sanitize-env -us -uc -mLaunchpad Build Daemon <buildd@lcy02-amd64-013.buildd> -b -rfakeroot
• In Resolute
  • Command: dpkg-buildpackage --sanitize-env -us -uc -mLaunchpad Build Daemon <buildd@lcy02-amd64-075.buildd> -b -rfakeroot

One quick path is to not rely on build but it's dangerous as I've got no idea of why this has been dropped.

Another thing to consider is compat. But I'll need some more information before committing.

Possible culprit

From the documentation of dpkg-buildpackage. In 674eae4 I added Dockerfiles to test this locally and updated debian/rules.

Default build targets
       dpkg-buildpackage is using the build-arch and build-indep targets
       since dpkg 1.16.2.  Before dpkg 1.22.7, there was code to try to
       detect the missing targets and fallback on the build target.
       Those targets are thus mandatory.