current ROS-O build failures

[v4hn]

@mqcmd196 As announced I worked my way through most problems in ros-o-builder by now and jsk_visualization works well. 🥳

Here is the list of all remaining packages in the JSK stacks that fail to build (the first few of them also at the bottom of the README.md in jammy-one).
The affected repositories are https://github.com/jsk-ros-pkg/jsk_3rdparty, https://github.com/jsk-ros-pkg/jsk_recognition, and https://github.com/jsk-ros-pkg/jsk_roseus .
It would be great if you could help to get these resolved one way or another so we can include a fully-building jsk stack in https://github.com/v4hn/ros-o-builder, as well as https://github.com/ubi-agni/ros-builder-action .

$ curl -sL https://github.com/v4hn/ros-o-builder/raw/jammy-one/pkg_build_status.csv | tail -n+2 | awk -F, '$4 != "success" { print $1,$4 }'
collada_urdf_jsk_patch failed-sbuild
dialogflow_task_executive failed-sbuild
downward failed-sbuild
ff failed-sbuild
ffha failed-sbuild
libsiftfast failed-sbuild
lpg_planner failed-sbuild
respeaker_ros failed-sbuild
ros_speech_recognition failed-sbuild
sesame_ros failed-sbuild
imagesift failed-sbuild
jsk_perception failed-bloom-generate
jsk_pcl_ros_utils failed-sbuild
jsk_pcl_ros failed-sbuild
roseus_tutorials failed-bloom-generate
sound_classification failed-sbuild

I suspect many of these are obsolete (some relying on python2) and maybe it makes sense to CATKIN_IGNORE them in the upstream repository until someone ports them.

Feel free to link me in new individual issues if I can help somehow.

[mqcmd196]

@v4hn
Thank you for your report. I'm fixing build errors in between my research :)

Some packages seem to be patches for old upstream packages that could be dropped.

