robotpkg

Also, it looks that we could switch the default PREFER.octomap to
system, as octomap >= 1.6 is available at least in in ubuntu

= 16.04, debian >= 9, fedora 31, and Arch.

Yes. I kept the robotpkg default for the few distributions that don't
have it.

The PREFER change might be causing issues on the buildfarm, eg. if the system package is not actually available on the system. It looks like this is the case for Debian 10.

But for Debian 9, Fedora 31, Ubuuntu 16.04 & 18.04, another issue is that the package is still installed by robotpkg:
http://robotpkg.openrobots.org/rbulk/robotpkg-wip/wip/talos-torque-control/talos-torque-control-1.1.0/Ubuntu-18.04-x86_64/bulk.html

I don't exactly understand what is happening, here, but I guess you have more clues :)

On Thursday 16 Dec 2021, at 09:45, Guilhem Saurel wrote:

The PREFER change might be causing issues on the buildfarm, eg. if
the system package is not actually available on the system. It looks
like this is the case for Debian 10.

Yes, I installed it.

But for Debian 9, Fedora 31, Ubuuntu 16.04 & 18.04, another issue is
that the package is still installed by robotpkg:
http://robotpkg.openrobots.org/rbulk/robotpkg-wip/wip/talos-torque-control/talos-torque-control-1.1.0/Ubuntu-18.04-x86_64/bulk.html

This is usually caused by old packages not being properly
rebuilt. Normaly, after a change like this, all packages depending on
octomap should have their revision bumped.