add 26.04

[k-okada]

~~ @rhaschke could you add https://ros.packages.techfak.net resolute-testing ?~~
Sorry, runing without 'Continue previous build?' checkbox seems fine.

@simonschmeisser thanks! I have fixed the typo

https://github.com/k-okada/ros-builder-action/actions/runs/29391029710/job/87274382453

[rhaschke]

Thanks for pushing this. Did you already verify that all packages build?
I have a few minor remarks.

[rhaschke]

This shouldn't be necessary.

[simonschmeisser]

Thanks for pushing this. Did you already verify that all packages build? I have a few minor remarks.

It seems to fail with catkin already, as a newer CMake min version is needed. Using the modernize-python branch seems to have other issues

https://github.com/simonschmeisser/ros-builder-action/actions/workflows/interactive.yaml

[k-okada]

Thanks for pushing this. Did you already verify that all packages build? I have a few minor remarks.

No, I just want to check by this CI process....

[rhaschke]

It seems to fail with catkin already, as a newer CMake min version is needed.

Yeah. @v4hn and I independently started an effort to fix deprecation issues with catkin a while ago.
I didn't have time to continue yet, and I don't remember the current state.
The best starting point seems to be ros-o/catkin#3

Closing this PR in favor of the new branch resolute.dev.

[rhaschke]

Yeah. @v4hn and I independently started an effort to fix deprecation issues with catkin a while ago.

Both our changes fail to build:

• rhaschke's python-build+pip-install branch:
  https://github.com/ubi-agni/ros-builder-action/actions/runs/29405505980/job/87320008891#step:6:1520
  ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied: '/opt/ros'
• v4hn's modernize-python branch:
  https://github.com/ubi-agni/ros-builder-action/actions/runs/29406045698/job/87321740359#step:6:798
  Error running generator: Failed to resolve rosdep key 'setup_files', aborting.
• Dropping setup_files from catkin's package.xml seems to work:
  https://github.com/ubi-agni/ros-builder-action/actions/runs/29407703498/job/87327144484
  However, many other basic packages run into cmake 3.5 deprecations now.

[simonschmeisser]

Yeah. @v4hn and I independently started an effort to fix deprecation issues with catkin a while ago.

Both our changes fail to build:

* rhaschke's [`python-build+pip-install` branch](https://github.com/ubi-agni/catkin/tree/python-build%2Bpip-install):
  https://github.com/ubi-agni/ros-builder-action/actions/runs/29405505980/job/87320008891#step:6:1520
  `ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied: '/opt/ros'`

* v4hn's [`modernize-python` branch](https://github.com/ros-o/catkin/tree/modernize-python):
  https://github.com/ubi-agni/ros-builder-action/actions/runs/29406045698/job/87321740359#step:6:798
  `Error running generator: Failed to resolve rosdep key 'setup_files', aborting.`

* Dropping `setup_files` from catkin's package.xml **seems to work**:
  https://github.com/ubi-agni/ros-builder-action/actions/runs/29407703498/job/87327144484
  However, many other basic packages run into cmake 3.5 deprecations now.

gemini suggests trying this:

cmake -B build -DCMAKE_POLICY_VERSION_MINIMUM=3.5

[rhaschke]

cmake is called via the bloom-generated debian build rules. Not sure, we can inject such an option.

[rhaschke]

I successfully injected and it actually resolves the cmake version issue.
The next issue is with boost:
https://github.com/ubi-agni/ros-builder-action/actions/runs/29418863170/job/87363919965#step:6:3425

  CMake Warning (dev) at CMakeLists.txt:4 (find_package):
    Policy CMP0167 is not set: The FindBoost module is removed.  Run "cmake
    --help-policy CMP0167" for policy details.  Use the cmake_policy command to
    set the policy and suppress this warning.
  
  This warning is for project developers.  Use -Wno-dev to suppress it.
  
  CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Boost-1.90.0/BoostConfig.cmake:141 (find_package):
    Could not find a package configuration file provided by "boost_system"
    (requested version 1.90.0) with any of the following names:
  
      boost_systemConfig.cmake
      boost_system-config.cmake
  
    Add the installation prefix of "boost_system" to CMAKE_PREFIX_PATH or set
    "boost_system_DIR" to a directory containing one of the above files.  If
    "boost_system" provides a separate development package or SDK, be sure it
    has been installed.
  Call Stack (most recent call first):
    /usr/lib/x86_64-linux-gnu/cmake/Boost-1.90.0/BoostConfig.cmake:262 (boost_find_component)
    /usr/share/cmake-4.2/Modules/FindBoost.cmake:610 (find_package)
    CMakeLists.txt:4 (find_package)

