<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Hi
Drew</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Sorry
on the delay in replying, I got hit with a VPN bug and couldn't
reach my email from my current laptop.</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I
think reframe it. Your reading of the problem is correct, I think.</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">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.</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I've
no plans (or time ) to package VisIt, so don't see the need. </div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">We
could either leave it as wishlist, or close</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">Regards<br>
Alastair</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</div>
<div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">On
01/02/2026, 17:49, "Drew Parsons" <a class="moz-txt-link-rfc2396E" href="mailto:dparsons@debian.org"><dparsons@debian.org></a>
wrote:</div>
<br>
<div>Package: paraview</div>
<div>Followup-For: Bug #641542</div>
<div>X-Debbugs-Cc: Alastair McKinstry <<a
href="mailto:mckinstry@debian.org" class="moz-txt-link-freetext">mckinstry@debian.org</a>></div>
<div>Control: reassign -1 src:vtk9 9.5.2+dfsg3-1</div>
<div dir="ltr"><br>
</div>
<div dir="ltr"><br>
</div>
<div>Hi Alastair, do you think Bug#641542 is still live, or should
we close</div>
<div>it now, or reframe it?</div>
<div dir="ltr"><br>
</div>
<div>There's a couple of points on the current state of it.</div>
<div dir="ltr"><br>
</div>
<div>Firstly the vendored xdmf code was in VTK not paraview as such.</div>
<div>paraview had been vendering its own VTK code due to
incompatibility</div>
<div>with libvtk9-dev, but that is now resolved with paraview 6 /
vtk9 9.5.</div>
<div>The xdmf code is still in VTK, so I'm moving this bug from
paraview</div>
<div>to vtk9.</div>
<div dir="ltr"><br>
</div>
<div>Next, vtk9 does vendor both xdmf2 and xdmf3 in ThirdParty.</div>
<div>But debian's separate libxdmf-dev is xdmf3 not xdmf2 (if I
understood</div>
<div>correctly).</div>
<div dir="ltr"><br>
</div>
<div>vtk9 does allow to build with some external libraries. We're
doing</div>
<div>that with eigen, expat, zlib and others. vtk allows for this
with a</div>
<div>EXTERNAL option in the CMakeLists.txt for the ThirdParty
component dir.</div>
<div dir="ltr"><br>
</div>
<div>But in the case of both xdmf2 and xdmf3, vtk is using</div>
<div>vtk_module_third_party_internal, with no EXTERNAL.</div>
<div dir="ltr"><br>
</div>
<div>I tried briefly to patch ThirdParty/xdmf3 to use the external</div>
<div>libxdmf-dev, but VTK didn't find the external library cleanly.
It can</div>
<div>probably be done but it will need some effort. Is it worth the
effort?</div>
<div dir="ltr"><br>
</div>
<div>But even if vtk9 is patched to use external libxdmf-dev, that's
xdmf3</div>
<div>not xdmf2 (correct me if I'm wrong about that).</div>
<div dir="ltr"><br>
</div>
<div>Kitware has taken responsibility for ongoing xdmf code
development at</div>
<div><a href="https://gitlab.kitware.com/xdmf/xdmf"
class="moz-txt-link-freetext">https://gitlab.kitware.com/xdmf/xdmf</a></div>
<div>But they haven't (yet) facilitated enabling VTK to use xdmf as
an external</div>
<div>xdmf library. Instead, they've just been updating their
vendored copy</div>
<div>from time to time when needed, most recently last week with</div>
<div><a
href="https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12864"
class="moz-txt-link-freetext">https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12864</a></div>
<div dir="ltr"><br>
</div>
<div>With respect to VisIt, paraview 6 uses Utilities/VisItBridge to
access</div>
<div>VisIt, rather than providing VisIt directly. As far as I can
see VTK</div>
<div>doesn't contain VisIt either. So there's currently no second
copy of</div>
<div>xdmf2 as such. Debian currently isn't packaging VisIt itself,
but I</div>
<div>can't see a direct copy of xdmf (either version) in the VisIt
source at</div>
<div><a
href="https://github.com/visit-dav/visit/tree/develop/src/third_party_builtin"
class="moz-txt-link-freetext">https://github.com/visit-dav/visit/tree/develop/src/third_party_builtin</a></div>
<div>src/CMake/FindXdmf.cmake seems to imply they would get xdmf
from vtk</div>
<div>(vtklibxml2)</div>
<div dir="ltr"><br>
</div>
</body>
</html>