Adrian Bunk: > Control: reassign -1 qtbase5-dev > Control: reassign 876917 qtbase5-dev > Control: reassign 876933 qtbase5-dev > Control: forcemerge -1 876917 876933 > Control: retitle -1 QFINDTESTDATA uses __FILE__ > Control: severity -1 normal > Control: affects -1 src:karchive src:ki18n src:kcodecs src:kparts > thanks > > The problem is the following implementation in > /usr/include/x86_64-linux-gnu/qt5/QtTest/qtestcase.h: > # define QFINDTESTDATA(basepath)\ > QTest::qFindTestData(basepath, __FILE__, __LINE__) > > With the patched gcc in the unstable reproducible builds setting > __FILE__ to something other value, this does no longer find the > test data. > > I do not really see any reason for blaming the users here for using > a documented public Qt API for accesssing test data in the source > directory: > http://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA > > I've added reproducible-builds@lists.alioth.debian.org to Cc for giving > input what a reproducible and portable implementation might be for Qt. >
Our patched dpkg tells GCC to map $PWD to "$srcpkg-$version" when expanding __FILE__. That is the source of the problem, because this path doesn't exist at test-time. You have the following options: 1. Unset BUILD_PATH_PREFIX_MAP. This is not great because things that use __FILE__ will become unreproducible. 2. Symlink "$srcpkg-$version" -> ".", so that the files can be accessed under the paths that __FILE__ was expanded to. 3. Set BUILD_PATH_PREFIX_MAP to map $PWD to . instead. You do this by doing `export BUILD_PATH_PREFIX_MAP=$BUILD_PATH_PREFIX_MAP:.=$PWD`, then the tests should work. This makes any other uses of __FILE__ in this package, inconsistent with other Debian packages (built with our patched dpkg). (maybe there are other options) I chose "$srcpkg-$version" because it provides some extra information, and allows one to distinguish files in different packages. Currently, dpkg-buildflags(1) sets -fdebug-prefix-map= to ".", so propsal (3) would actually be consistent with that. However I do think "$srcpkg-$version" is better because it's more informative. More generally, we don't want __FILE__-using tests to dictate how we should remap build paths *in general* in Debian. The problem stems from the fact that we assume __FILE__ represents a build-time path and not a run-time path, so we rewrite it indiscriminately with BUILD_PATH_PREFIX_MAP. This assumption is broken in the specific case where you have some source code that uses __FILE__, that are specifically only meant to be run at build-time, so that they are in fact run-time paths (that are also build-time paths). The assumption is fine in all other cases. Therefore, the only solution to fix this problem, that also preserves reproducible builds, is to make those tests *not use __FILE__*. Or option (2), which makes the non-existent rewritten paths, into an actually-existing build-time path. I am not "blaming the user", but pointing to the fact that __FILE__ is being used in a surprising way here, which is not good for reproducible builds. An analogy would be to write your program to execute something at time "__DATE__ + 30 seconds". This is obviously ridiculous, but works "by accident" if done inside a test case. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
