Bug#1024638: opencv: embeds build path in Python extension

Victor Westerhuis victor at westerhu.is
Wed Feb 1 00:11:48 GMT 2023


Vagrant Cascadian <vagrant at reproducible-builds.org> schreef op 22 november 2022 19:56:07 CET:
>On 2022-11-22, Victor Westerhuis wrote:
>> Stripping the rpath from the Python extension makes its BuildId
>> reproducible. The extension still works and both arch:all and arch:any
>> builds succeed locally.
>...
>> diff --git a/debian/rules b/debian/rules
>> index b4d654102..6bd845023 100755
>> --- a/debian/rules
>> +++ b/debian/rules
>> @@ -151,6 +151,7 @@ override_dh_auto_configure:
>>  		-- --name=opencv --system=custom --configure-args "\
>>  			dh_auto_configure -S cmake -D modules/python -B {build_dir} -- \
>>  				-GNinja \
>> +				-DCMAKE_SKIP_RPATH=ON \
>>  				-DOpenCV_BINARY_DIR=$(CURDIR)/$(BUILDDIR) \
>>  				-DOPENCV_PYTHON_STANDALONE_INSTALL_PATH={install_dir} \
>>  				-DOPENCV_SKIP_PYTHON_LOADER=ON \
>
>I would recommend using -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON instead of
>-DCMAKE_SKIP_RPATH=ON.
Unfortunately the Python modules are built as a separate module via a separate Cmake invocation, so this has not worked. The rpaths passed to the linker of the Python libraries are absolute build paths, so they are not reproducible. 
>
>This is the default behavior with (the currently experimental) debhelper
>compat level 14. A little more detail on the issue is available here:
>
>  https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
>
>The main advantage of CMAKE_BUILD_RPATH_USE_ORIGIN is it is more likely
>to work with test suites that depend on the full path.
OpenCV does not ship tests for its Python module, so this is not an issue. 
>
>live well,
>  vagrant

Control: reopen -1

I would suggest to change the d/rules files to my original proposal. 
-- 
Groet, Regards,

Victor Westerhuis



More information about the debian-science-maintainers mailing list