Am 10.11.20 um 01:00 schrieb Vagrant Cascadian:
On 2020-10-16, Kai Pastor, DG0YT wrote:
Am 16.10.20 um 01:19 schrieb Vagrant Cascadian:
When the reproducible=+fixfilepath feature is enabled (either through
DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
openorienteering-mapper fails to build from source:
http://qa-logs.debian.net/2020/09/26.fixfilepath/openorienteering-mapper_0.9.3-1_unstable_fixfilepath.log
While the "fixfilepath" feature is not currently enabled by
dpkg-buildflags by default, it may become the default at some point in
the future, and can by triggered manually by setting
DEB_BUILD_OPTIONS=reproducible=+fixfilepath in the build environment.
More information about this issue is available at:
https://tests.reproducible-builds.org/debian/issues/unstable/ftbfs_due_to_f-file-prefix-map_issue.html
I have not identified the exact cause of this issue for
openorienteering-mapper, but a common triggering issue is test suites
expectinfg __FILE__ to resolve to an absolute path.
The attached patch works around this issue by disabling the fixfilepath
feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.
... sorry for the delay...
So far, all cases in openorienteering-mapper were tests which were
expected to be run in the build environment and indeed access the
pristine test data in the source directory.
The current issue comes from using Qt's QFINDTESTDATA(), which relies on
a cpp macro (QT_TESTCASE_BUILDDIR) pointing "to the working directory
from which the compiler is invoked" in order to "the absolute path of
the source directory" [!],
https://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA . QT_TESTCASE_BUILDDIR
is defined by Qt's cmake file. I do see some inconsistency there, but
this is a different story.
Yes, this is part of the known issues with test data mentioned; the
majority of known build failures triggered by fixfilepath are these
use-cases with QFINDTESTDATA.
In previous cases I "solved" the failing reproducible builds by: using
another macro, carrying the source directory. But I'm not sure if this
is what is intented. While I do have ideas how to workaround this in
other ways, I would appreciate a clear recommendation how test data in
the source dir should be handled.
If the package in question only uses such features in test suites that
are not shipped in the binary packages, it's perfectly reasonable to
disable the fixfilepath feature; it will likely have no effect on the
resulting packages either way.
If the package embeds file paths in files shipped in the binary
packages, then it might be worth some of the workarounds you suggested
with the test suites, and further debugging what exactly is embedding
the build paths; enabling fixfilepath only catches some of the issues of
embedded build paths, so it may be a moot point for any particular
package.
Disabling fixfilepath in your package will allow
tests.reproducible-builds.org to be able to test builds of the
openorienteering-mapper package in unstable and experimental again,
where the build path is varied, and possibly help identify weather
further exploration is needed.
At this point, I'd suggest disabling fixfilepath for this particular
package. But I submitted the patch to do that, so maybe I am biased? :)
Trying to express my concerns in terms of reproducible-builds.org
terminology definitions:
As the author of the software, I define the "expected reproducible
artifacts" to be the files created by "make install".
With disabling fixfilepath, is there another test which not only
verifies "bit-by-bit identical copies of all specified artifacts", but
would also offer the diagnosis that the build path ended up in the
installed artifacts?
Last not least, "make install" is the canonical way of creating the set
of artifacts meant for distribution.
Hope that is a clear enough recommendation?
Oh, and, sorry for not getting back to you till now! Not sure how I lost
track of this...
live well,
vagrant
Thanks!
Kai
