On 2020-11-10, Kai Pastor, DG0YT wrote: > 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?
I'm not sure what exactly you are asking, but here is my attempt to answer... :) In this case, DEB_BUILD_OPTIONS or DEB_BUILD_MAINT_OPTIONS=reproducible=+fixfilepath merely tells dpkg-buildflags to set various flags (e.g. CFLAGS) to include -ffile-prefix-map=BUILDPATH=. It does not verify reproducibility of resulting artifacts. It can lead to artifacts which are easier to build reproducibly in some cases. Determining weather the artifacts are reproducible is done with mechanisms such as comparing checksums of the artifacts, and diagnosis of reproducibility issues when the checksums do not match is done by comparing the resulting artifacts of multiple builds using tools such as diffoscope... or tools such as reprotest which perform multiple builds varying a variety of things, and then compares the results with diff or diffoscope. Lintian appears to be able to detect build path in some cases: https://lintian.debian.org/tags/file-references-package-build-path.html For openorienteering-mapper, it looks like it is affected by at least one issue unrelated to build path: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/openorienteering-mapper.html Specifically: https://tests.reproducible-builds.org/debian/issues/timestamps_in_qhc_issue.html But test.reproducible-builds.org builds using bullseye do not vary the build path, so you cannot know if setting fixfilepath would affect the results or not. The tests.reproducible-builds.org builds using unstable do vary the build path, but also sets DEB_BUILD_OPTIONS=reproducible=+all which enables the fixfilepath feature, triggering a build failure in openorienteering-mapper due to use of QFINDTESTDATA in the test suites, and hence this bug report. So if you want to see if fixfilepath affects the build, disable the test suite and run one build with it enabled and another with it disabled, with a different build path each time, changing as little as possible otherwise, and see if you get differences related to the build path in the resulting artifacts. Another option for openorienteering-mapper is if you could filter out the -ffile-prefix-map and -fmacro-prefix-map flags from CFLAGS (or other relevent *FLAGS) in the test suite, since the test suite relies on behavior that these flags change incompatibly. That's a bit more complicated than the proposed one-line change to debian/rules, but would be upstreamable. Hope that helps. live well, vagrant
signature.asc
Description: PGP signature
