New release is available upstream: https://github.com/cnr-isti-vclab/meshlab/releases/tag/MeshLab-2022.02 Reproducible: Always
soft bump
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c9a290239287bf9a67b1e6ef31d50d8d95954fca commit c9a290239287bf9a67b1e6ef31d50d8d95954fca Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-03-01 00:11:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-01 00:32:31 +0000 media-gfx/meshlab: remove various totally erroneous dependencies mpir: mpir is an ancient fork of gmp from 2017. It claims to be focused on speed. It doesn't build with modern compilers due to Modern C issues, and it fails to build with LTO as well. Unlike gmp, this will never be fixed. meshlab can look for either mpir or gmp, but we depended on BOTH and only gmp got used. mpir was completely extraneous. levmar: It would be great if we could use the system levmar, as meshlab genuinely depends on it. But it hardcodes a vendored copy: https://github.com/cnr-isti-vclab/meshlab/blob/bd88167db9839109487f401be50991c4bc990d27/src/external/levmar.cmake qhull: Currently, the build logs this: -- Could NOT find Qhull: missing: libqhull (found /usr/lib64/cmake/Qhull/QhullConfig.cmake (found version "8.0.2")) This happens because cmake is broken, probably. But meshlab 2021 ports to libqhull_r, which "should" work fine. Pity we are stuck in 2020 instead. We really could and should use the system copy but the build system cannot and does not detect it, which means we shouldn't be depending on something we cannot use. Bug: https://bugs.gentoo.org/905859 Bug: https://bugs.gentoo.org/812950 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> .../{meshlab-2020.12-r2.ebuild => meshlab-2020.12-r3.ebuild} | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
