Bug#641542: paraview: Please use xdmf2 package rather than internal versionof xdmf
Alastair McKinstry
alastair.mckinstry at mckinstry.ie
Wed Feb 4 14:54:49 GMT 2026
Hi Drew
Sorry on the delay in replying, I got hit with a VPN bug and couldn't
reach my email from my current laptop.
I think reframe it. Your reading of the problem is correct, I think.
I packaged xdmf way-back-when and moved it directly to xdmf3 thinking it
would (should) work like any other library, with transitions. Not
expecting an application to use both xdmf2 and xdmf3.
I've no plans (or time ) to package VisIt, so don't see the need.
We could either leave it as wishlist, or close
Regards
Alastair
On 01/02/2026, 17:49, "Drew Parsons" <dparsons at debian.org> wrote:
Package: paraview
Followup-For: Bug #641542
X-Debbugs-Cc: Alastair McKinstry <mckinstry at debian.org>
Control: reassign -1 src:vtk9 9.5.2+dfsg3-1
Hi Alastair, do you think Bug#641542 is still live, or should we close
it now, or reframe it?
There's a couple of points on the current state of it.
Firstly the vendored xdmf code was in VTK not paraview as such.
paraview had been vendering its own VTK code due to incompatibility
with libvtk9-dev, but that is now resolved with paraview 6 / vtk9 9.5.
The xdmf code is still in VTK, so I'm moving this bug from paraview
to vtk9.
Next, vtk9 does vendor both xdmf2 and xdmf3 in ThirdParty.
But debian's separate libxdmf-dev is xdmf3 not xdmf2 (if I understood
correctly).
vtk9 does allow to build with some external libraries. We're doing
that with eigen, expat, zlib and others. vtk allows for this with a
EXTERNAL option in the CMakeLists.txt for the ThirdParty component dir.
But in the case of both xdmf2 and xdmf3, vtk is using
vtk_module_third_party_internal, with no EXTERNAL.
I tried briefly to patch ThirdParty/xdmf3 to use the external
libxdmf-dev, but VTK didn't find the external library cleanly. It can
probably be done but it will need some effort. Is it worth the effort?
But even if vtk9 is patched to use external libxdmf-dev, that's xdmf3
not xdmf2 (correct me if I'm wrong about that).
Kitware has taken responsibility for ongoing xdmf code development at
https://gitlab.kitware.com/xdmf/xdmf
But they haven't (yet) facilitated enabling VTK to use xdmf as an external
xdmf library. Instead, they've just been updating their vendored copy
from time to time when needed, most recently last week with
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12864
With respect to VisIt, paraview 6 uses Utilities/VisItBridge to access
VisIt, rather than providing VisIt directly. As far as I can see VTK
doesn't contain VisIt either. So there's currently no second copy of
xdmf2 as such. Debian currently isn't packaging VisIt itself, but I
can't see a direct copy of xdmf (either version) in the VisIt source at
https://github.com/visit-dav/visit/tree/develop/src/third_party_builtin
src/CMake/FindXdmf.cmake seems to imply they would get xdmf from vtk
(vtklibxml2)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20260204/e3dbfbf9/attachment-0001.htm>
More information about the debian-science-maintainers
mailing list