jsk_perception depends on opencv_apps , so I want you to request that opencv_apps be released. I confirmed opencv_apps is buildable in my Ubuntu 22.04 machine (I haven't tried creating .deb package yet)

[mqcmd196]

Work on here

[v4hn]

jsk_perception depends on opencv_apps , so I want you to request that opencv_apps be released

I added it to my builder for testing.

Thank you for looking into these!

[v4hn]

I added [opencv_apps] to my builder for testing.

It built on Ubuntu 22.04 (synced just now), but fails with boost errors on current Debian sid. I'm not sure what change causes the failure, I have not seen this particular error before. But maybe you can have a look as well.

log excerpt

/<<BUILDDIR>>package/src/nodelet/face_recognition_nodelet.cpp:93:7: error: template-id ‘append<boost::filesystem::path::iterator>’ for ‘boost::filesystem::path& boost::filesystem::path::append(iterator, iterator, const codecvt_type&)’ does not match any template declaration
   93 | path& path::append<typename path::iterator>(typename path::iterator lhs, typename path::iterator rhs,
      |       ^~~~
In file included from /usr/include/boost/filesystem.hpp:16,
                 from /<<BUILDDIR>>package/src/nodelet/face_recognition_nodelet.cpp:36:
/usr/include/boost/filesystem/path.hpp:876:13: note: candidates are: ‘template<class InputIterator> typename boost::enable_if_c<boost::conjunction<boost::filesystem::detail::path_traits::is_path_source_iterator<InputIterator>, boost::negation<boost::filesystem::detail::path_traits::is_native_char_ptr<InputIterator> > >::value, boost::filesystem::path&>::type boost::filesystem::path::append(InputIterator, InputIterator, const codecvt_type&)’
  876 |     >::type append(InputIterator begin, InputIterator end, const codecvt_type& cvt)
      |             ^~~~~~
/usr/include/boost/filesystem/path.hpp:1708:25: note:                 ‘boost::filesystem::path& boost::filesystem::path::append(const value_type*, const value_type*, const codecvt_type&)’
 1708 | BOOST_FORCEINLINE path& path::append(const value_type* begin, const value_type* end, codecvt_type const&)
      |                         ^~~~
/usr/include/boost/filesystem/path.hpp:860:13: note:                 ‘template<class InputIterator> typename boost::enable_if_c<boost::conjunction<boost::filesystem::detail::path_traits::is_path_source_iterator<InputIterator>, boost::negation<boost::filesystem::detail::path_traits::is_native_char_ptr<InputIterator> > >::value, boost::filesystem::path&>::type boost::filesystem::path::append(InputIterator, InputIterator)’
  860 |     >::type append(InputIterator begin, InputIterator end)
      |             ^~~~~~
/usr/include/boost/filesystem/path.hpp:1702:25: note:                 ‘boost::filesystem::path& boost::filesystem::path::append(const value_type*, const value_type*)’
 1702 | BOOST_FORCEINLINE path& path::append(const value_type* begin, const value_type* end)
      |                         ^~~~
/usr/include/boost/filesystem/path.hpp:845:13: note:                 ‘template<class Source> typename boost::enable_if_c<boost::conjunction<boost::filesystem::detail::path_traits::is_convertible_to_path_source<typename boost::remove_cv<T>::type>, boost::negation<boost::filesystem::detail::path_traits::is_path_source<typename boost::remove_cv<T>::type> > >::value, boost::filesystem::path&>::type boost::filesystem::path::append(const Source&, const codecvt_type&)’
  845 |     >::type append(Source const& source, codecvt_type const& cvt)
      |             ^~~~~~

[mqcmd196]

2024/11/17 update

❯ curl -sL https://github.com/v4hn/ros-o-builder/raw/jammy-one/pkg_build_status.csv | tail -n+2 | awk -F, '$4 != "success" { print $1,$4 }'
mtc_pour failed-sbuild
collada_urdf_jsk_patch failed-sbuild
dialogflow_task_executive failed-sbuild
downward failed-sbuild
ff failed-sbuild
ffha failed-sbuild
libsiftfast failed-sbuild
lpg_planner failed-sbuild
respeaker_ros failed-sbuild
ros_speech_recognition failed-sbuild
sesame_ros failed-sbuild
imagesift failed-sbuild
jsk_perception failed-sbuild
jsk_pcl_ros_utils failed-sbuild
jsk_pcl_ros failed-sbuild
roseus_tutorials failed-bloom-generate
sound_classification failed-sbuild

jsk_3rdparty

• Support ros-o / Ubuntu 22.04 #512
• collada_urdf_jsk_patch
• downward
• ff
• ffha
• libsiftfast
• sesame_ros

another build issue

• dialogflow_task_executive
• respeaker_ros
• ros_speech_recognition
• sound_classification

jsk_recognition

• imagesift failed-sbuild
• jsk_perception failed-sbuild
• jsk_pcl_ros_utils failed-sbuild
• jsk_pcl_ros failed-sbuild

??
mtc_pour failed-sbuild
lpg_planner failed-sbuild

roseus_tutorials failed-bloom-generate

[mqcmd196]

@v4hn
Some packages in jsk_3rdparty seem to fail to build because of the ROS_DISTRO environment variable.

There are CMake codes like

elseif($ENV{ROS_DISTRO} STRGREATER "melodic")
  catkin_generate_virtualenv(
    INPUT_REQUIREMENTS requirements.in.noetic
    PYTHON_INTERPRETER python3
    )
else()
  catkin_generate_virtualenv(
    INPUT_REQUIREMENTS requirements.in
    PYTHON_INTERPRETER python2
    )
endif()

and it fails to invoke python3 venv with your apt ros-one environment because ROS_DISTRO is set to debian .

I use techfak's ros-one, which sets ROS_DISTRO as one . So I had never noticed until I used your apt ros-one environment in Docker.

Since the o in one/obese happens to be the following letter after the n in noetic, I would like to use this CMake code, but what is @v4hn's preferred way? There may be a way to set up a version of the apt repository with different environment variables, but I don't want this kind of thing to be disorganized.

[v4hn]

Thank you for your efforts!

In order of perceived complexity:

mtc_pour failed-sbuild

That list also includes non JSK package failure. Already addressed and not relevant here.

roseus_tutorials failed-bloom-generate

uvc_camera was made obsolete 10 years ago with the clear successor libuvc_camera (usb_cam should work just as well). Kei also never released it into noetic, so I assume your group agrees we should drop it by now. If you disagree, I can add it to the builder as well as it at least builds, but I suggest to migrate the tutorial if possible.

lpg_planner failed-sbuild

Turns out the package downloads a tarball with a binary that was compiled in 2000 (Linux 2.4...) on 32 bit. Systems do not by default include 32bit libraries anymore, so the binary is broken unless libc6-i386 is installed. Kei released the package to ROS noetic, but it is also broken there:

docker run -it ros:noetic bash -l
$ apt update && apt install ros-noetic-lpg-planner
$ /opt/ros/noetic/share/lpg_planner/bin/lpg-1.2
bash: /opt/ros/noetic/share/lpg_planner/bin/lpg-1.2: No such file or directory

(The misleading error message here is due to 32bit libm.so.6 missing)

Options I see are

• drop the package from jsk_3rdparty as nothing seems to depend on it and there is a newer binary release on Pypi up-lpg.
• switch to the newer binary release of LPG-td-1.4 which the group shares in their github organization
• Switch to build the old version from source as the team shares the 1.2 sources. There are several hopefully-minor patches required though, this is made for gcc and bison from 20 years ago.

packages fail to build because of ROS_DISTRO=debian

I agree this is annoying and I personally prefer one as well (I defined it to begin with 😁). Thus the stretch to call packages ros-one-*, but use debian for building.
I use the debian rosdep registry/"ROS distribution", because ideally all ROS packages considered in ROS-O might be packaged in Debian directly at some point - a lot more work to adhere to Debian policies would be required for that, but this is what people at previous events discussed concerning where ROS1 packages might "end up".

As far as I know the decision for debian was made by @jspricke and others long before it was clear that "ROS n" will be the last Open Robotics ROS distribution. I believe he always advises developers not to rely on this environment variable at all, but rely on ROS-independent criteria.

Independent of that, in the particular case you cite above I would at least expect a check for ROS_PYTHON_VERSION and not ROS_DISTRO which would solve the problem at hand.

[v4hn]

Minor addition: in the current ros-o fork of jsk_visualization, I also reworked some of these logics to special-case for the older versions explicitly instead of testing into future versions: ros-o/jsk_visualization@54b1406
That is another reasonable alternative.

[mqcmd196]

@v4hn Oh, the note was for me, and I planned to work around them, but you did so much work! Thank you for your help!!

packages fail to build because of ROS_DISTRO=debian

Ok, I understand the situation. I'll rewrite it so that it does not depend on ROS_DISTRO