Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jan 2024 rebuild #124

Merged
merged 23 commits into from
Feb 2, 2024
Merged

Jan 2024 rebuild #124

merged 23 commits into from
Feb 2, 2024

Conversation

Tobias-Fischer
Copy link
Contributor

No description provided.

@Tobias-Fischer
Copy link
Contributor Author

Hi @traversaro - do you happen to know which ignition versions humble is compatible with? I get some compatibility issues with the various ignition libraries, I think the current mapping isn't correct / up-to-date.

@Tobias-Fischer
Copy link
Contributor Author

Actually, it might be because I didn't take the latest protobuf migration into account here; but they were applied in the conda-forge libignition feedstocks.

@traversaro
Copy link
Member

Hi @traversaro - do you happen to know which ignition versions humble is compatible with? I get some compatibility issues with the various ignition libraries, I think the current mapping isn't correct / up-to-date.

From https://gazebosim.org/docs/fortress/ros_installation it seems Gazebo Fortress, from https://github.com/gazebo-tooling/gazebodistro/blob/master/collection-fortress.yaml the packages are:

  • libignition-gazebo6
  • libignition-gazebo5
  • libignition-math6

and so on so forth.

@Tobias-Fischer
Copy link
Contributor Author

@wolfv - I'm running into this again: RuntimeError: Could not find output with name ros2-distro-mutex - do you have any idea what this is about? I've had it locally as well, but somehow it went away .. I thought a weak run_export did the job, but it must have been something else.

@traversaro
Copy link
Member

Actually, it might be because I didn't take the latest protobuf migration into account here; but they were applied in the conda-forge libignition feedstocks.

I am not sure which problems are you seeing, but actually something that I did was to disable Windows in some Ignition Fortress-related packages, see:

If we actually need it in Ros Humble, I can look into re-enabling them. However, Ignition Fortress never worked fine on Windows, so I do not think it makes a lot of sense to try to fix compilation if then runtime will never work.

@Tobias-Fischer
Copy link
Contributor Author

@traversaro - I think I resolved the ignition issues by bumping the protobuf/abseil pinnings, thanks for checking!

I'm now struggling locally on osx-arm64 building cartographer-ros. It seems that clang doesn't like the mutex macros:

