The build path and various binary paths are embedded in two demo files
and the build path changes the buildid of /usr/bin/comedi_soft_calibrate
and /usr/bin/comedi_calibrate:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/comedilib.html

  /usr/share/doc/libcomedi-dev/demo/pwm.gz

  #!·/bin/bash
  vs.
  #!·/bin/sh

  lt_dump_D=`$ECHO·"X$lt_script_arg0"·|·/bin/sed·-e·'s/^X//'·-e·'s%/[^/]*$%%'`
  vs.
  lt_dump_D=`$ECHO·"X$lt_script_arg0"·|·/usr/bin/sed·-e·'s/^X//'·-e·'s%/[^/]*$%%'`

  LD_LIBRARY_PATH="/build/1st/comedilib-0.11.0+5/lib/.libs:$LD_LIBRARY_PATH"
  vs.
  LD_LIBRARY_PATH="/build/2/comedilib-0.11.0+5/2nd/lib/.libs:$LD_LIBRARY_PATH"

The attached patches fix this by adjusting these values from the
debian/rules, and passing CFLAGS and CXXFLAGS to the appropriate
configure target.


According to my local tests, with these patches applied comedilib should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining comedilib!

live well,
  vagrant

severity -1 wishlist
thanks

Dear Maintainer,

Because Debian builds packages from a fixed build path, neither the 'reprotest'
utility in Salsa-CI, nor the Reproducible Builds team's package test
infrastructure for Debian[1] currently check for equivalent binary package
output from differing source package build paths.

This means that your package will pass current reproducibility tests; however
we believe that source code and/or build steps still embed the build path into
the binary package output, making it more difficult than necessary for
independent consumers to check the integrity of binary packages by recompiling
them themselves.

As a result, this bugreport will remain open and be re-assigned the 'wishlist'
severity[2].

For more information about build paths and how they can affect reproducibility,
please refer to: https://reproducible-builds.org/docs/build-path/

Thanks,
James

[1] - https://tests.reproducible-builds.org/debian/reproducible.html

[2] - https://www.debian.org/Bugs/Developer#severities

A correction for a mistake in my previous message:

Currently the 'reprotest' job in Salsa-CI does in fact continue to exercise
variations of the build-path, and will fail if it builds binary packages that
contain different contents as a result.