#2 ROS Fedora 30 and rawhide packages were built for Fedora 27
Closed 2 years ago by thofmann. Opened 4 years ago by lukehutchison.

The ROS Fedora 30 and rawhide packages were built for Fedora 27. e.g.:

https://copr-be.cloud.fedoraproject.org/results/thofmann/ros/fedora-30-x86_64/00574315-ros-kinetic-cpp_common/

This version is also based on Kinetic, which is 3 years old now:

http://wiki.ros.org/Distributions#Release_Schedule

Short-term, would you be able to please re-build the Fedora 30 packages to be compatible with Fedora 30 rather than Fedora 27, and if possible, also update the ROS version to Melodic?

Long-term, it would be great to have ROS 2 packages available too, since a lot of work in the ROS community is going into developing ROS 2:

https://index.ros.org/doc/ros2/Releases/

Thank you!


I think you misunderstand the COPR web interface: The SRPM has been built on Fedora 27, but the package has been built in the buildroot of the respective release. But it's true that there are only a few packages available on Fedora Rawhide and F30, because of the removal of python2.

Updating to python3 and a newer ROS release is on my agenda, but it does require some work. Pull requests are welcome.

Ah, thanks for explaining, I didn't understand why there were so few packages for F30/rawhide.

Honestly I'd love to help, and I really need to get this working, but I don't know where to start. Could you please give me a rough outline of the work that needs to be done, how to build the current system, what would likely need to be done to upgrade to Python 3, etc.? I'll try to spend some time on this this week, if you can give me sufficient pointers to get started. (I'm an experienced software engineer, but know very little about ROS at this point, and have only a little experience building RPMs.)

But it's true that there are only a few packages available on Fedora Rawhide and F30, because of the removal of python2

It looks like there's still a python2 package for F30, albeit maybe not installed by default?

python2-2.7.16-2.fc30.x86_64

I'm having issues using the rosfed.py script: "./rosfed.py -r desktop_full" gives "KeyError: 'cmake'". I installed cmake, and I tried separately calling "./rosfed.py cmake", but that didn't solve the issue.

Additionally the instructions seem out of sync with the code, since the "--copr-project-id" argument is not recognized by rosfed.py.

The traceback for "KeyError: 'cmake'" is:

Generating Spec file for desktop_full.
./rosfed.py:65: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
common_config = yaml.load(open('cfg/common.yaml'))
./rosfed.py:70: YAMLLoadWarning: calling yaml.load() without Loader=... is deprecated, as the default Loader is unsafe. Please read https://msg.pyyaml.org/load for full details.
open('cfg/{}.yaml'.format(self.name), 'r'))
Generating Spec file for perception.
Generating Spec file for simulators.
Generating Spec file for desktop.
Generating Spec file for catkin.
Traceback (most recent call last):
File "./rosfed.py", line 97, in compute_dependencies
self.distro_info.get_release_package_xml(pkg)
File "/usr/local/lib/python3.7/site-packages/rosdistro/distribution.py", line 66, in get_release_package_xml
pkg = self._distribution_file.release_packages[pkg_name]
KeyError: 'cmake'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "./rosfed.py", line 104, in compute_dependencies
['distro_names'][pkg]
KeyError: 'cmake'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "./rosfed.py", line 437, in <module>
main()
File "./rosfed.py", line 301, in main
args.destination)
File "./rosfed.py", line 362, in generate_spec_files
ros_pkg = RosPkg(name=packages[i], distro=distro)
File "./rosfed.py", line 85, in init
self.compute_dependencies()
File "./rosfed.py", line 109, in compute_dependencies
get_system_package_name(pkg, self.rosdistro)
File "./rosfed.py", line 33, in get_system_package_name
stdout=subprocess.PIPE
File "/usr/lib64/python3.7/subprocess.py", line 472, in run
with Popen(popenargs, *kwargs) as process:
File "/usr/lib64/python3.7/subprocess.py", line 775, in init
restore_signals, start_new_session)
File "/usr/lib64/python3.7/subprocess.py", line 1522, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'rosdep': 'rosdep'

Next question -- I decided to skip trying to use rosfed.py, and just use the spec files that have already been generated and added to the repository. Is there any way to just build all of them at once, in topological dependency order, also fetching any fc30 devel packages automatically as needed? I am trying to do this by hand, and every time I try to bulid a package, it depends upon something else that is not yet built, and/or devel packages that have not yet been installed.

I tried using yum-builddep spec/* , but this fails, since some of the spec files depend upon the built RPM from other spec files...

I tried using copr-build.py, and ended up with:

./copr_build.py --copr-project ros --spec-dir specs ros-kinetic-desktop_full
Traceback (most recent call last):
  File "./copr_build.py", line 224, in <module>
    main()
  File "./copr_build.py", line 210, in main
    for chroot in args.chroot:
TypeError: 'NoneType' object is not iterable

Thanks for working on this! Directly using copr-build.py won't work because the dependencies have changed. Not sure where the key error comes from. I'm currently travelling (RoboCup in Sydney), I'll have a closer look next week.

I realized that the 'NoneType' object is not iterable error came from failing to specify one of the --copr-* switches (they were marked with square brackets in the commandline help, so I thought they were optional, and they are not). Now I get:

$ ./copr_build.py --copr-owner lukehutchison --copr-project ros --chroot fedora-30-x86_64 --spec-dir specs/ ros-kinetic-desktop_full
Building specs/ros-kinetic-desktop_full.spec for chroot fedora-30-x86_64
Building /home/luke/rpmbuild/SRPMS/ros-kinetic-desktop_full-1.3.2-5.fc30.src.rpm for project lukehutchison/ros with chroot fedora-30-x86_64
Waiting for 1 build(s) to complete...
Traceback (most recent call last):
  File "./copr_build.py", line 224, in <module>
    main()
  File "./copr_build.py", line 221, in main
    wait_for_completion=True)
  File "./copr_build.py", line 68, in build_spec
    return self.build_srpm(chroot, srpm, wait_for_completion)
  File "./copr_build.py", line 88, in build_srpm
    self.wait_for_completion([build])
  File "./copr_build.py", line 178, in wait_for_completion
    finished = wait(builds)
NameError: name 'wait' is not defined

If I add to copr_build.py the line from copr.v3.helpers import wait, then the code runs, but sits waiting for an rpmbuild process to finish, and there is no rpmbuild process even running (so it waits forever).

I'm currently travelling (RoboCup in Sydney), I'll have a closer look next week.

Thanks!

I see where your interest in ROS comes from :-)

So after another set of patches, I finally managed to rebuild the desktop_full melodic stack for Fedora 30 and python3. The ros distro is no longer part of the package name (e.g., it's ros-desktop_full, not ros-melodic-desktop_full), the ROS distro is encoded in the package version instead. However, all packages provides the corresponding ros-melodic-$pkg name, so installing ros-melodic-desktop_full should do the same.

The moveit and move_base stacks are next.

I'd appreciate if you could test:

$ dnf copr enable thofmann/ros-testing
$ dnf install ros-desktop_full

Thanks!

Incredible, thank you!

I had a time crunch, and after spending a week unsuccessfully trying to cobble something together on Fedora I had to switch to Ubuntu so I could have a working system before I left for a conference. I'm traveling now with only Ubuntu on my laptop, but I will be able to test this when I get back in a couple of weeks.

One of the biggest set of recurring issues I kept running into though were issues with compatibility between ROS and the distro-installed versions of Google libraries (protobuf 3; gmock/gtest, which is now googletest; etc.) while trying to build packages (and actually I have had issues with those libraries even on Ubuntu). That's the first set of issues I would want to test. Do your packages work with Fedora system packages for these Google libraries, or do they compile their own snapshot?

I'll also try building cartographer_ros with these packages when I get back, unless you beat me to it and decide to add Cartographer and related libraries (Ceres etc.) to the set of Fedora ROS packages.

I came back to start looking at ROS on Fedora again, using your ros-testing repo. I will document issues here as I run into them. First thing I hit:

# pkg-config --cflags rosbag
Package rosbag was not found in the pkg-config search path.
Perhaps you should add the directory containing `rosbag.pc'
to the PKG_CONFIG_PATH environment variable
Package 'rosbag', required by 'virtual:world', not found

# rpm -ql ros-rosbag-devel | grep '\.pc$'
/usr/lib64/ros/lib/pkgconfig/rosbag.pc

# pkg-config --cflags /usr/lib64/ros/lib/pkgconfig/rosbag.pc
-I/usr/lib64/ros/include 

I also get a runtime error for any compiled binary, since /usr/lib64/ros/lib is not in LD_LIBRARY_PATH.

Well, you need to source /usr/lib64/ros/setup.bash (if you use bash).

I could do this automatically but I decided not to, as I don't want to clutter the environment if a user does not use ROS.

Sorry, I should have clarified. I am trying to compile against the rosbag library for non-Catkin code. Having the headers and libraries in nonstandard locations seems to screw up a lot of toolchains (eg. I'm wrestling to get CDT to use these locations, and failing). Why are the headers and libraries in their own non-system dirs? Is that necessary for ROS?

Sorry, I should have clarified. I am trying to compile against the rosbag library for non-Catkin code. Having the headers and libraries in nonstandard locations seems to screw up a lot of toolchains (eg. I'm wrestling to get CDT to use these locations, and failing). Why are the headers and libraries in their own non-system dirs? Is that necessary for ROS?

Yes, for two reasons:
1. ROS packages are terrible with sonames, many ROS libraries do not have proper sonames at all or do not bump the soname with incompatible updates. Such a library cannot be in %{_libdir}, as this would be against the packaging guidelines.
2. Some ROS packages provide the same libraries as non-ROS versions of the package, which causes conflicts with existing Fedora packages. Again, this would be against the packaging guidelines.

What kinds of issues are you facing exactly? If CDT can't find those libraries/headers because they are in a non-standard location, that's a limitation of CDT (I remember this was an issue I had with all kinds of code, which is why I don't use CDT anymore).

I abandoned CDT years ago too, but I heard it improved a lot, so I'm giving it another shot.

The current issue is that (with the right pkg-config parameters) even though the editor and compiler can find the rosbag/bag.h header file, there is an error when trying to use anything from within the header file, eg. rosbag::Bag. I'm not totally sure what's even going on there.

rosbag and associated projects (rosbag_storage etc.), and maybe other parts of ros_comm/tools, arguably should be built in standard locations, because they are actually designed for use as standalone libraries either from within or from outside ROS. For rosbag in particular, you often want to postprocess bag files outside the ROS environment, and being able to compile against and link to that library easily is important.

When running catkin_make on a new (empty) ~/catkin_ws dir, I get:

-- Could NOT find PY_em (missing: PY_EM) 
CMake Error at /usr/lib64/ros/share/catkin/cmake/empy.cmake:29 (message):
  Unable to find either executable 'empy' or Python module 'em'...  try
  installing the package 'python-empy'
Call Stack (most recent call first):

However python3-empy is already installed. I have to install python2-empy to fix the problem.

rosbag and associated projects (rosbag_storage etc.), and maybe other parts of ros_comm/tools, arguably should be built in standard locations, because they are actually designed for use as standalone libraries either from within or from outside ROS. For rosbag in particular, you often want to postprocess bag files outside the ROS environment, and being able to compile against and link to that library easily is important.

Works for me, rosbag.cpp:

#include <rosbag/bag.h>

int main(int argc, char **argv) {
  rosbag::Bag bag;
}

Which compiles without problems and links correctly:

$ g++ $(pkg-config --cflags --libs rosbag) rosbag.cpp; echo $?
0
$ ldd a.out
    linux-vdso.so.1 (0x00007ffde6f73000)
    librosbag.so => /usr/lib64/ros/lib/librosbag.so (0x00007f24c6bdc000)
    librosbag_storage.so => /usr/lib64/ros/lib/librosbag_storage.so (0x00007f24c6b47000)
    libconsole_bridge.so.0.3 => /lib64/libconsole_bridge.so.0.3 (0x00007f24c6ae1000)
    libboost_date_time.so.1.69.0 => /lib64/libboost_date_time.so.1.69.0 (0x00007f24c6acd000)
    libboost_filesystem.so.1.69.0 => /lib64/libboost_filesystem.so.1.69.0 (0x00007f24c6ab0000)
    libboost_program_options.so.1.69.0 => /lib64/libboost_program_options.so.1.69.0 (0x00007f24c6a2a000)
    libboost_regex.so.1.69.0 => /lib64/libboost_regex.so.1.69.0 (0x00007f24c692d000)
    libboost_system.so.1.69.0 => /lib64/libboost_system.so.1.69.0 (0x00007f24c6928000)
    libtinyxml2.so.7 => /lib64/libtinyxml2.so.7 (0x00007f24c690f000)
    libclass_loader.so => /usr/lib64/ros/lib/libclass_loader.so (0x00007f24c68e1000)
    libboost_thread.so.1.69.0 => /lib64/libboost_thread.so.1.69.0 (0x00007f24c68b3000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f24c6892000)
    libboost_chrono.so.1.69.0 => /lib64/libboost_chrono.so.1.69.0 (0x00007f24c6881000)
    libboost_atomic.so.1.69.0 => /lib64/libboost_atomic.so.1.69.0 (0x00007f24c687c000)
    libPocoFoundation.so.60 => /lib64/libPocoFoundation.so.60 (0x00007f24c66a5000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f24c669f000)
    librosconsole.so => /usr/lib64/ros/lib/librosconsole.so (0x00007f24c665c000)
    libcpp_common.so => /usr/lib64/ros/lib/libcpp_common.so (0x00007f24c664c000)
    libroslib.so => /usr/lib64/ros/lib/libroslib.so (0x00007f24c662e000)
    librospack.so => /usr/lib64/ros/lib/librospack.so (0x00007f24c65dd000)
    libpython3.7m.so.1.0 => /lib64/libpython3.7m.so.1.0 (0x00007f24c6294000)
    libroslz4.so => /usr/lib64/ros/lib/libroslz4.so (0x00007f24c628d000)
    liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f24c626e000)
    libtopic_tools.so => /usr/lib64/ros/lib/libtopic_tools.so (0x00007f24c6267000)
    libroscpp.so => /usr/lib64/ros/lib/libroscpp.so (0x00007f24c60b3000)
    librosconsole_log4cxx.so => /usr/lib64/ros/lib/librosconsole_log4cxx.so (0x00007f24c6092000)
    librosconsole_backend_interface.so => /usr/lib64/ros/lib/librosconsole_backend_interface.so (0x00007f24c608d000)
    liblog4cxx.so.10 => /lib64/liblog4cxx.so.10 (0x00007f24c5e96000)
    libroscpp_serialization.so => /usr/lib64/ros/lib/libroscpp_serialization.so (0x00007f24c5e91000)
    libxmlrpcpp.so => /usr/lib64/ros/lib/libxmlrpcpp.so (0x00007f24c5e6b000)
    librostime.so => /usr/lib64/ros/lib/librostime.so (0x00007f24c5e3c000)
    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f24c5c43000)
    libm.so.6 => /lib64/libm.so.6 (0x00007f24c5afd000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f24c5ae3000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f24c591d000)
    libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f24c5909000)
    libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f24c5626000)
    libgpgme.so.11 => /lib64/libgpgme.so.11 (0x00007f24c55d9000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f24c55cf000)
    libicudata.so.63 => /lib64/libicudata.so.63 (0x00007f24c3bde000)
    libicui18n.so.63 => /lib64/libicui18n.so.63 (0x00007f24c38fb000)
    libicuuc.so.63 => /lib64/libicuuc.so.63 (0x00007f24c3726000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f24c6c96000)
    libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f24c36b2000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f24c3698000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00007f24c3693000)
    libaprutil-1.so.0 => /lib64/libaprutil-1.so.0 (0x00007f24c3661000)
    libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007f24c3625000)
    libassuan.so.0 => /lib64/libassuan.so.0 (0x00007f24c360f000)
    libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f24c35ec000)
    libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f24c35e2000)
    libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f24c35a5000)
    libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f24c3577000)

My editor is also able to find the headers and auto-complete function names.

When running catkin_make on a new (empty) ~/catkin_ws dir, I get:
-- Could NOT find PY_em (missing: PY_EM)
CMake Error at /usr/lib64/ros/share/catkin/cmake/empy.cmake:29 (message):
Unable to find either executable 'empy' or Python module 'em'... try
installing the package 'python-empy'
Call Stack (most recent call first):

However python3-empy is already installed. I have to install python2-empy to fix the problem.

This one is interesting, looks like two related issues:

  • catkin prefers python2 as python interpreter even if it's called with python3
  • Even if we override PYTHON_EXECUTABLE on the commandline (with catkin_make --cmake-args -DPYTHON_EXECUTABLE=/usr/bin/python3), it still looks for the python2 empy module, which leads to weird errors, as it loads a python2 pyc with a python3 interpreter.

This can be fixed with export ROS_PYTHON_VERSION=3, I'm currently looking into patching catkin so this is not necessary.

This can be fixed with export ROS_PYTHON_VERSION=3, I'm currently looking into patching catkin so this is not necessary.

Fixed in ros-catkin-melodic.0.7.17-4.

Nice, thanks for fixing that.

I'm not sure what the issues were that were causing problems compiling and linking directly against rosbag, but I made my project a catkin build to get around it.

One other suggestion I'll mention again -- building Google Cartographer for ROS was a major stress test for the ROS packages last time I tried it. I won't have the bandwidth to try that again for these new Fedora packages, but it's an important piece of software that would be a good addition to the ROS stack, and it would be a good test of integrating some significant software with these other packages. If you have some free time to give that a shot. If not, no worries :-)

Next issue that's blocking me from pushing forward with my ROS work, and apologies that this is off-topic for this ROS issue, since it's about PCL and VTK, and not strictly about ROS (although it is important that PCL and VTK work well with ROS). Maybe you have some insight into how to solve it.

I get a segfault when my ROS code calls PCL visualization code, which calls VTK, which calls OpenGL.

I'm converting a ROS sensor_msgs::PointCloud2 message into a pcl::PointCloud message, then calling:

    pcl::visualization::CloudViewer viewer("Point Cloud");
    viewer.showCloud(point_cloud, "cloud");

This segfaults here:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fffed5b8613 in vtkOpenGLRenderTimer::ReusableStart (this=0x7fffd8a62e30)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLRenderTimer.cxx:292
#2  0x00007fffed595a61 in vtkOpenGLPolyDataMapper::RenderPieceStart (this=0x7fffd8a62520, ren=0x7fffd8008440, actor=0x7fffd8a3aa60)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx:2360
#3  0x00007fffed5917fc in vtkOpenGLPolyDataMapper::RenderPiece (this=0x7fffd8a62520, ren=0x7fffd8008440, actor=0x7fffd8a3aa60)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLPolyDataMapper.cxx:2569
#4  0x00007fffeba6c5f3 in vtkPolyDataMapper::Render (this=0x7fffd8a62520, ren=0x7fffd8008440, act=0x7fffd8a3aa60)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkPolyDataMapper.cxx:68
#5  0x00007fffeb9b79d6 in vtkDataSetMapper::Render (this=0x7fffd8a3b5e0, ren=0x7fffd8008440, act=0x7fffd8a3aa60)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkDataSetMapper.cxx:163
#6  0x00007fffed5163f7 in vtkOpenGLActor::Render (this=0x7fffd8a3aa60, ren=0x7fffd8008440, mapper=0x7fffd8a3b5e0)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLActor.cxx:100
#7  0x00007fffee40f076 in vtkLODActor::Render (this=0x7fffd8829f90, ren=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/LOD/vtkLODActor.cxx:187
#8  0x00007fffee40e542 in vtkLODActor::RenderOpaqueGeometry (this=0x7fffd8829f90, vp=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/LOD/vtkLODActor.cxx:226
#9  0x00007fffeba89c2b in vtkRenderer::UpdateOpaquePolygonalGeometry (this=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRenderer.cxx:693
#10 0x00007fffed5cd618 in vtkOpenGLRenderer::DeviceRenderOpaqueGeometry (this=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLRenderer.cxx:317
#11 0x00007fffed5c9009 in vtkOpenGLRenderer::UpdateGeometry (this=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLRenderer.cxx:229
#12 0x00007fffed5c8275 in vtkOpenGLRenderer::DeviceRender (this=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkOpenGLRenderer.cxx:170
#13 0x00007fffeba9176b in vtkRenderer::Render (this=0x7fffd8008440)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRenderer.cxx:351
#14 0x00007fffeba88fc8 in vtkRendererCollection::Render (this=0x7fffd8001e70)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRendererCollection.cxx:51
#15 0x00007fffebaaaca0 in vtkRenderWindow::DoStereoRender (this=0x7fffd8000c50)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRenderWindow.cxx:789
#16 0x00007fffebaa7fdd in vtkRenderWindow::DoFDRender (this=0x7fffd8000c50)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRenderWindow.cxx:758
#17 0x00007fffebaa8f63 in vtkRenderWindow::DoAARender (this=0x7fffd8000c50)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRenderWindow.cxx:637
#18 0x00007fffebaa7283 in vtkRenderWindow::Render (this=this@entry=0x7fffd8000c50)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/Core/vtkRenderWindow.cxx:450
#19 0x00007fffed681d61 in vtkXOpenGLRenderWindow::Render (this=0x7fffd8000c50)
    at /usr/src/debug/vtk-8.1.1-5.fc30.x86_64/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx:1571
#20 0x00007ffff70f1301 in pcl::visualization::PCLVisualizer::resetCameraViewpoint(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /lib64/libpcl_visualization.so.1.9
#21 0x00007ffff71238c6 in pcl::cloud_show<pcl::PointCloud<pcl::PointXYZI> >::pop() () from /lib64/libpcl_visualization.so.1.9
#22 0x00007ffff7127e39 in pcl::visualization::CloudViewer::CloudViewer_impl::operator()() () from /lib64/libpcl_visualization.so.1.9
#23 0x00007ffff71c558e in ?? () from /lib64/libboost_thread.so.1.69.0
#24 0x00007ffff75d35a2 in start_thread () from /lib64/libpthread.so.0
#25 0x00007fffe8609303 in clone () from /lib64/libc.so.6

(gdb) list
287   }
288 
289   if (this->StartQuery == 0)
290   {
291     glGenQueries(1, static_cast<GLuint*>(&this->StartQuery));
292     glQueryCounter(static_cast<GLuint>(this->StartQuery), GL_TIMESTAMP);
293     this->ReusableStarted = true;
294     this->ReusableEnded = false;
295   }
296   if (!this->ReusableStarted)

There seems to be some sort of issue with a clash between dynamic and static linking somewhere in the boundary between PCL and VTK:

https://gitlab.kitware.com/vtk/vtk/issues/17280

It seems to be that the OpenGL context is not initialized by the VTK module system, if VTK is statically linked against PCL, if I understand the problem right.

The following should fix the problem, but doesn't seem to in my case (although I can't get it to compile with vtkRenderingOpenGL, only with vtkRenderingOpenGL2):

https://github.com/PointCloudLibrary/pcl/issues/1601#issuecomment-407968604

I guess I'll try compiling my own PCL and VTK, but the packages in Fedora seem to be broken the way they are compiled, and they are in other distros too, and even on Windows. However it seems to be a compilation configuration issue, affecting linking (or preventing the VTK module system from properly automatically initializing its modules when needed), and not a fundamental bug in the libraries.

Any assistance you can provide in fixing PCL/VTK would be appreciated, although I understand if it's not something you want to spend time on because it's off-topic.

Update on previous comment: I replaced the F30 PCL and VTK packages with F31 (rawhide) packages (vtk-8.2.0-6.fc31.x86_64, pcl-1.9.1-4.fc31.x86_64), and the problem is solved. I'll leave the previous comment in place in case anyone else runs into the same problem.

I have some code that depends upon std_msgs::FluidPressure. Compiling the code, I get this:

CMake Warning (dev) at barometer/CMakeLists.txt:26 (add_dependencies):
  Policy CMP0046 is not set: Error on non-existent dependency in
  add_dependencies.  Run "cmake --help-policy CMP0046" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  The dependency target "std_msgs" of target "barometer" does not exist.
This warning is for project developers.  Use -Wno-dev to suppress it.

However these packages are installed:

ros-std_msgs-melodic.0.5.12-3.fc30.noarch
ros-std_msgs-devel-melodic.0.5.12-3.fc30.noarch

The CMakeLists.txt for the project is:

cmake_minimum_required(VERSION 2.8.3)
project(barometer)

## Find catkin and any catkin packages
find_package(catkin REQUIRED COMPONENTS roscpp std_msgs sensor_msgs message_generation)

add_message_files(
  FILES
  CMPS14.msg
)

generate_messages(
  DEPENDENCIES
  std_msgs sensor_msgs
)

## Declare a catkin package
catkin_package(CATKIN_DEPENDS message_runtime)

## Build talker and listener
include_directories(include ${catkin_INCLUDE_DIRS})

FILE(GLOB _sources src/*.c src/*.cpp)
add_executable(barometer ${_sources})
target_link_libraries(barometer ${catkin_LIBRARIES})
add_dependencies(barometer std_msgs)

When upgrading to VTK-8.2.0 (fc31 packages), ros-pcl_conversions-melodic-devel and ros-pcl_ros-melodic (fc30 packages) break. This may or may not be fixed automatically by your build tools once you create an actual fc31 / rawhide build. But in case it is not, changes need to be made to the following four files:

/usr/lib64/ros/share/pcl_conversions/cmake/pcl_conversionsConfig.cmake
/usr/lib64/ros/share/pcl_ros/cmake/pcl_rosConfig.cmake
/usr/lib64/ros/lib/pkgconfig/pcl_conversions.pc
/usr/lib64/ros/lib/pkgconfig/pcl_ros.pc 

The required changes are:
* Replace /usr/lib64/vtk/ with /usr/lib64/
* Remove the libraries libvtkalglib.so.1, libvtkproj4.so.1, libvtksqlite.so.1, libvtkexoIIic.so.1, and libvtkglew.so.1. These are apparently not built in VTK-8.2.0.

(both changes need to be made to all four files)

Incidentally, is there no way to refer to the VTK Config.cmake files and .pc files from the pcl_ros and pcl_conversions files, so that these paths and library names are not hard-coded?

[minor issue]: There is some funny interaction between the rpm tool and package names. It may be because the -devel package names end with -devel-melodic and not -melodic-devel:

$ rpm -q ros-pcl_ros-devel-melodic
package ros-pcl_ros-devel-melodic is not installed
$ rpm -q ros-pcl_ros-devel-melodic.1.6.2-3.fc30.x86_64
ros-pcl_ros-devel-melodic.1.6.2-3.fc30.x86_64

[minor issue]: There is some funny interaction between the rpm tool and package names. It may be because the -devel package names end with -devel-melodic and not -melodic-devel:
$ rpm -q ros-pcl_ros-devel-melodic
package ros-pcl_ros-devel-melodic is not installed
$ rpm -q ros-pcl_ros-devel-melodic.1.6.2-3.fc30.x86_64
ros-pcl_ros-devel-melodic.1.6.2-3.fc30.x86_64

The package is not called ros-pcl_ros-devel-melodic, but ros-pcl_ros-devel, the melodic suffix is part of the version string.

Ah. Maybe consider separating "devel" from "melodic" with a dot rather than a hyphen then, to make this more obvious? Typically the version string starts after the first dot.

Ah. Maybe consider separating "devel" from "melodic" with a dot rather than a hyphen then, to make this more obvious? Typically the version string starts after the first dot.

That's not true, it's always <name>-<version>-<release> (or <name>-<epoch>:<version>-<release> if there is an epoch) for virtually every RPM package. The only uncommon (but completely acceptable) aspect is that we use a string as first part of the version.

I hit another Python version issue.

in CMakeLists.txt, when adding the following:

find_package(OpenGL REQUIRED)
include_directories(${OpenGL_INCLUDE_DIRS})
target_link_libraries(${OpenGL_LINK_LIBRARIES})

I get:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find PythonInterp: Found unsuitable version "2.7.16", but
  required is at least "3" (found /usr/bin/python2)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:376 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindPythonInterp.cmake:160 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  /usr/lib64/ros/share/catkin/cmake/python.cmake:4 (find_package)
  /usr/lib64/ros/share/catkin/cmake/all.cmake:163 (include)
  /usr/lib64/ros/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:56 (find_package)


-- Configuring incomplete, errors occurred!
See also "/home/luke/catkin_ws/build/CMakeFiles/CMakeOutput.log".
See also "/home/luke/catkin_ws/build/CMakeFiles/CMakeError.log".
make: *** [Makefile:2336: cmake_check_build_system] Error 1

I had to remove build/CMakeCache.txt to fix the problem. Adding the lines back does not re-create the problem, and I can't seem to reproduce it unfortunately.

This may be another issue caused by Python version differences (I have no idea)...

$roswtf src/ouster_example/ouster_ros/os1.launch
Loaded plugin tf.tfwtf
Traceback (most recent call last):
  File "/usr/lib64/ros/bin/roswtf", line 35, in <module>
    roswtf.roswtf_main()
  File "/usr/lib64/ros/lib/python3.7/site-packages/roswtf/__init__.py", line 89, in roswtf_main
    _roswtf_main()
  File "/usr/lib64/ros/lib/python3.7/site-packages/roswtf/__init__.py", line 152, in _roswtf_main
    ctx = WtfContext.from_roslaunch(launch_files)
  File "/usr/lib64/ros/lib/python3.7/site-packages/roswtf/context.py", line 168, in from_roslaunch
    _load_roslaunch(ctx, roslaunch_files)
  File "/usr/lib64/ros/lib/python3.7/site-packages/roswtf/context.py", line 245, in _load_roslaunch
    base_pkg, file_deps, missing = roslaunch.depends.roslaunch_deps(roslaunch_files)
  File "/usr/lib64/ros/lib/python3.7/site-packages/roslaunch/depends.py", line 330, in roslaunch_deps
    rl_file_deps(file_deps, launch_file, verbose)
  File "/usr/lib64/ros/lib/python3.7/site-packages/roslaunch/depends.py", line 224, in rl_file_deps
    parse_launch(launch_file, file_deps, verbose)
  File "/usr/lib64/ros/lib/python3.7/site-packages/roslaunch/depends.py", line 209, in parse_launch
    _parse_launch(launch_tag.childNodes, launch_file, file_deps, verbose, context)
  File "/usr/lib64/ros/lib/python3.7/site-packages/roslaunch/depends.py", line 126, in _parse_launch
    if not _check_ifunless(tag, context):
  File "/usr/lib64/ros/lib/python3.7/site-packages/roslaunch/depends.py", line 99, in _check_ifunless
    if tag.attributes.has_key('if'):
AttributeError: 'NamedNodeMap' object has no attribute 'has_key'

ROS now works without any issues for my application on Fedora 30, so please go ahead and close this bug. However, please be aware that changes in VTK and PCL in Fedora 31 may (or may not) cause issues with Fedora 31 ROS packages.

Thanks for putting together this COPR repository, and for your help in sorting out previous issues!

One further comment on Python -- Fedora 31 has continued the process of removing Python 2 packages, so I'm wondering if that will break anything more in these ROS packages. Did you have a chance to build ROS for Fedora 31, now that Fedora 31 is released?

I'm holding back on upgrading to Fedora 31 until ROS works well on it, but any ROS packages that depend on VTK are broken in Fedora 30, due to this bug:

https://gitlab.kitware.com/vtk/vtk/issues/17280

If I wanted to try building all of ROS for Fedora 31, do you have a single script to build all packages, or do I need to use rosinstall_generator / ./rosfed.py $pkgname for each package separately?

Sorry for not replying earlier. Thanks for testing and reporting your issues!

I don't expect python2 to be a problem, I don't think any of the ROS packages pulls in python2. That being said, I don't know if all packages actually work with python3, as that's not easy to check at build time.

I haven't had the time to build for Fedora 31. There is a problem with eigenpy, which pulls sources from the Internet during build, which is not possible when building a package. (Technically, COPR allows it, but I really would want to avoid this). That's not directly related to F31, but it needs to be fixed before the whole stack can be built for F31.

The following command should build the desktop_full stack (you'll need to insert your own COPR and change the chroot):

$ ./rosfed.py -b --copr-owner thofmann --copr-project ros --chroot fedora-30-x86_64 --obsolete-distro-pkg -c "Update to latest release" --distro melodic -r desktop_full

The README provides more info, but I do realize it could be improved.

This is what I get when trying to build on f30 in a f31 toolbox:

$ ./rosfed.py -b --copr-owner lukehutch --copr-project ros --chroot /tmp/fedora-31-x86_64 --obsolete-distro-pkg -c "Update to latest release" --distro melodic -r desktop_full
Generating Spec file for desktop_full.
Generating Spec file for perception.
Generating Spec file for catkin.
ERROR: no rosdep rule for 'python3-catkin-pkg'
Traceback (most recent call last):
  File "./rosfed.py", line 99, in compute_dependencies
    self.distro_info.get_release_package_xml(pkg)
  File "/usr/local/lib/python3.7/site-packages/rosdistro/distribution.py", line 66, in get_release_package_xml
    pkg = self._distribution_file.release_packages[pkg_name]
KeyError: 'python3-catkin-pkg'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./rosfed.py", line 106, in compute_dependencies
    ['distro_names'][pkg]
KeyError: 'python3-catkin-pkg'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./rosfed.py", line 435, in <module>
    main()
  File "./rosfed.py", line 310, in main
    args.destination)
  File "./rosfed.py", line 359, in generate_spec_files
    ros_pkg = RosPkg(name=packages[i], distro=distro)
  File "./rosfed.py", line 87, in __init__
    self.compute_dependencies()
  File "./rosfed.py", line 111, in compute_dependencies
    get_system_package_name(pkg, self.rosdistro)
  File "./rosfed.py", line 36, in get_system_package_name
    pkg_name, cmd.stderr or cmd.stdout.decode())
AssertionError: Could not find system package python3-catkin-pkg: 

It seems to be calling into my existing f30 ROS install: /usr/local/lib/python3.7/site-packages/rosdistro/distribution.py

Hi, I never got the ROS packages compiling on Fedora 31, despite a few attempts. I don't live in the Python or C++ world, so I'm not good at wrangling this stuff into shape.

We're 6 weeks away from the release of Fedora 32 at this point. I'm still running F30 so that my ROS stuff will keep running. Hopefully the changes from F31 -> F32 are not as disruptive as the changes from F30 -> F31 were (e.g. the removal of Python 2, and changes to the locations of VTK and PCL libraries). We're also less than a month away from the release of ROS Noetic.

Any chance you would have time to please try building Melodic and/or Noetic packages for F31 and/or F32?

Thanks, I appreciate your efforts on this!

Almost all packages are available for F31:
https://copr.fedorainfracloud.org/coprs/thofmann/ros/monitor/

Oh, thanks for that! I didn't see that those were available.

I went to upgrade my ROS packages, and I see where I was going wrong. I forgot that I had switched my DNF repo from ros to ros-testing, and the latest package versions in ros-testing are kinetic packages for fc29 (so the last time I tried updating, I couldn't see either melodic or fc30/31 packages available). The upgrade worked after switching back to the ros repo. Thanks!

@thofmann Any chance we're gonna get ROS2 on Fedora anytime soon?

The latest one https://index.ros.org/doc/ros2/Installation/Foxy/ ROS2 frosty fitzroy, is LTS and the build instructions for Fedora give an error on Fedora 32, so now looks like a good time.

I think this issue can be closed ?

Yes, thanks for pointing this out. I should have closed this a long time ago. Thanks @thofmann for all the help on this!

Looks like I don't have permissions to close this. Please go ahead and close. Thanks!

Metadata Update from @thofmann:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata