No reply from upstream for over a month. Maybe someone with upstream connections can help.
Should be fixed in https://gitlab.kitware.com/vtk/vtk/-/commit/3efa07ad277efe5c1d11a2ef2b907c095f68bbef
Hi Paul, thanks for the pointer and bringing this back to attention. The issue is fixed upstream only in >=9.3.1 … # git --no-pager tag --contains 3efa07ad277efe5c1d11a2ef2b907c095f68bbef v9.3.1 …and there is no 9.3.1 in Gentoo and no backported patch in any Gentoo ebuild either. I am therefore re-opening, this is unfixed in Gentoo. Please let me know anything that I might be missing.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=546ead3103af153d5e869730fe0ad642019a9c67 commit 546ead3103af153d5e869730fe0ad642019a9c67 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2024-09-04 11:42:05 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2024-09-04 11:42:05 +0000 sci-libs/vtk: Protect against use with >=dev-libs/expat-2.6.0 Bug: https://bugs.gentoo.org/930032 Signed-off-by: Sebastian Pipping <sping@gentoo.org> sci-libs/vtk/vtk-9.2.5.ebuild | 4 ++-- sci-libs/vtk/vtk-9.2.6-r1.ebuild | 4 ++-- sci-libs/vtk/vtk-9.3.0.ebuild | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
Could this patch be backported to 9.3.0 or am I missing something? Cheers, Rémi
(In reply to Rémi Cardona from comment #4) > Could this patch be backported to 9.3.0 or am I missing something? Either that (in general) or a bump to 9.3.1 (bug #939045), yes.
https://gitlab.kitware.com/vtk/vtk/-/issues/19258 implies it's runtime breakage hence a revbump should be done.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d767aab3f077c05916d47ffdc38a09927b04298d commit d767aab3f077c05916d47ffdc38a09927b04298d Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2024-09-06 20:35:43 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-09-06 20:35:43 +0000 sci-libs/vtk: revbump for expat RDEPEND fix Without this revbump, people with existing installed copies of vtk won't see the change and will end up with broken installs. Bug: https://bugs.gentoo.org/930032 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> sci-libs/vtk/{vtk-9.2.5.ebuild => vtk-9.2.5-r1.ebuild} | 0 sci-libs/vtk/{vtk-9.2.6-r1.ebuild => vtk-9.2.6-r2.ebuild} | 0 sci-libs/vtk/{vtk-9.3.0.ebuild => vtk-9.3.0-r1.ebuild} | 0 3 files changed, 0 insertions(+), 0 deletions(-)
This really isn't going to work either way. If Python depends on >= expat to avoid things like bug 939045, you soon get to a point where VTK is uninstallable if VTK has a < dep. If it doesn't, you get runtime breakage with VTK if it has a < dep. If VTK doesn't have a < dep, you get runtime breakage in Python as it gets downgraded when you emerge VTK. We should drop the < and leave VTK broken as it's the lesser evil, and then try pull in the patch if it applies cleanlyish. I'll handle that now.
(In reply to Sam James from comment #8) > This really isn't going to work either way. > > If Python depends on >= expat to avoid things like bug 939045, you soon get > to a point where VTK is uninstallable if VTK has a < dep. (bug 939211, I mean) > [...]
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=147183f1c2ca93eaf6db4f308c94e9aa226ea7b4 commit 147183f1c2ca93eaf6db4f308c94e9aa226ea7b4 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-07 09:13:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-07 09:15:12 +0000 sci-libs/vtk: don't cap expat version This reverts commit 546ead3103af153d5e869730fe0ad642019a9c67 and d767aab3f077c05916d47ffdc38a09927b04298d as a consequence. As I explained on the bug: """ This really isn't going to work either way. If Python depends on >= expat to avoid things like bug 939045, you soon get to a point where VTK is uninstallable if VTK has a < dep. If it doesn't, you get runtime breakage with VTK if it has a < dep. If VTK doesn't have a < dep, you get runtime breakage in Python as it gets downgraded when you emerge VTK. We should drop the < and leave VTK broken as it's the lesser evil, and then try pull in the patch if it applies cleanlyish. """ So, let's do the lesser evil bit now to avoid runtime breakge in CPython from it being downgraded. Bug: https://bugs.gentoo.org/930032 Closes: https://bugs.gentoo.org/939211 Signed-off-by: Sam James <sam@gentoo.org> sci-libs/vtk/{vtk-9.2.5-r1.ebuild => vtk-9.2.5-r2.ebuild} | 2 +- sci-libs/vtk/{vtk-9.2.6-r2.ebuild => vtk-9.2.6-r3.ebuild} | 2 +- sci-libs/vtk/{vtk-9.3.0-r1.ebuild => vtk-9.3.0-r2.ebuild} | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5b0280e7b92008879c644166456c9895b0dc123 commit b5b0280e7b92008879c644166456c9895b0dc123 Author: Paul Zander <negril.nx+gentoo@gmail.com> AuthorDate: 2024-09-07 15:25:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-08 13:50:24 +0000 sci-libs/vtk: revbump to backport expat fix from 9.3.1 The underlaying issue is only present in IOXMLParser which we uncondionally build but is only required by paraview. Which bundles it's own vtk. https://gitlab.kitware.com/vtk/vtk/-/issues/19258 https://discourse.paraview.org/t/i-cannot-read-a-vtp-file-i-could-open-yesterday-can-someone-try-to-open-it/13938/4 Closes: https://bugs.gentoo.org/930032 Signed-off-by: Paul Zander <negril.nx+gentoo@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> sci-libs/vtk/files/vtk-9.3.0-r1-expat-2.6.0.patch | 72 ++++++++++++++++++++++ .../{vtk-9.3.0-r2.ebuild => vtk-9.3.0-r3.ebuild} | 1 + 2 files changed, 73 insertions(+)
