The DMRTest is failing on big endian arches. from build.log ... make check-TESTS make[3]: Entering directory '/builddir/build/BUILD/libdap-3.14.0/tests' make[4]: Entering directory '/builddir/build/BUILD/libdap-3.14.0/tests' PASS: DASTest PASS: DDSTest PASS: EXPRTest FAIL: DMRTest ============================================================================ Testsuite summary for libdap 3.14.0 ============================================================================ ... more details will follow Version-Release number of selected component (if applicable): libdap-3.14.0-3.fc23
failed build on ppc64 http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2520606
Created attachment 1034620 [details] test log file
*** Bug 1241593 has been marked as a duplicate of this bug. ***
Upstream is looking into it.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Orion, is it safe to use libdap 3.13.3 instead of the 3.14 until there is an upstream solution for this problem? By safe I mean are they API/ABI compatible?
I suspect it's API compatible (nothing needed to be modified to compile with 3.14), but it looks like there are ABI breaks, despite not bumping the soname version.
ok, then we will wait instead of building against the older 3.13 version
seems to be fixed in 3.16.0 - http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2938873
(In reply to Dan Horák from comment #9) > seems to be fixed in 3.16.0 - > http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2938873 but it depends on a non-generic define, so it fails on s390/s390x. I've reported the issue to upstream.