Xdmf2 is shipped with paraview sources, but is also used in the VisIt software (which is being packaged), so I have packaged it as xdmf and it is now available (version 2.1) in debian unstable. Please use this version rather than the internal xdmf. Thanks Alastair McKinstry
severity 641542 serious thanks This is a violation of policy on convenient library. Marking as serious.
Hi Alastair, it seems, there are different versions of xdmf (or fork), if I correctly understood from this thread [1]. ======== Biddiscombe, John A. "...the vtkXdmfReader in paraview would need to be rewritten to use the new Xdmf API..." ======== [1] http://www.paraview.org/pipermail/paraview/2011-December/023547.html Anton
I'm going to reduce the severity of the bug to the "Wishlist". Rewriting the software is not the task of packaging. The RC-bug will probably remove Paraview from Wheezy [1], [2]. Comments are welcome. [1] http://lists.debian.org/debian-devel/2012/01/msg00653.html [2] http://release.debian.org/~nthykier/rc-buggy-leaf-pkgs-dd-list-2012-01-25 Anton
severity 641542 wishlist thanks
We have been trying to reach you as regards the estate of Late George Brumley, you were made one of the beneficiaries of his estate. Do get back to me at your earliest convenience. The Trustees
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)
I mentioned that Kitware is developing xdmf at https://gitlab.kitware.com/xdmf/xdmf But looking at VTK MR#12864, more closely, it was copied from https://gitlab.kitware.com/spiros.tsalikis/xdmf which is a fork of https://gitlab.kitware.com/third-party/xdmf https://gitlab.kitware.com/xdmf/xdmf https://gitlab.kitware.com/spiros.tsalikis/xdmf or https://gitlab.kitware.com/third-party/xdmf ? Will the real Xdmf please stand up?
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@debian.org> wrote: Package: paraview Followup-For: Bug #641542 X-Debbugs-Cc: Alastair McKinstry <mckinstry@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)
I think the general request of the bug is still valid. Kitware should keep https://gitlab.kitware.com/xdmf/xdmf up to date, and fit for use by VTK, so VTK's xdmf3 ought to have an EXTERNAL configuration option available. People might still ask about the external xdmf library, so we might as well keep the bug open. I'll update the title to xdmf3 and link to VTK upstream issue #17702 (unifying xdmf support). Drew