FAILED: CMakeFiles/cartographer_ros.dir/src/metrics/family_factory.cpp.o 
$BUILD_PREFIX/bin/arm64-apple-darwin20.0.0-clang++ -DBOOST_ATOMIC_DYN_LINK -DBOOST_ATOMIC_NO_LIB -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_FILESYSTEM_NO_LIB -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_IOSTREAMS_NO_LIB -DBOOST_SYSTEM_DYN_LINK -DBOOST_SYSTEM_NO_LIB -DDEFAULT_RMW_IMPLEMENTATION=rmw_cyclonedds_cpp -DGFLAGS_IS_A_DLL=0 -DGLOG_CUSTOM_PREFIX_SUPPORT -DPROTOBUF_USE_DLLS -DTINYXML2_IMPORT -Dcartographer_ros_EXPORTS -I$SRC_DIR/ros-humble-cartographer-ros/src/work/include -I$PREFIX/lib/urdfdom_headers/cmake/../../../include/urdfdom_headers -isystem $PREFIX/include/pcl-1.13 -isystem $PREFIX/include/eigen3 -isystem $PREFIX/include -isystem $PREFIX/include/builtin_interfaces -isystem $PREFIX/include/cartographer_ros_msgs -isystem $PREFIX/include/geometry_msgs -isystem $PREFIX/include/nav_msgs -isystem $PREFIX/include/rclcpp -isystem $PREFIX/include/sensor_msgs -isystem $PREFIX/include/std_msgs -isystem $PREFIX/include/tf2 -isystem $PREFIX/include/tf2_eigen -isystem $PREFIX/include/tf2_msgs -isystem $PREFIX/include/tf2_ros -isystem $PREFIX/include/visualization_msgs -isystem $PREFIX/include/rosbag2_cpp -isystem $PREFIX/include/rosbag2_storage -isystem $PREFIX/include/urdf -isystem $PREFIX/include/urdfdom -isystem $PREFIX/include/message_filters -isystem $PREFIX/include/pcl_msgs -isystem $PREFIX/include/rosidl_runtime_c -isystem $PREFIX/include/rcutils -isystem $PREFIX/include/rosidl_typesupport_interface -isystem $PREFIX/include/rosidl_runtime_cpp -isystem $PREFIX/include/rosidl_typesupport_fastrtps_cpp -isystem $PREFIX/include/rmw -isystem $PREFIX/include/rosidl_typesupport_fastrtps_c -isystem $PREFIX/include/rosidl_typesupport_introspection_c -isystem $PREFIX/include/rosidl_typesupport_introspection_cpp -isystem $PREFIX/include/ament_index_cpp -isystem $PREFIX/include/libstatistics_collector -isystem $PREFIX/include/rcl -isystem $PREFIX/include/rcl_interfaces -isystem $PREFIX/include/rcl_logging_interface -isystem $PREFIX/include/rcl_yaml_param_parser -isystem $PREFIX/include/tracetools -isystem $PREFIX/include/rcpputils -isystem $PREFIX/include/statistics_msgs -isystem $PREFIX/include/rosgraph_msgs -isystem $PREFIX/include/rosidl_typesupport_cpp -isystem $PREFIX/include/rosidl_typesupport_c -isystem $PREFIX/include/rclcpp_action -isystem $PREFIX/include/action_msgs -isystem $PREFIX/include/unique_identifier_msgs -isystem $PREFIX/include/rcl_action -isystem $PREFIX/include/pluginlib -isystem $PREFIX/include/class_loader -isystem $PREFIX/include/urdf_parser_plugin -isystem $PREFIX/include/urdfdom_headers -fdiagnostics-color=always -O3 -DNDEBUG -std=gnu++17 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.15 -fPIC -Wall -Wextra -MD -MT CMakeFiles/cartographer_ros.dir/src/metrics/family_factory.cpp.o -MF CMakeFiles/cartographer_ros.dir/src/metrics/family_factory.cpp.o.d -o CMakeFiles/cartographer_ros.dir/src/metrics/family_factory.cpp.o -c $SRC_DIR/ros-humble-cartographer-ros/src/work/src/metrics/family_factory.cpp
In file included from $SRC_DIR/ros-humble-cartographer-ros/src/work/src/metrics/family_factory.cpp:17:
In file included from $SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/family_factory.h:24:
In file included from $SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/internal/counter.h:21:
$SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/internal/gauge.h:74:16: error: expected ';' at end of declaration list
  double value_ GUARDED_BY(mutex_);
               ^
               ;
In file included from $SRC_DIR/ros-humble-cartographer-ros/src/work/src/metrics/family_factory.cpp:17:
In file included from $SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/family_factory.h:25:
In file included from $SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/internal/family.h:26:
$SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/internal/histogram.h:53:37: error: expected ';' at end of declaration list
  std::vector<double> bucket_counts_ GUARDED_BY(mutex_);
                                    ^
                                    ;
$SRC_DIR/ros-humble-cartographer-ros/src/work/include/cartographer_ros/metrics/internal/histogram.h:54:14: error: expected ';' at end of declaration list
  double sum_ GUARDED_BY(mutex_);
             ^
             ;
3 errors generated.

Do you have any idea how to fix it?

@Tobias-Fischer
Copy link
Contributor Author

Actually, there is a ignition/gazebo related question as well:
It seems that https://github.com/conda-forge/gazebo-feedstock/blob/main/recipe/meta.yaml still uses ignition-dome. I think that clashes with the fortress packages in ros-humble somehow. Could this be?

@Tobias-Fischer
Copy link
Contributor Author

All good, it was just a pinning issue. Sorry for the noise. I think on osx-arm64, I locally should very shortly have a full rebuild.

@Tobias-Fischer
Copy link
Contributor Author

@wolfv - I'm running into this again: RuntimeError: Could not find output with name ros2-distro-mutex - do you have any idea what this is about? I've had it locally as well, but somehow it went away .. I thought a weak run_export did the job, but it must have been something else.

For future reference - this was solved by installing conda-build=3.27 (3.28 is broken)

@Tobias-Fischer
Copy link
Contributor Author

Looking pretty good now, except for the Windows builds.

Needs conda-forge/graphicsmagick-feedstock#30

@traversaro
Copy link
Member

Interestingly, by local build failed with:

