Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Found this in the junk e-mails today... Am 23.02.21 um 19:20 schrieb Sebastiaan Couwenberg: There is still a test failure, though. Refer to the attached buildlog for details. This seems unrelated to PROJ 8.0.0. The failing test creates a QTemporaryFile, removes all permissions from the file via QFile::setPermissions(), and expects QFileInfo::readable() to return false for the path of the temporary file. This expectation seems to be not met. The test may be volatile, but worked so far, and I didn't have a better idea how to solve this in a portable way. If there is another change in the environment, hints are welcome. Best regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 24.02.21 um 08:46 schrieb Sebastiaan Couwenberg: On 2/24/21 8:04 AM, Kai Pastor, DG0YT wrote: I would agree that many projects have shortcoming in how they use CMake, partly due to past shortcomings of CMake and its documentation, partly due to ignorance of cross-platform building and packaging. But IMO it goes to far when you imply that CMake is to blame for issues with paths and reproducibility. CMake uses abolute paths, whereas autotools uses relative paths. How is CMake not to blame from issues that arise from that? If issue arise from the use of absolute path, it is okay to consider to CMake as a cause of this issues. But it doesn't mean it can always be blamed. Example: This Debian package was flagged to not build reproducible, due to absolute paths in binaries. But the installed artifacts were fully reproducible. The offending binaries were tests which were meant to be run in the build environment, nowhere else. Since your more comfortable with CMake, maybe you can help upstream the pkg-config patch so that the Fedora package doesn't have to patch the CMake build to have proj.pc installed. Did Fedora try to do that? We really need to get downstream projects more involved in PROJ development to help support their needs. Sure. I'm doing that for at least for PROJ, GDAL, Qt, Poppler. And I really want to use the small gains in build time CMake can offer e.g. with Ninja, when working with so many upstreams and platforms. We probably can agree that a packager (infrequent builds of a particular, rare changes to a clean build system, facing many leaf packages) and a developer (frequent builds, regular modifications to the build system, onboarding of new developers, facing many upstream packages) may have different requirements. Best regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 24.02.21 um 05:55 schrieb Sebastiaan Couwenberg: On 2/24/21 12:58 AM, Kai Pastor, DG0YT wrote: Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: It's good practice to include the Find modules for any dependencies that are not part of cmake itself to not need upstream projects to install cmake modules for them. I think it is deprecated legacy practice, not good practice. Find modules are poorly standardized, poorly maintained, and poorly tested. It would be much better to provide PROJ config files as soon as possible, instead of letting more developers start using PROJ with non-standard find modules picked from random internet locations. I wonder if there is a blocker for building debian PROJ with CMake. I build PROJ for Android, macOS, Windows from Debian tarballs - with cmake, not using debian/rules. https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake Switching from autotools to cmake is generally a regression, cmake doesn't handle multiarch as well, and because it uses absolute paths instead of relative paths it hinders reproducible builds. See the recent discussion on the geos-devel lists for example: https://lists.osgeo.org/pipermail/geos-devel/2021-January/010078.html From the mailing list post and its links I learn that a) actively maintained projects do fix reported build system issues quickly. b) there is some confusion about dealing with CMAKE_BUILD_TYPE, NDEBUG and reproducible paths. I would agree that many projects have shortcoming in how they use CMake, partly due to past shortcomings of CMake and its documentation, partly due to ignorance of cross-platform building and packaging. But IMO it goes to far when you imply that CMake is to blame for issues with paths and reproducibility. (Is there a Debian documentation for how to prepare CMake projects to help with Debian multi-arch?) The CMake build of PROJ doesn't seem to provide a pkgconfig file, but even for mips64el, the single proj.pc looks much less complex than the set of cmake config files, or the patch proposed for FindProj4.cmake. We're not going to switch to cmake for the proj package as long as autotools is supported, because that is the best build system from a packaging point of view. Okay, so this covers your packaging point of view where autotools are already available. But it doesn't align with my requirements as a developer, and also not with my experience in single-arch bundling/packaging third-party components for Android, macOS, Windows. (And I wouldn't even say that CMake is the best system for some purpose.) The best solution for downstream projects not wanting to include their own FindProj modules is to update the autotools build system to also install the cmake bits. Perhaps you can provide a patch for that which PROJ upstream can merge? No, I don't think learning autotools and then teaching autotools to provide CMake config files, possibly for multi-arch, is a good use of my resources. But you may ask for patches for PROJ's CMake build system. Multiarch if I can test/verify in an amd_64 environment. Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 23.02.21 um 19:53 schrieb Sebastiaan Couwenberg: A patch for that was just submitted to this bugreport. Thanks. It's good practice to include the Find modules for any dependencies that are not part of cmake itself to not need upstream projects to install cmake modules for them. I think it is deprecated legacy practice, not good practice. Find modules are poorly standardized, poorly maintained, and poorly tested. It would be much better to provide PROJ config files as soon as possible, instead of letting more developers start using PROJ with non-standard find modules picked from random internet locations. I wonder if there is a blocker for building debian PROJ with CMake. I build PROJ for Android, macOS, Windows from Debian tarballs - with cmake, not using debian/rules. https://github.com/OpenOrienteering/superbuild/blob/master/proj-7.1.1.cmake The CMake build of PROJ doesn't seem to provide a pkgconfig file, but even for mips64el, the single proj.pc looks much less complex than the set of cmake config files, or the patch proposed for FindProj4.cmake. Kind regards, Kai
Bug#983254: openorienteering-mapper: FTBFS with PROJ 8.0.0
Am 21.02.21 um 16:32 schrieb Bas Couwenberg: Source: openorienteering-mapper Version: 0.9.4-2 Severity: important Tags: upstream ftbfs User: debian-...@lists.debian.org Usertags: proj-8.0 Control: forwarded -1 https://github.com/OpenOrienteering/mapper/issues/1214 Dear Maintainer, Your package FTBFS with PROJ 8.0.0: CMake Error at /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message): Could NOT find PROJ4 (missing: PROJ4_INCLUDE_DIR) It needs to be ported to use proj.h instead of proj_api.h which has been removed. Kind Regards, Bas Mapper source code is ported to use proj.h for modern PROJ. However, the embedded fallback FindPROJ4.cmake module isn't, and possible won't. Does Debian build PROJ 8.0.0 with cmake? Debian doesn't seem to provide the cmake config files for PROJ. openorienteering-mapper is meant to pick up these config files. If it finds a recent PROJ in that way, it won't use proj_api.h. Regards, Kai
Bug#875847: Patch to fix ".qhc files not reproducible"
Am 25.11.20 um 19:05 schrieb Dmitry Shachnev: On Wed, Nov 25, 2020 at 06:15:53AM +0100, Kai Pastor, DG0YT wrote: I also left a link to this Debian bug in Qt's code review for the offending change. Can you please share a link to the mentioned code review? https://bugreports.qt.io/browse/QTBUG-62697 has only some old reviews from 2018 linked. https://codereview.qt-project.org/c/qt/qttools/+/203587 (Found again via seaching "status:merged commentby:dg...@darc.de") Ah, sorry, I misunderstood you and thought that you submitted a new code review with your patch. But you commented on change that introduced that code. Is there any reason why you didn't submit your patch to gerrit? Will you mind if I do it? -- Dmitry Shachnev Feel free to submit it. I didn't submit it to gerrit because contributing in that way became too much work for me when they required contributions to go to dev, not LTS. (And I didn't realize that there is a *new* Qt Help issue until Oct 2020, with dev meaning Qt 6 IIRC.) Kai
Bug#875847: Patch to fix ".qhc files not reproducible"
Am 24.11.20 um 19:24 schrieb Dmitry Shachnev:
Hi Kai!
On Thu, Oct 15, 2020 at 07:48:49AM +0200, Kai Pastor, DG0YT wrote:
This patch fixes the creation of the offending timestamp, by clamping to
SOURCE_DATE_EPOCH as specified.
Thank you for the patch and sorry for delayed response!
I also left a link to this Debian bug in Qt's code review for the offending
change.
Can you please share a link to the mentioned code review?
https://bugreports.qt.io/browse/QTBUG-62697 has only some old reviews from
2018 linked.
https://codereview.qt-project.org/c/qt/qttools/+/203587
(Found again via seaching "status:merged commentby:dg...@darc.de")
Clamp registered collection time-stamp to SOURCE_DATE_EPOCH if set.
--- a/src/assistant/help/qhelpcollectionhandler.cpp
+++ b/src/assistant/help/qhelpcollectionhandler.cpp
@@ -2197,7 +2197,14 @@
m_query->addBindValue(fileName);
const QFileInfo fi(absoluteDocPath(fileName));
m_query->addBindValue(fi.size());
-m_query->addBindValue(fi.lastModified().toString(Qt::ISODate));
+QDateTime last_modified = fi.lastModified();
+if (qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))
+{
+qint64 source_date_epoch =
qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH");
+if (source_date_epoch < last_modified.toSecsSinceEpoch())
+
last_modified.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
I think we can use setSecsSinceEpoch(source_date_epoch) here?
I think this was my intention.
Kai.
Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath
Am 10.11.20 um 11:35 schrieb Simon McVittie:
On Fri, 16 Oct 2020 at 08:29:48 +0200, Kai Pastor, DG0YT wrote:
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.
One way this is often done, particularly in the GNOME ecosystem, is to
check for an environment variable that is set by the build system while
running tests. There are often two environment variables - one for the
source directory and one for the build directory - so that tests can
either ask for data files that are distributed with the source code, or
data files that were compiled along with the test itself and placed in
the build directory, if those directories are different.
If the environment variable is not set, there's a fallback that would
be reasonable to use if the test has been installed system-wide,
typically into /usr/libexec/installed-tests (which is something
that various GNOME and GNOME-adjacent packages support doing, for
"as-installed" testing like Debian's autopkgtest: see
<https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests>).
In GLib the fallback is to use dirname(argv[0]), but hard-coding an
installation path would also be reasonable here.
This avoids having to hard-code the path to either the source or build
directory into any binaries, even if test executables and data are going
to be installed into /usr/libexec/installed-tests for "as-installed"
testing.
Some packages need to set environment variables for build-time testing
*anyway*, so that third-party components will find their required data
in the source or build tree: for example, you might need to set PATH,
LD_LIBRARY_PATH, XDG_DATA_DIRS and similar variables. The variables used
by this particular package's tests can be set in the same way.
The implementation that is normally used in GNOME is GLib's
g_test_build_filename(), which works something like this pseudocode:
if file_type == G_TEST_DIST:
dir = getenv("G_TEST_SRCDIR")
elif file_type == G_TEST_BUILT:
# this branch is the closest equivalent of QFINDTESTDATA
dir = getenv("G_TEST_BUILDDIR")
else:
fatal error
if dir is null:
dir = directory containing the running executable
return join_paths(dir, first_path, ...)
An implementation of the build-system side of this in a simple
Makefile-based build system would look something like:
export G_TEST_BUILDDIR = $(CURDIR)
export G_TEST_SRCDIR = $(srcdir)
check:
./test-foo
./test-bar
Obviously the code would look a bit different for Autotools, CMake or
Meson, but all are capable of doing this (Autotools uses
AM_TESTS_ENVIRONMENT, CMake uses
set_tests_properties(... PROPERTIES ENVIRONMENT ...), Meson uses
test(..., env : ...)).
I assume qmake would also be able to do this, but I don't know how.
smcv
I did consider these options, but I am not convinced. One perspective I
am looking at is onboarding of new contributors (upstream).
Reproducibility helps with that, no doubt. But with your favourite IDE
as a development tool, or at the command line, why to make it hard to
just run a particular test executable? Why add complexity to each and
every package's source code or build system?
... or how to fix QFINDTESTDATA? This macro is the canonical way with
Qt. It should be made compatible with reproducible builds. The solution
might include environment variables, but implemented by Qt Test, not
implemented in each and every package.
And then one more step, and standardize the variables' names (like
SOURCE_DATE_EPOCH).
Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath
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? Last not least, "make install" is the canonical way of creating the set of artifacts meant for distribution. 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 Thanks! Kai
Bug#972294: openorienteering-mapper: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath
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
Bug#875847: Patch to fix ".qhc files not reproducible"
This patch fixes the creation of the offending timestamp, by clamping to
SOURCE_DATE_EPOCH as specified.
I also left a link to this Debian bug in Qt's code review for the
offending change.
Best regards,
Kai
Clamp registered collection time-stamp to SOURCE_DATE_EPOCH if set.
--- a/src/assistant/help/qhelpcollectionhandler.cpp
+++ b/src/assistant/help/qhelpcollectionhandler.cpp
@@ -2197,7 +2197,14 @@
m_query->addBindValue(fileName);
const QFileInfo fi(absoluteDocPath(fileName));
m_query->addBindValue(fi.size());
-m_query->addBindValue(fi.lastModified().toString(Qt::ISODate));
+QDateTime last_modified = fi.lastModified();
+if (qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))
+{
+qint64 source_date_epoch = qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH");
+if (source_date_epoch < last_modified.toSecsSinceEpoch())
+last_modified.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));
+}
+m_query->addBindValue(last_modified.toString(Qt::ISODate));
if (!m_query->exec())
return false;
Bug#972178: openorienteering-mapper: FTBFS with Qt 5.15: error: aggregate 'QPainterPath outside_path' has incomplete type and cannot be defined
Am 13.10.20 um 20:05 schrieb Dmitry Shachnev: Source: openorienteering-mapper Version: 0.9.3-1 Severity: important Tags: ftbfs User: debian-qt-...@lists.debian.org Usertags: qt5.15 Dear Maintainer, openorienteering-mapper fails to build with Qt 5.15, currently available in experimental: /build/openorienteering-mapper-0.9.3/src/gui/print_tool.cpp: In member function 'virtual void OpenOrienteering::PrintTool::draw(QPainter*, OpenOrienteering::MapWidget*)': /build/openorienteering-mapper-0.9.3/src/gui/print_tool.cpp:144:15: error: aggregate 'QPainterPath outside_path' has incomplete type and cannot be defined 144 | QPainterPath outside_path; | ^~~~ The full build log is attached. -- Dmitry Shachnev Fixed in 0.9.4, already released. Cf. https://build.opensuse.org/package/show/home:dg0yt/openorienteering-mapper Regards, Kai
Bug#941903: snapshot.debian.org: 404 error for one snapshot.debian.org IP address but not for the other
Am 21.10.19 um 15:11 schrieb Peter Palfrader: Evan Jones schrieb am Monday, dem 21. October 2019: THANK YOU and whoever else is involved in maintaining this. Just letting you know that I appreciate the work here. I don't work for Google, but I do use Distroless [1], a lightweight Debian-based container runtime that uses snapshot to have reproducible builds, so this was definitely annoying to work around. Thanks! [1] https://github.com/GoogleContainerTools/distroless I'm tempted to think that this tool should not use snapshot but the real mirrors that can handle the load way better. Thank you very much, indeed. Coincidentally, I'm also using the snapshots for non-debian build scripts (for Windows, macOS, Android). I'm not using the debian rules, but the copyright, patches, and DFSG source tarballs. I cannot switch versions at the pace of the debian packages, and I'm unaware of mirrors which provide long-term stable download URLs for older versions (except of uploads to/downloads from my own webspace). The sources are cached in CI, so the load should be very low anyway. OTOH it seems this kind of usage helps to discover such debian snapshots issues quickly. Kai.
Bug#942485: snapshot.debian.org: "404 Not found" for sqlite3_3.30.1-1.debian.tar.xz
This is probably the same issue as #941903.
Bug#919598: zlib: copyright file needs updating
Source: zlib Severity: normal Dear Maintainer, a) the zlib 1:1.2.11.dfsg-1 copyright file claims to be based on sources from zlib-1.0.4.tar.gz which is obviously wrong. b) the Files-Excluded field is not up-to-date for zlib_1.2.11.dfsg.orig.tar.gz. The listed contrib/testzlib is in the DFSG sources, but the now-removed win32 directory is not listed as Files-Excluded. The win32 directory is how I came here: I'm building for Mingw from the Debian sources, which now fails. Is the removal of the win32 directory neccessary? I do see the restrictions established in win32/DLL_FAQ.txt. However, I don't think these restrictions are removed by removing this file. They may apply to the DFSG sources as well, even with the win32 dir removed. Best regards Kai
Bug#903237: openorienteering-mapper: FTBFS with Qt 5.11.1 in experimental due to tests
Am 08.07.2018 um 06:03 schrieb Simon Quigley: Source: openorienteering-mapper Version: 0.8.1.1-1 Severity: important User: debian-qt-...@lists.debian.org Usertags: qt5.11.1 Dear Maintainer, Your package fails to build from source against Qt 5.11.1 in Experimental with the following error: ... 16: Test command: /usr/bin/cmake "-P" "transform_t-RUN.cmake" 16: Test timeout computed to be: 1000 16: * Start testing of TransformTest * 16: Config: Using QtTest library 5.11.1, Qt 5.11.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.3.0) 16: PASS : TransformTest::initTestCase() 16: PASS : TransformTest::testTransformBasics() 16: PASS : TransformTest::testTransformIdentity() 16: PASS : TransformTest::testTransformTranslate() 16: PASS : TransformTest::testTransformProject() 16: PASS : TransformTest::testTransformRotate(No rotation) 16: PASS : TransformTest::testTransformRotate(90 deg) 16: PASS : TransformTest::testTransformRotate(180 deg) 16: PASS : TransformTest::testTransformRotate(200 deg) 16: PASS : TransformTest::testTransformRotate(270 deg) 16: PASS : TransformTest::testTransformCombined(No rotation) 16: PASS : TransformTest::testTransformCombined(90 deg) 16: PASS : TransformTest::testTransformCombined(180 deg) 16: PASS : TransformTest::testTransformCombined(200 deg) 16: PASS : TransformTest::testTransformCombined(270 deg) 16: PASS : TransformTest::testTransformRoundTrip(No rotation) 16: PASS : TransformTest::testTransformRoundTrip(90 deg) 16: PASS : TransformTest::testTransformRoundTrip(180 deg) 16: PASS : TransformTest::testTransformRoundTrip(-160 deg) 16: PASS : TransformTest::testTransformRoundTrip(-90 deg) 16: PASS : TransformTest::testEstimateNonIsometric() 16: FAIL! : TransformTest::testEstimateSimilarityTransformation() Compared values are not the same 16: Actual (QPointF(passpoints[0].calculated_coords)): QPointF(1.95943e-15,-32) 16: Expected (QPointF(passpoints[0].dest_coords)) : QPointF(0,-32) 16: Loc: [/<>/test/transform_t.cpp(368)] 16: PASS : TransformTest::cleanupTestCase() 16: Totals: 22 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms 16: * Finished testing of TransformTest * 16: CMake Error at transform_t-RUN.cmake:35 (message): 16: Test transform_t failed: 1 16: I see this error since a few weeks in our builds for Fedora Rawhide and openSUSE Tumbleweed on OBS. What fails is a fuzzy comparison close to zero. It is not triggered by a change in openorienteering-mapper: 1.95943e-15 is the actual value also in builds that succeed. I was able to track this down to a change in Qt 5.11.1, and left a comment there: https://codereview.qt-project.org/#/c/227223/ The Qt bug may trigger more apps to FTBFS. Kai (upstream)
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: proj transition started, increasing severity to serious
Am 04.03.2018 um 10:03 schrieb Sebastiaan Couwenberg: severity 889931 serious severity 876934 serious severity 889936 serious thanks The proj transition (#891966) has started, these build failures are now RC. Kind Regards, Bas Again, 876934 was reported for FTBFS in reproducible builds. This should be fixed by updating to Mapper 0.8.0. openorienteering-mapper in Debian also FTBFS where libpoppler exports a C++ class Object in the global namespace, by tests failing due to (indirect!) linking, not even usage. It should be fixed by updating to Mapper 0.8.0. I don't expect an issues with proj 5.0.0. 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
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
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#865180: On Big Endian support
Relevant upstream changes for Big Endian builds are aed9a2d7d20d019c8cf5dff0d8e5edeee2b4d2d8 14a683b07b7657f766b84c6c67f9080bef8af7c5 Cf. https://github.com/OpenOrienteering/mapper/commits/14a683b07b7657f766b84c6c67f9080bef8af7c5/CMakeLists.txt
Bug#872291: openorienteering-mapper: unable to open files with spaces in their names
Am 15.08.2017 um 21:48 schrieb Graham Inggs: Source: openorienteering-mapper Version: 0.6.7-1 OpenOrienteering Mapper is unable to open files with spaces in their names from the command line. This also prevents users from double-clicking on a map with a space in its name from a file manager; e.g. Nautilus. These files can be opened from within OpenOrienteering Mapper though. $ cd /usr/share/openorienteering-mapper/examples/ $ Mapper 'forest sample.omap' Two error messages appear: Cannot open file: forest File format not recognized, and: It seems that OpenOrienteering Mapper crashed the last time this file was opened: forest Really retry to open it? Clicking 'No' results in the following: Cannot open file: sample.omap for reading. Not reproducible in latest upstream release and dev, from bash and from dash. The following works, too: $ cd /usr/share/openorienteering-mapper/examples/ $ Mapper forest\ sample.omap The relevant code uses QApplication::arguments and hasn't changed significantly since 2013: https://github.com/OpenOrienteering/mapper/blob/master/src/main.cpp#L147 https://github.com/OpenOrienteering/mapper/commit/14bfdef265343e22d91345793612eaf16c56c353 Check Qt / other Qt apps.
Bug#871820: openorienteering-mapper FTBFS: Test map_t Failed
The only relevant change in the environment I see is gcc-7. According to https://tracker.debian.org/pkg/gcc-7: "[2017-08-08] Accepted gcc-7 7.1.0-13 (source) into unstable" According to https://tests.reproducible-builds.org/debian/history/openorienteering-mapper.html, openorienteering-mapper 0.6.71 FTBFS on unstable amd64 since 2017-08-08 16:28. (Don't know what really fails inside the test, but it loads an external file, the path being determined using the __FILE__ macro. Hope the compiler didn't break this.)
Bug#865180: On Big Endian support
Mapper contains binary file format implementations which are known to break on Big Endian machines. Mapper remains usable without these file formats since the current native format is based on XML. However, the loss of the OCD format would harm exchange with common proprietary software. This might surprise some users. In addition, I didn't see a possibility to do Big Endian builds without much effort. This is now mitigated by the possibility to build with openSUSE Build service (even locally) for s390x. However, all changes which I could implement upstream would arrive in 0.7.x or later, and cannot easily be backported, due to major changes in source file structure and in CMake files. Kai, dg0yt
Bug#839205: openorienteering-mapper: New version available on Github
Package: openorienteering-mapper Version: 0.6.3-2 Dear Maintainer, OpenOrienteering Mapper is developed on Github (https://github.com/OpenOrienteering/mapper/). The current release is 0.6.5. The watch file in Debian needs to be corrected to point to Github instead of Sourceforge. Thanks.
