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? :) 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
signature.asc
Description: PGP signature
