Created attachment 155831 [details] fix /usr/local/include/wx-3.0/wx/strvararg.h:350:18: error: 'is_enum' in namespace 'std' does not name a template type typedef std::is_enum<T> is_enum; ^ /usr/local/include/wx-3.0/wx/strvararg.h:354:54: error: 'is_enum' was not declared in this scope enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value }; ^ /usr/local/include/wx-3.0/wx/strvararg.h:354:68: error: template argument 1 is invalid enum { value = wxFormatStringSpecifierNonPodType<is_enum::value>::value }; las_export.cpp:336:25: error: operands to ?: have different types 'double' and 'std::nullptr_t' x < xmin ? xmin = x : NULL; ^ las_export.cpp:337:25: error: operands to ?: have different types 'double' and 'std::nullptr_t' x > xmax ? xmax = x : NULL; ^ las_export.cpp:338:25: error: operands to ?: have different types 'double' and 'std::nullptr_t' y < ymin ? ymin = y : NULL; ^ las_export.cpp:339:25: error: operands to ?: have different types 'double' and 'std::nullptr_t' y > ymax ? ymax = y : NULL; ^ las_export.cpp:340:25: error: operands to ?: have different types 'double' and 'std::nullptr_t' z < zmin ? zmin = z : NULL; ^ las_export.cpp:341:25: error: operands to ?: have different types 'double' and 'std::nullptr_t' z > zmax ? zmax = z : NULL; ^ http://muscles.dragonflybsd.org/bulk/latest-per-pkg/saga/2.1.4/bleeding-edge-potential.log https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20150420/230843.html https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20150420/231046.html
Created attachment 155832 [details] 9.3R i386 build log (compressed)
Created attachment 155836 [details] 10.1R i386 build log (compressed)
The port did build fine on FreeBSD before before r383466. Note, only python27-2.7.9 -> python27-2.7.9_1 and wx30-gtk2-3.0.2_2 -> wx30-gtk2-3.0.2_3 happend between the following runs. http://beefy1.isc.freebsd.org/data/93i386-default/383446/logs/saga-2.1.4.log http://beefy1.isc.freebsd.org/data/93i386-default/383569/logs/errors/saga-2.1.4.log I didn't notice all platforms use GCC because of USES=compiler:gcc-c++11-lib. So, the reason the port builds fine on F10+ despite absence of -std=c++11 is likely because of libc++. http://beefy5.nyi.freebsd.org/data/101i386-default/384362/logs/saga-2.1.4.log
Jan, I don't think you actually need maintainer permission to unbreak this. It's probably sufficient to inform you are doing it, then reference PR in the commit message. Unless your fix has some controversial element or something...
patch looks fine to me. If Rainer doesn't respond soon, you can use "Approved by: marino" if you still need approval to commit.
Hi Jan, thanks for your work on a patch. I also tried to find a solution in the last days, but failed until now. Your patch seems to work fine. So, it would be fine, if you could commit the patch. I will try to get your patch for patch-src__modules__io__io_shapes_las__las_export.cpp upstream into the saga sources. If this has happend, I will report back and prepare a new patch to remove this from the port again. Would this be ok in your eyes?
A commit references this bug: Author: jbeich Date: Wed Apr 22 17:15:00 UTC 2015 New revision: 384500 URL: https://svnweb.freebsd.org/changeset/ports/384500 Log: Unbreak build on platforms using libstdc++ after r383466 Force C++11 mode and fix incompatibility with NULL being defined as nullptr on FreeBSD. PR: 199600 Reported by: pkg-fallout, DPorts Approved by: Rainer Hurling <rhurlin@gwdg.de> (maintainer) Changes: head/math/saga/Makefile head/math/saga/files/patch-src__modules__io__io_shapes_las__las_export.cpp
(In reply to Rainer Hurling from comment #6) > So, it would be fine, if you could commit the patch. Please, use bugzilla flags if possible. Bug 197656 was fixed months ago. > I will try to get your patch for > patch-src__modules__io__io_shapes_las__las_export.cpp upstream into > the saga sources. Thanks. Upstreaming stuff is important but often time-consuming. > If this has happend, I will report back and prepare a new patch to > remove this from the port again. Would this be ok in your eyes? Replacing the fix is fine as long as you don't regress this bug.
Thanks for the hint with the bugzilla flags. Last time, I consciously noticed them, they were not usable for maintainers. For the sake of completeness I changed the flag into '+'.