Works.

sudo apt install libxcomposite1 libxcursor1

Pushed new branch T27135-DisablePrecompiledHeadersInOpenCV.

In T27069#195000, @floca wrote:

Yes. This solved the problem. Still do not understand why only LabelSetImages where that problematic, but thanks for having a look. The second pair of eyes really helped.

The fix is to replace the calls of repaint() with update() in QmitkNodeSelectionButton.cpp. More info: https://doc.qt.io/qt-5/qwidget.html#repaint

I deactivated FXAA in the RenderingManager and BaseRenderer and while the error output is still the same, the crash doesn't happen anymore. Instead, one of the four render windows is black until it is redrawn for example by clicking in it.

Did a first test on my PC and the exception is thrown from the Nvidia OpenGL driver (nvoglv64.dll) because of a null pointer access. So whatever causes it to happen, there is at least also a bug in the driver.

Pushed new branch T27130-RemoveQtVariablesFromDashboardScripts.

Then let's wait until we talked to the Openstack admins regarding Windows instances. If we can have them in the same Openstack project, resource requirements change anyway. If we cannot have them in the same project, we may just want to increase RAM to 160 GB to have 10 Linux build clients.

Was able to (probably) completely provision Ubuntu 18.04 instances for MITK builds with a cloud-config file.

Was able to successfully connect an OpenStack Ubuntu 18.04 to Jenkins via SSH. Currently writing a cloud-config file to provision the instances for MITK.

FYI: When changing/removing properties there's always the chance that old mitk scene files are suddenly incompatible as properties are stored in them. If that's an issue, property aliases may be a solution for a legacy mapping between property names.

• I would like to see the plugin generator loosing complexity by removing its project template capabilities
• The current approach is https://github.com/MITK/MITK-ProjectTemplate
• The project template is based on the last release, resp. releases/2018-04
• The project template is an MITK extension
• MITK extensions can be easily set in a recent version of our CDash script
• To test the project template, we need separate build clients based on the last release instead of master, no specific test has to be executed (see bullet point above)
• A few tests are currently not executed because I removed CTest subproject labels for testing purposes and I forgot to reintroduce them
• Instead of simply adding them again, I vote for a better label than "MITK" or "MITK-Plugins" like "MITK-Packaging"

Pushed new branch T27082-RectifyImageApp.

It's an experimental app that already helped us to load some images that otherwise were flipped or oriented the wrong way. Probably does not work with oblique images. I'll move the app to the BasicImageProcessing module.

Oops, meant to comment on the Differential, not on this commit. See D240 instead.

Here's a screenshot from the last release. All the tools are deactivated as long as there isn't any visible object.

While there should be a nullptr check I guess, this is another regression in the first place as it wasn't possible with the Measurement view to draw with an empty storage until recently. Is this possibly related to your work on selections?

Merged! 🎉 Will be available in CMake 3.17.

Pushed new branch T27024-FixVolumeTest.

I activated MITK_AUTOCLEAN_EXTERNAL_PROJECTS on Differential and Continuous jobs. Fingers crossed.

Pushed new branch T27042-AutocleanExternalProjects.

I just thought about it could be a good idea to actually do this in our CMake script right in MITK. We can check all sorts of things there before and after external project processing.

In T26980#193572, @floca wrote:

@kislinsk You mentioned that we should do something as soon as the (wrong) autload dependencies are gone. I cannot remember what, do you? May be some work arround in our packaging code due to the autoload modules?

Possibly useful Jenkins plugins:

We also have the possibility to modify the Herald rule that triggers the jobs. For example, if the revision summary contains a certain keyword, trigger a complete rebuild instead of an incremental build. Two disadventages are: Revision creators have to be aware of this possibility, and this is not enough as there may be also some other changes on the master branch since the last build on the build client that affect critical files.

Possible entry points in Jenkions job configuration:

Pushed new branch T27041-MITK_CUSTOM_REVISION_DESC.

Pushed new branch T27038-CTestSubprojectsInExtensions.

Pushed new branch T27037-CleanUpUnusedComponents.