Bug#876934: openorienteering-mapper FTBFS: test failures
For the record, I now verified on SLE (s390x) that version 0.8.1 also builds for big endian systems. Packages for Debian users continue to be available on https://build.opensuse.org/package/show/home:dg0yt/openorienteering-mapper Bye, Kai
Bug#876934: openorienteering-mapper FTBFS: test failures
Dear maintainers, today I released OpenOrienteering Mapper 0.8.1. Now you have the following options for fixing bug#876934: a) Update to 0.8.1. 0.8.x builds successful with proj-5.0.0 and gdal/libpoppler for Debian Testing on build.opensuse.org. It also builds reproducible for openSUSE Tumbleweed. b) Disable GDAL when building openorienteering-mapper-0.7.0. This stops the crashes from a ODR violation caused by a duplicate symbol named pulled in by libgdal from libpoppler. Regards, Kai.
Bug#876934: openorienteering-mapper FTBFS: test failures
Am 09.02.2018 um 16:03 schrieb Sebastiaan Couwenberg: In preparating of the proj transition openorienteering-mapper (0.7.0-1) was rebuilt in my cowbuilder chroot where these tests caused FTBFS too. I'll raise the severity of this issue to serious when the proj transition starts. Kind Regards, Bas Be careful not to mix issues: #876934 was about tests failing on reproducible builds, due to the use of the __FILE__ macro. What you are likely to face now is tests failing on exit, due to violation of ODR by linking openorienteering-mapper transitively via GDAL to libpoppler, and both openorienteering-mapper und libpoppler defining a class "Object". The crash occurs when a destructor for "Object" is run (cf. https://github.com/OpenOrienteering/mapper/issues/1030). This is a horrible trap for application developers. IMO opinion no library must export such generic names in the global namespace, i.e. it is a serious bug in libpoppler. Anyway, we moved all of openorienteering-mapper source code to namespace OpenOrienteering. This solved the failing tests we observed also for openSUSE Tumbleweed. v0.8.0 will be released in the next days. Kind regards, Kai
Bug#876934: openorienteering-mapper FTBFS: test failures
On Mon, 9 Oct 2017 10:54:14 +0200 Graham Inggs wrote: > I've just tried sbuild in an amd64 sid schroot and > openorienteering-mapper builds fine for me. > > I noticed it also still builds in testing on the reproducible-builds > buildds. > > Why don't co-maintainers (uploaders) receive bug by default? I missed > this report. In preparating of the proj transition openorienteering-mapper (0.7.0-1) was rebuilt in my cowbuilder chroot where these tests caused FTBFS too. I'll raise the severity of this issue to serious when the proj transition starts. Kind Regards, Bas
Bug#876934: openorienteering-mapper FTBFS: test failures
Kai Pastor, DG0YT: > Am 13.11.2017 um 20:15 schrieb Adrian Bunk: >>> I didn't find a recommendation how to solve the issue. I hope a custom macro >>> is okay. >> Based on the discussion in #876901 [1] it is still unclear how this >> should be resolved in general. >> > One more remark: > > Replacing __FILE__ with an individual macro makes it much harder to detect > embedded build paths in source code review. Proliferation of individual > macros could become worse than __FILE__ IMO. > > > I see the discussion on debian-qt-kde. The proposal in > https://lists.debian.org/debian-qt-kde/2017/11/msg00110.html: > >> If all the test files reside underneath the same directory, like tests/, you >> could: > >> 4. export >> BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests". > > will probably worked for this package (old versions). But such information > needs to be in documentation, at the time such a change is introduced. In > addition, there needs to be much better correlation of changes in the > environment and changes in reproducibility build success. It seems there are > two variations tested, but __FILE__ vs. not __FILE__ is not included. > > I remember that I spent time studying changelogs of gcc and Qt packages in > Debian when this bug was opened, but I was unaware of the particularities of > the gcc in reproducible builds. The rbuild log that I find online does not > contain the exact c++ compiler package name and version. What an irony, the > reproducible-builds logs do not provide enough information to consider them > reproducible. Even Debian package build logs on build.opensuse.org offer more > details. We could have solved this much earlier, and without wasting CPU > cycles and developer time. > There was some mis-co-ordination, Adrian did not tell us he was filing the bug, we the reproducible-builds team were not intending to file a bug, and I missed the first few messages of the bug report so I assumed he already explained that the FTBFS is only a problem on tests.r-b.org and not the official Debian archive or buildds. The patch currently being used on tests.r-b.org is here: https://anonscm.debian.org/cgit/reproducible/debrepatch.git/tree/toolchain-patches/gcc-7_BPPM.patch The documentation for the variable seems to have been chopped off by mistake, but it is in the patch that I sent upstream to GCC, ctrl-F for "invoke.texi": https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01318.html Indeed, the exact version of the C++ compiler does not appear in the rbuild: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openorienteering-mapper.html That is because schroots are installed with "build-essential" by default and so gcc doesn't get downloaded every single time for each package build. That's an unfortunate situation and I can see it's ironic, you could probably file a bug against jenkins.debian.org or perhaps pbuilder to have the builders dump this information into the log, even if the build fails. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git
Bug#876934: openorienteering-mapper FTBFS: test failures
Am 13.11.2017 um 20:15 schrieb Adrian Bunk: I didn't find a recommendation how to solve the issue. I hope a custom macro is okay. Based on the discussion in #876901 [1] it is still unclear how this should be resolved in general. One more remark: Replacing __FILE__ with an individual macro makes it much harder to detect embedded build paths in source code review. Proliferation of individual macros could become worse than __FILE__ IMO. I see the discussion on debian-qt-kde. The proposal in https://lists.debian.org/debian-qt-kde/2017/11/msg00110.html: > If all the test files reside underneath the same directory, like tests/, you could: > 4. export BUILD_PATH_PREFIX_MAP="$BUILD_PATH_PREFIX_MAP=tests=$BASEDIR/tests". will probably worked for this package (old versions). But such information needs to be in documentation, at the time such a change is introduced. In addition, there needs to be much better correlation of changes in the environment and changes in reproducibility build success. It seems there are two variations tested, but __FILE__ vs. not __FILE__ is not included. I remember that I spent time studying changelogs of gcc and Qt packages in Debian when this bug was opened, but I was unaware of the particularities of the gcc in reproducible builds. The rbuild log that I find online does not contain the exact c++ compiler package name and version. What an irony, the reproducible-builds logs do not provide enough information to consider them reproducible. Even Debian package build logs on build.opensuse.org offer more details. We could have solved this much earlier, and without wasting CPU cycles and developer time. Regards, Kai.
Bug#876934: openorienteering-mapper FTBFS: test failures
Am 13.11.2017 um 20:15 schrieb Adrian Bunk: On Sun, Nov 12, 2017 at 10:57:38AM +0100, Kai Pastor, DG0YT wrote: Am 11.11.2017 um 17:18 schrieb Adrian Bunk: I found what causes the problem: The failing tests use the following for finding the path to test files: QDir::addSearchPath(prefix, QFileInfo(QString::fromUtf8(__FILE__)).dir().absoluteFilePath(prefix)); In unstable reproducible builds the build path is varied, and gcc patched to accept setting __FILE__ to a fixed (reproducible) location. In other words, when Debian will start changing __FILE__ also on the buildds this will become a FTBFS also there. It is a pity that I immediately suspected the __FILE__ macro when I studied this bug before, but didn't ask. I really couldn't imagine that someone would tinker with such a commonly used feature, or at least one would immediately notice a lot of breaking packages in the moment the change was introduced. There is no mention of __FILE__ on https://wiki.debian.org/ReproducibleBuilds/Howto... Hm, I understand the benefit of reproducible builds. But does this really need to extend to test binaries which do not get packaged? These tests need to be as much stand-alone as possible and work out of the box in any context (host OS, target OS). I didn't find a recommendation how to solve the issue. I hope a custom macro is okay. Based on the discussion in #876901 [1] it is still unclear how this should be resolved in general. Semi-related, why aren't you using QFINDTESTDATA [2]? Do be honest, I didn't know about QFINDTESTDATA, and it was not available when we started (Qt 4.8). I looked for something like that before answering yesterday and I think I saw QFINDTESTDATA at this time. But a) the "Note:" section states some requirements for reliable detection of testdata, and b) it is definitely considering multiple locations where I explicitly want to use a single location. In addition, c) now I didn't want to rely on anything which might use __FILE__ as well. So it does not fit. Kai.
Bug#876934: openorienteering-mapper FTBFS: test failures
On Sun, Nov 12, 2017 at 10:57:38AM +0100, Kai Pastor, DG0YT wrote: > Am 11.11.2017 um 17:18 schrieb Adrian Bunk: > > I found what causes the problem: > > > > The failing tests use the following for finding the path to test files: > > QDir::addSearchPath(prefix, > > QFileInfo(QString::fromUtf8(__FILE__)).dir().absoluteFilePath(prefix)); > > > > In unstable reproducible builds the build path is varied, > > and gcc patched to accept setting __FILE__ to a fixed > > (reproducible) location. > > > > In other words, when Debian will start changing __FILE__ also on the > > buildds this will become a FTBFS also there. > > Hm, I understand the benefit of reproducible builds. But does this really > need to extend to test binaries which do not get packaged? These tests need > to be as much stand-alone as possible and work out of the box in any context > (host OS, target OS). > > I didn't find a recommendation how to solve the issue. I hope a custom macro > is okay. Based on the discussion in #876901 [1] it is still unclear how this should be resolved in general. Semi-related, why aren't you using QFINDTESTDATA [2]? > Kai > (upstream) cu Adrian [1] https://bugs.debian.org/876901 [2] http://doc.qt.io/qt-5/qtest.html#QFINDTESTDATA -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#876934: openorienteering-mapper FTBFS: test failures
v0.7.92 hopefully fixes the FTBFS in the reproducible builds environment. v0.7.92+2 (cd0aed9) might fix reproducibility. (At least, v0.7.92+1 deals with the time stamp in the help collection.) Kai.
Bug#876934: openorienteering-mapper FTBFS: test failures
Am 11.11.2017 um 17:18 schrieb Adrian Bunk: I found what causes the problem: The failing tests use the following for finding the path to test files: QDir::addSearchPath(prefix, QFileInfo(QString::fromUtf8(__FILE__)).dir().absoluteFilePath(prefix)); In unstable reproducible builds the build path is varied, and gcc patched to accept setting __FILE__ to a fixed (reproducible) location. In other words, when Debian will start changing __FILE__ also on the buildds this will become a FTBFS also there. Hm, I understand the benefit of reproducible builds. But does this really need to extend to test binaries which do not get packaged? These tests need to be as much stand-alone as possible and work out of the box in any context (host OS, target OS). I didn't find a recommendation how to solve the issue. I hope a custom macro is okay. Kai (upstream)
Bug#876934: openorienteering-mapper FTBFS: test failures
Control: tags -1 buster On Tue, Oct 17, 2017 at 03:47:37PM +0200, Graham Inggs wrote: > Hi Adrian > > binNMU against libpolyclipping22 is successful too: > https://buildd.debian.org/status/package.php?p=openorienteering-mapper=unstable > > Should this report be reassigned to reproducible builds? I found what causes the problem: The failing tests use the following for finding the path to test files: QDir::addSearchPath(prefix, QFileInfo(QString::fromUtf8(__FILE__)).dir().absoluteFilePath(prefix)); In unstable reproducible builds the build path is varied, and gcc patched to accept setting __FILE__ to a fixed (reproducible) location. In other words, when Debian will start changing __FILE__ also on the buildds this will become a FTBFS also there. > Regards > Graham cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#876934: openorienteering-mapper FTBFS: test failures
Hi Adrian binNMU against libpolyclipping22 is successful too: https://buildd.debian.org/status/package.php?p=openorienteering-mapper=unstable Should this report be reassigned to reproducible builds? Regards Graham
Bug#876934: openorienteering-mapper FTBFS: test failures
Control: tags -1 + unreproducible sid Control: severity -1 normal I've just tried sbuild in an amd64 sid schroot and openorienteering-mapper builds fine for me. I noticed it also still builds in testing on the reproducible-builds buildds. Why don't co-maintainers (uploaders) receive bug by default? I missed this report.
Bug#876934: openorienteering-mapper FTBFS: test failures
Source: openorienteering-mapper Version: 0.7.0-1 Severity: serious Some recent change in unstable makes openorienteering-mapper FTBFS: https://tests.reproducible-builds.org/debian/history/openorienteering-mapper.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/openorienteering-mapper.html ... debian/rules override_dh_auto_test make[1]: Entering directory '/build/1st/openorienteering-mapper-0.7.0' # The tests need a running X server, so use Xvfb to run the tests in automated # build environments. cd obj-x86_64-linux-gnu ; xvfb-run /usr/bin/ctest --force-new-ctest-process -j1 --extra-verbose UpdateCTestConfiguration from :/build/1st/openorienteering-mapper-0.7.0/obj-x86_64-linux-gnu/DartConfiguration.tcl UpdateCTestConfiguration from :/build/1st/openorienteering-mapper-0.7.0/obj-x86_64-linux-gnu/DartConfiguration.tcl Test project /build/1st/openorienteering-mapper-0.7.0/obj-x86_64-linux-gnu Constructing a list of tests Done constructing a list of tests Updating test list for fixtures Added 0 tests to meet fixture requirements Checking test dependency graph... Checking test dependency graph end test 1 Start 1: tst_qglobal 1: Test command: /usr/bin/cmake "-P" "tst_qglobal-RUN.cmake" 1: Test timeout computed to be: 9.99988e+06 1: * Start testing of tst_QGlobal * 1: Config: Using QtTest library 5.9.1, Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.2.0) 1: PASS : tst_QGlobal::initTestCase() 1: PASS : tst_QGlobal::testqOverload() 1: PASS : tst_QGlobal::cleanupTestCase() 1: Totals: 3 passed, 0 failed, 0 skipped, 0 blacklisted, 1ms 1: * Finished testing of tst_QGlobal * 1/17 Test #1: tst_qglobal .. Passed0.07 sec test 2 Start 2: encoding_t 2: Test command: /usr/bin/cmake "-P" "encoding_t-RUN.cmake" 2: Test timeout computed to be: 9.99988e+06 2: * Start testing of EncodingTest * 2: Config: Using QtTest library 5.9.1, Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.2.0) 2: PASS : EncodingTest::initTestCase() 2: PASS : EncodingTest::testCodepageForLanguage(cs) 2: PASS : EncodingTest::testCodepageForLanguage(cs_x) 2: PASS : EncodingTest::testCodepageForLanguage(ru) 2: PASS : EncodingTest::testCodepageForLanguage(ru_RU) 2: PASS : EncodingTest::testCodepageForLanguage(de) 2: PASS : EncodingTest::testCodepageForLanguage(??) 2: PASS : EncodingTest::testCodecForName() 2: PASS : EncodingTest::cleanupTestCase() 2: Totals: 9 passed, 0 failed, 0 skipped, 0 blacklisted, 3ms 2: * Finished testing of EncodingTest * 2/17 Test #2: encoding_t ... Passed0.08 sec test 3 Start 3: georeferencing_t 3: Test command: /usr/bin/cmake "-P" "georeferencing_t-RUN.cmake" 3: Test timeout computed to be: 9.99988e+06 3: * Start testing of GeoreferencingTest * 3: Config: Using QtTest library 5.9.1, Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.2.0) 3: PASS : GeoreferencingTest::initTestCase() 3: PASS : GeoreferencingTest::testEmptyProjectedCRS() 3: PASS : GeoreferencingTest::testGridScaleFactor() 3: PASS : GeoreferencingTest::testCRS(EPSG:4326) 3: PASS : GeoreferencingTest::testCRS(UTM) 3: PASS : GeoreferencingTest::testCRSTemplates() 3: PASS : GeoreferencingTest::testProjection(LVermGeo RLP Koblenz UTM) 3: PASS : GeoreferencingTest::testProjection(LVermGeo RLP Koblenz GK3) 3: PASS : GeoreferencingTest::testProjection(LVermGeo RLP Pruem UTM) 3: PASS : GeoreferencingTest::testProjection(LVermGeo RLP Pruem GK2) 3: PASS : GeoreferencingTest::testProjection(LVermGeo RLP Landau UTM) 3: PASS : GeoreferencingTest::testProjection(LVermGeo RLP Landau GK3) 3: PASS : GeoreferencingTest::testProjection(EPSG 5514 ČÚZK Dolní Temenice) 3: PASS : GeoreferencingTest::cleanupTestCase() 3: Totals: 14 passed, 0 failed, 0 skipped, 0 blacklisted, 4ms 3: * Finished testing of GeoreferencingTest * 3/17 Test #3: georeferencing_t . Passed0.08 sec test 4 Start 4: locale_t 4: Test command: /usr/bin/cmake "-P" "locale_t-RUN.cmake" 4: Test timeout computed to be: 9.99988e+06 4: * Start testing of LocaleTest * 4: Config: Using QtTest library 5.9.1, Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.2.0) 4: PASS : LocaleTest::initTestCase() 4: XFAIL : LocaleTest::testEsperantoQLocale() Cannot construct Esperanto QLocale from "eo" (issue #792). 4:Loc: [openorienteering-mapper_0.7.0-1/test/locale_t.cpp(46)] 4: XFAIL : LocaleTest::testEsperantoQLocale() Cannot construct Esperanto QLocale from "eo_C". 4:Loc: [openorienteering-mapper_0.7.0-1/test/locale_t.cpp(49)] 4: XFAIL : LocaleTest::testEsperantoQLocale() Cannot construct Esperanto QLocale for AnyScript, AnyCountry. 4:Loc: [openorienteering-mapper_0.7.0-1/test/locale_t.cpp(52)] 4: PASS :
