Am 16.10.20 um 01:19 schrieb Vagrant Cascadian:
Package: openorienteering-mapper
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: fixfilepath ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
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.
Thanks for maintaining openorienteering-mapper!
live well,
vagrant
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.
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.
Thanks,
Kai
