hugin/2019.0.0+dfsg-2 debian sid/testing crashing on start (mad64 as well x86)/32bit

[c]

greetings to the team!

on both of my machines (x86/32bit and amd64) the debian-package of hugin crashes on start with the same behaviour.

$ hugin

(hugin:24142): Gtk-CRITICAL **: 17:54:57.385: gtk_widget_set_size_request: assertion 'height >= -1' failed
...
/usr/share/hugin/data/plugins/top_five.py
   CAT:Control Points
   NAM:keep 5 CPs per image pair
   fails @api-max
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
   fails @api-max
/usr/share/hugin/data/plugins/crop_cp.py
   CAT:Control Points
   NAM:Crop Control Points
   fails @api-max
/usr/share/hugin/data/plugins/shooting_pattern.py
   CAT:initial distribution
   NAM:6-1-1 Shooting Pattern
   fails @api-max
Aborted

unfortununatly no further informations are available.

this behaviour starts after upgrading system from BUSTER to BULLSEYE/SID/TESTING. yes Xwayland is in use, but this is not new. hugin worked perfectly under the BUSTER - which was using Xwayland as well.

I'm using hugin since the early days - a favorite project at all

best regards carsten

[tmodes (tmodes)]

The backtrace show that the crash happens in some X window function.
This is an indication that Hugin runs on Wayland.
Try setting GDK_BACKEND to x11 explicitly before running Hugin:
GDK_BACKEND=x11 hugin
If this works, then your hugin is not compiled with the needed Wayland patch.

[c (murmel)]

indeed exporting GDK_BACKEND=x11 worked. hugin started successfully.

with this workaround this bug could be closed.
thank you for this hint.

[tmodes (tmodes)]

Thanks for feedback.
So this should be reported to Debian, which should adopt their build process by adding -DUSE_GDKBACKEND_X11=on to the CMake command.

This is also mentioned in the release notes:

Known issues

Hugin does not run native on Wayland because of a bug in the underlying wxWidgets library.
The source code contains a workaround which forces the usage of the XWayland emulation layer. This workaround has be activated during compiling by adding -DUSE_GDKBACKEND_X11=on to the CMake command line.