I tried to build MeshLab 1.3.2 on September 30, but it fails to build with another C++ problem:

In file included from decorate_base.h:29:0,
                 from decorate_base.cpp:24:
colorhistogram.h: In member function 'void vcg::ColorHistogram<ScalarType>::Clear()':
colorhistogram.h:43:11: error: '::::Clear' is not a class member

I've reported this upstream as ticket 340:

    https://sourceforge.net/p/meshlab/bugs/340/

I won't be able to package 1.3.2 for Fedora until either upstream fixes it, or someone comes up with a patch.

Created attachment 688430 [details]
Patch to correct this behavior

This should work well, but is not tested, as the current spec seems very complicated. Please show me new prepared spec for 1.3.2 (if it exists), or try it yourself.

Hi, have you looked at it. If you are not available or interested just tell me and I'll try to build the package.

I've got a SPEC and SRPM with your patch and other fixes, but a koji build for rawhide fails with:

/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character

Bug 304121 indicates that this error can occur do to an extraneous '/' in or at the end of a path, but I haven't found it yet.

http://fedorapeople.org/~brouhaha/meshlab/meshlab.spec
http://fedorapeople.org/~brouhaha/meshlab/meshlab-1.3.2-1.fc19.src.rpm

I think I found it, testing.

Created attachment 703984 [details]
Fix for debugedit // FTBFS

Yes, this patch fixes it.

Thanks. I wonder, how did you find it? Have you used some sophisticated grep, or you were manually browsing the code?

Thanks Jon and Miro!  I've just started a new build for rawhide.

(In reply to comment #7)
> Thanks. I wonder, how did you find it? Have you used some sophisticated
> grep, or you were manually browsing the code?

That's a great question.  grepping through a large c++ codebase for // isn't going to tell you anything particularly useful.  Additionally, I had to idea in what type of statement the // might be.  Fortunately, the last chuck of the build.log with the error was:

<snip>
extracting debug info from /builddir/build/BUILDROOT/meshlab-1.3.2-1.fc19.x86_64/usr/lib64/meshlab/plugins/libfilter_unsharp.so
extracting debug info from /builddir/build/BUILDROOT/meshlab-1.3.2-1.fc19.x86_64/usr/lib64/meshlab/plugins/libfilter_colorproc.so
extracting debug info from /builddir/build/BUILDROOT/meshlab-1.3.2-1.fc19.x86_64/usr/lib64/meshlab/plugins/libfilter_clean.so
extracting debug info from /builddir/build/BUILDROOT/meshlab-1.3.2-1.fc19.x86_64/usr/lib64/meshlab/plugins/libfilter_qhull.so
extracting debug info from /builddir/build/BUILDROOT/meshlab-1.3.2-1.fc19.x86_64/usr/lib64/meshlab/plugins/libfilter_quality.so
extracting debug info from /builddir/build/BUILDROOT/meshlab-1.3.2-1.fc19.x86_64/usr/lib64/meshlab/plugins/librender_splatting.so
/usr/lib/rpm/debugedit: canonicalization unexpectedly shrank by one character
<snip>

So I went to meshlab/src/meshlabplugins/render_splatting.

grep "//" * revealed the GPL URL, some comments, whatever is going on in splatrenderer_plugin.cpp line 73, and the two #include statements.  Since I wasn't sure about line 73, and the extra /s in the #includes were pointless, I patched those out, made a fresh SRPM, ran it through mock, and it worked.

(In reply to comment #9)
> That's a great question.  grepping through a large c++ codebase for // isn't
> going to tell you anything particularly useful.
No, it's not :)

> grep "//" * revealed the GPL URL, some comments, whatever is going on in
> splatrenderer_plugin.cpp line 73, and the two #include statements.  Since I
> wasn't sure about line 73, and the extra /s in the #includes were pointless,
> I patched those out, made a fresh SRPM, ran it through mock, and it worked.
Cool. Thanks for the answer.

Very welcome!