I'm afraid that there are too many incompatibilities in Resolute as we ignored deprecation warnings in Jammy and Noble... Maybe RoboStack is an alternative?

[simonschmeisser]

Robostack and Pixi sound super sexy until you need to debug something and notice there are no debug packages/infos available. They seem to be several development steps in the tooling away from that

I'll see if I can get a few more packages to build

[simonschmeisser]

ros-o/roscpp_core#1 solves the boost system issue

[v4hn]

Thank you for pushing the forward migration!

@rhaschke dropping the setup_files conflict line should indeed be the only change needed for my side. I need this to migrate away from my previous custom setup_files package as catkin is now packaged as well on my side. I did not clean that up yet as it was all work in progress for so long now. Feel free to push a new occult-devel branch or similar without the line. I'll keep a personal fork with it then for my builds.

However, many other basic packages run into cmake 3.5 deprecations now.

This is the main annoyance in the transition due to the design decision in cmake to touch this line every few years even when not needed. I'm still torn whether we should fork and bump the remaining repositories into ros-o for this sole reason (annoying but possible without that much effort) or whether we should inject a -DCMAKE_POLICY_VERSION_MINIMUM=3.16 into the catkin commands for building.
That's what I do manually at the moment and there are no problems with it.
Do you have a preference @rhaschke @simonschmeisser @k-okada ?

boost_systemConfig.cmake

Yes, that affects 39 packages in my local core workspace. system was an empty component for a long time, so it should even be a backward compatible change to drop these lines in the obese branches (and fork where required).

${PYTHON_LIBRARIES}

The other build API change that affects multiple packages is ${PYTHON_LIBRARIES} (at least in Debian testing, I did not explicitly validate resolute yet) which needs manual migration to Python::Python and friends, which affects 5 packages in my local builds.
I plan to push my own overdue changes and set up my ros-o-builder for trixi end of next week, as I push to migrate my labs there until September.

[simonschmeisser]

There seems to be quite some logic behind the scenes in CMake to "preserve" bogus edge cases that once worked. Increasing the minimum number allows it run less of that arcane magic. I can totally understand their motivation to weed out from time to time.

In the same spirit I prefer increasing the version in all repos and forking whatever needed. Most of those repos are "archived" by Them so this would also give back a place to discuss about issues etc. I'll contribute to that as we want our next major release to run on resolute and start working on the migration soon

[v4hn]

allows [cmake to] run less of that arcane magic

There are alternatives to their approach of bug-compatibility between releases. But yes, they invoke a lot of arcane magic that results in any cmake project to be bound by an upper and lower version of cmake SOLELY because of that single line, so that entire git branches are bound SOLELY because of this line. As almost all uses of cmake in ROS are quite basic and do not touch any of these edge-cases, this is nonsense and adds a lot of administrative overhead, specifically to maintain different branches.

Most of those repos are "archived"

My builder currently includes 345 repositories, out of which 88 use ros-o forks and 98 are still in ros/ and ros-* organizations. Several external package maintainers also merge ros-o specific patches into their external repos in noetic-devel, ros1, or even kinetic-devel branches. I would prefer a solution that does not ask them to maintain more branches without good reason. While I do not object to increasing the number of ros-o forks, specifically to get issues/pr sections back, it's wrong to say everything is archived.
If you start forking archived repositories to ros-o, be aware that issues are disabled on github forks by default.

by Them

😄

boost_systemConfig.cmake

Yes, that affects 39 packages in my local core workspace. system was an empty component for a long time, so it should even be a backward compatible change to drop these lines in the obese branches (and fork where required).

I just pushed a sweep addressing this issue throughout the ros-o ecosystem I have access to, and pushing PRs were I do not.

${PYTHON_LIBRARIES}

I still left these out in this first badge of changes, as they should be consistently migrated together with the overall catkin change.