VTK 9.1.0.rc4 has been tagged

Hi all,

9.1.0.rc4 (rc3 had some process timing issues that ended up forcing it to be skipped) is out on PyPI and the repository. The website should be updated within a day or two. This is to be the last rc before the final release later this week. Please report any issues.



1 Like

Thanks Ben,

I bumped our internal Ubuntu packaging to 9.1.0.rc4 and ran into one build problem for which I made this MR https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8596 (merged now)

Right now I’m getting

cd /buildbot/b-vtk9/build/debian/build/GUISupport/QtQuick/qml && /usr/bin/qmlplugindump -output /buildbot/b-vtk9/build/debian/build/lib/qml/VTK.9.1/plugins.qmltypes VTK 9.1 /buildbot/b-vtk9/build/debian/build/lib/qml
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-buildbot'
QQmlComponent: Component is not ready
make[3]: *** [GUISupport/QtQuick/qml/CMakeFiles/qmlvtkplugin.dir/build.make:136: lib/qml/VTK.9.1/libqmlvtkplugin.so] Error 3
make[3]: *** Deleting file 'lib/qml/VTK.9.1/libqmlvtkplugin.so'
make[3]: Leaving directory '/buildbot/b-vtk9/build/debian/build'
make[2]: *** [CMakeFiles/Makefile2:16469: GUISupport/QtQuick/qml/CMakeFiles/qmlvtkplugin.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....

At least I think that qmlplugindump invocation is what is failing (I’ll try with a -j1 build to make sure).

Do you know who to turn to regarding the QML plugin?

(We do the build in an Ubuntu 20.04 Docker container, hence the message about unset XDG_RUNTIME_DIR. We set QT_QPA_PLATFORM=offscreen in the environment if it matters, but I don’t think qmlplugindump should require a GUI?)

I’m sure this is probably some simple detail.

Yes, this has been seen multiple times, but I’ve not been able to pin it down. The “Component is not ready” seems to imply that the module is not loadable (more logging from Qt would be really helpful here). Our CI is fine with the Ninja generator; it may be worth using that to build VTK for the time being (until someone who can reproduce the issue grabs more useful error information from Qt itself here).

Cc: @sankhesh

Thanks Ben, I’ll see if I can dig out some Qt env var to get more verbose info. I’ll also try Ninja (may be a good idea to switch the build to that anyway).

@estan Could you please check:

  1. If you have the changes from https://gitlab.kitware.com/vtk/vtk/-/merge_requests/8516 in your source?
  2. If you do, could you please post the contents of <vtk-bld>/lib/qml?

We’re building from the https://www.vtk.org/files/release/9.1/VTK-9.1.0.rc4.tar.gz tarball which has that change.

Alright, will do. Our build is automated in a Docker container which perish when the build finishes, but I’ll try to catch it in the act (or reproduce on my laptop which is also Ubuntu 20.04). May not get to it today, but will do it ASAP.

Maybe the cmake policy CMP0127 warnings from newest cmake are worth fixing?