skip stripping issues

[christianrauch]

The rules for Debian packages force stripping of the installed binaries. This does not always work, for example, stripping errors may occur for officially distributed binaries from a third party. This ignores stripping errors such that dbgsym packages can still be created even when some files cannot be stripped.

[cottsay]

Does this break the dbgsym subpackages that are present in the repo, essentially leaving deb users with no ability to debug ROS packages with symbols present?

[christianrauch]

Does this break the dbgsym subpackages that are present in the repo, essentially leaving deb users with no ability to debug ROS packages with symbols present?

Indeed, thanks for the hint. This strips the ELF binaries but does not create the debug packages.

[christianrauch]

@cottsay I found a solution that works with the concrete problem I am facing and still creates the dbgsym packages.

[cottsay]

a solution that works with the concrete problem I am facing

Can you elaborate a little on this? Does it affect the RPM packages as well? Can you share a job failure URL?

Does this approach to making the dbgsym packages optional result in an empty dbgsym package or no dbgsym package at all?

[christianrauch]

Does it affect the RPM packages as well?

No. The PR only touches the templates in the debian folder.

Can you share a job failure URL?

An example is "building" a package with the binary distribution of libtorch using the ros-deb-builder-action. The package in question is simply downloading the binary archive https://download.pytorch.org/libtorch/cpu/libtorch-shared-with-deps-2.1.2%2Bcpu.zip via ExternalProject_Add and then installing headers and libraries.

The actual failure of this job is here: https://github.com/christianrauch/libtorch-ros-deb-builder/actions/runs/7215155524/job/19671508198, but it is easily reproducible locally with bloom-generate rosdebian --ros-distro humble and fakeroot debian/rules binary.

This fails with:

readelf: Error: no .dynamic section in the dynamic segment
    install -d debian/.debhelper/ros-humble-torch-cpp/dbgsym-root/usr/lib/debug/.build-id/99
    objcopy --only-keep-debug --compress-debug-sections debian/ros-humble-torch-cpp/opt/ros/humble/lib/x86_64-linux-gnu/libtorch_global_deps.so debian/.debhelper/ros-humble-torch-cpp/dbgsym-root/usr/lib/debug/.build-id/99/4b32c64b7b9a51afa3d4ad9b25f0cfcfdc5923.debug
objcopy: warning: debian/ros-humble-torch-cpp/opt/ros/humble/lib/x86_64-linux-gnu/libtorch_global_deps.so has a corrupt string table index - ignoring
objcopy: unable to modify 'debian/ros-humble-torch-cpp/opt/ros/humble/lib/x86_64-linux-gnu/libtorch_global_deps.so' due to errors
dh_strip: error: objcopy --only-keep-debug --compress-debug-sections debian/ros-humble-torch-cpp/opt/ros/humble/lib/x86_64-linux-gnu/libtorch_global_deps.so debian/.debhelper/ros-humble-torch-cpp/dbgsym-root/usr/lib/debug/.build-id/99/4b32c64b7b9a51afa3d4ad9b25f0cfcfdc5923.debug returned exit code 1
dh_strip: error: Aborting due to earlier error
make: *** [debian/rules:25: binary] Error 25
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit status 2

Does this approach to making the dbgsym packages optional result in an empty dbgsym package or no dbgsym package at all?

I guess so. If you try to install binary files without debug symbols, there is nothing to extract so the dbgsym package would not contain anything useful.

[tfoote]

I don't think that this is appropriate for us to just do generically for all packages because one package is doing something unsupported by the default policy. In this case the libtorch package is not building the binaries following the default build pipeline and (and downloading from an external source which is also discouraged when packaging) and then because of not having binaries built with the default way is failing. So the correct solution for this case is that the package maintainers should patch the debian control file specificallly for this package instead of changing the default behavior of all packages. (Disabling this check for everyone can lead to false negatives on error checking for all potential packages in the future. )

You can change the debian control file for a specific package as described here: http://wiki.ros.org/bloom/Tutorials/ChangeBuildFlags

[christianrauch]

A workaround is to strip the binaries manually before it comes to the dh_strip phase, e.g. with something like find lib -type f -name "*.so*" -o -name "*.a" | xargs -i strip --strip-all {}.