Cloning into bare repository 'C:\Users\straversaro\micromamba\envs\testpr_env\conda-bld\git_cache\github.com\ros2-gbp\moveit_resources-release.git'...
remote: Enumerating objects: 12383, done.
remote: Counting objects: 100% (7783/7783), done.
remote: Compressing objects: 100% (5630/5630), done.Receiving objects:  13% (1610/12383)
remote: Total 12383 (delta 2285), reused 7278 (delta 1800), pack-reused 4600
Receiving objects: 100% (12383/12383), 33.09 MiB | 8.51 MiB/s, done.
Resolving deltas: 100% (3890/3890), done.
HEAD detached at release/humble/moveit_plugins/2.5.5-1
nothing to commit, working tree clean

b'git-lfs/3.4.0 (GitHub; windows amd64; go 1.20.6; git d06d6e9e)'
fetch: 3 objects found, done.
fetch: Fetching all references...
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
error: failed to fetch some objects from 'https://github.com/ros2-gbp/moveit_resources-release.git/info/lfs'
fatal: destination path 'C:\Users\straversaro\micromamba\envs\testpr_env\conda-bld\git_cache\github.com\ros2-gbp\moveit_resources-release.git' already exists and is not an empty directory.
Traceback (most recent call last):
  File "C:\Users\straversaro\micromamba\envs\testpr_env\Lib\site-packages\conda_build\source.py", line 322, in git_mirror_checkout_recursive
    git_lfs_fetch(git, mirror_dir, stdout, stderr)
  File "C:\Users\straversaro\micromamba\envs\testpr_env\Lib\site-packages\conda_build\source.py", line 215, in git_lfs_fetch
    check_call_env(
  File "C:\Users\straversaro\micromamba\envs\testpr_env\Lib\site-packages\conda_build\utils.py", line 445, in check_call_env
    return _func_defaulting_env_to_os_environ("call", *popenargs, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\straversaro\micromamba\envs\testpr_env\Lib\site-packages\conda_build\utils.py", line 436, in _func_defaulting_env_to_os_environ
    subprocess.check_call(_args, **kwargs)
  File "C:\Users\straversaro\micromamba\envs\testpr_env\Lib\subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['C:\\Program Files\\Git\\cmd\\git.exe', 'lfs', 'fetch', 'origin', '--all']' returned non-zero exit status 2.

During handling of the above exception, another exception occurred:

However, the git clone of the repo locally works fine.

@traversaro
Copy link
Member

For reference, the Windows error in CI is in ament-cmake-core:

2024-01-22T06:07:59.4714489Z CMake Error: File C:/Users/runneradmin/micromamba/envs/testpr_env/conda-bld/ros-0_1705900595182/_h_env/Lib/site-packages/ament_package-0.14.0-py3.11.egg/ament_package/template/package_level/local_setup.bat.in does not exist.

probably due to ament-package is built, probably due to this error:

2024-01-22T06:06:32.8989098Z FINDSTR: Cannot open setup.cfg

See #41 for a related issue.

@traversaro
Copy link
Member

probably due to ament-package is built, probably due to this error:

2024-01-22T06:06:32.8989098Z FINDSTR: Cannot open setup.cfg

Actually this is unrelated, simply that specific repo does not have any setup.cfg .

@0wu
Copy link

0wu commented Jan 26, 2024

Thanks for bringing patches up to date!
I'd like to feedback build failures for this patch
https://github.com/RoboStack/ros-humble/pull/124/files#diff-541d0859e1a716f06147836348be2652e6793c0f203ca3f5b90c0c2fa5eaf940R31-R68
which is not python3.8 compatible. import_resources.files doesn't exist on py38.

@Tobias-Fischer
Copy link
Contributor Author

Hi @0wu - do I understand you correctly that you locally build for Python 3.8? Unfortunately we don’t have capacity to support multiple Python versions, but you are more than welcome to send a PR which ensures compatibility with multiple Python versions.

@0wu
Copy link

0wu commented Jan 28, 2024

Hi @0wu - do I understand you correctly that you locally build for Python 3.8? Unfortunately we don’t have capacity to support multiple Python versions, but you are more than welcome to send a PR which ensures compatibility with multiple Python versions.

PR added - #127

add python38 compatbility to rebuilt_2024 branch
@Tobias-Fischer Tobias-Fischer merged commit 65004cf into main Feb 2, 2024
2 of 5 checks passed
@Tobias-Fischer Tobias-Fischer deleted the rebuild_2024 branch February 2, 2024 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants