Jazzy migration #628
Jazzy migration #628
Conversation
|
TODO: Fix cppformat in Jazzy |
|
The CI seems to fail due to floating point errors in the team_communication. |
|
I've adjusted the |
starting from `~` instead of using the whole path
to prevent issues when interacting with the repository both from within the container and outside the container, due to permissions not being correct
in `Dockerfile`, because the `updateRemoteUserUID` setting of the devcontainer does not change the `GID` of the `containerUser` dynamically to the one of the host user if the group exists in the container already microsoft/vscode-remote-release#2402. In our case the `containerUser` is set to `bitbots`, because it automatically uses the last `USER` instruction from the `Dockerfile` and the `remoteUser` inherits from `containerUser`. For reference see: microsoft/vscode-remote-release#1155
as with upgrade to jazzy or packages floating point handling seems to have changed slightly
texhnolyze
force-pushed
the
feature/jazzy-ubuntu2404-devcontainer
branch
from
4b8b0e9 to
8ecfb93
Compare
|
TODO after merge: Revert #634 |
to ensure that the CI `colcon test` run works, because with a change to python 3.12 the `unittest` standard library used by default with colcon now exits with an error code of 5 for an empty test suite. See: colcon/colcon-core#678 See: python/cpython#102051
When using the colcon `--symlink-install` flag (as we usually do),
one gets shown the following huge warning for every Python-package:
```
/usr/lib/python3/dist-packages/setuptools/command/develop.py:40: EasyInstallDeprecationWarning: easy_install command is deprecated.
!!
********************************************************************************
Please avoid running ``setup.py`` and ``easy_install``.
Instead, use pypa/build, pypa/installer or other
standards-based tools.
See pypa/setuptools#917 for details.
********************************************************************************
!!
easy_install.initialize_options(self)
---
```
Has been solved by: ros2/ros2#1577 (comment)
This resolves the following cmake warning, that seems to appear when pybind is in use: ``` lto-wrapper: warning: using serial compilation of 2 LTRANS jobs lto-wrapper: note: see the ‘-flto’ option documentation for more information ```
``` --- stderr: bitbots_webots_sim CMake Warning at /opt/ros/jazzy/share/gazebo_msgs/cmake/gazebo_msgs-extras.cmake:6 (message): This gazebo_msgs package hosts messages designed initially for Gazebo Classic which is not available on ROS 2 Jazzy which is unavailable on ROS 2 Jazzy. The new Gazebo uses the ros_gz bridge message vailable at:https://github.com/gazebosim/ros_gz/tree/ros2/ros_gz_bridge#bridge-communication-between-ros-and-gazebo To avoid this warning and use this Gazebo Classic messages anyway you can use flag -DIGNORE_GAZEBO_MSGS_WARNING Call Stack (most recent call first): /opt/ros/jazzy/share/gazebo_msgs/cmake/gazebo_msgsConfig.cmake:41 (include) CMakeLists.txt:18 (find_package) ```
``` CMake Warning (dev) at CMakeLists.txt:15 (find_package): Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules are removed. Run "cmake --help-policy CMP0148" 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. ```
|
At this point, my devcontainer (built 6 days ago) only has a small warning on Now, I noticed that my bitbots_main was not clean. Therefore, I recloned and rebuilt the devcontainer. Finally, I can see the same compile failures and warnings from the CI! |
|
Since the latest apt-release, the CI and local builds fail because Similar issues appear with other components, but not as errors.
Once this is done, all issues are resolved (except the minor one listed in my comment above)! EDIT: I have migrated everything to |
|
I have opened an issue #642 to turn warnings as errors back on. |
|
Now, only this warning remains at compilation. Nothing has yet been executed. We should test thoroughly in sim and on robot.
|
We can also just build this from source for now by adding it to lib |
This has been addressed in #643 |
I know, but that's more effort and we get unclean lib/ but I guess, that would be resolved with a make fresh libs... Btw, do you know, why we had |
I think it was not available in the package sources when we started out with ros2 or something like this. |
|
TODO: revert #646 on this branch if it is merged into main and this branch is updated. These are iron specific fixes. Edit: Done |
|
The second merge was weird but needed for some reason |
No description provided.