Bug 1045553

Summary: ncurses version of yast2 is started instead of qt/gtk
Product: [openSUSE] openSUSE Tumbleweed Reporter: Vit Pelcak <vpelcak>
Component: GNOMEAssignee: E-mail List <gnome-bugs>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: dimstar, fezhang, mfilka, mstaudt, vpelcak
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: yast2 logs

Description Vit Pelcak 2017-06-22 13:03:42 UTC
Created attachment 729862 [details]
yast2 logs

running yast21 --gtk/qt always ends up with yast2 being started in ncurses.

#rpm -qv yast2
yast2-3.2.38-1.1.x86_64
# rpm -qv libyui-qt-pkg7
libyui-qt-pkg7-2.45.12-1.4.x86_64
# rpm -qv libyui-qt7
libyui-qt7-2.47.1-1.3.x86_64

y2logs in attachment.

Feel free to ask for more info.
Comment 1 Michal Filka 2017-06-23 09:08:45 UTC
Do you run it e.g. from root terminal / konsole which was started from non-privileged X environment?
Comment 2 Vit Pelcak 2017-06-26 11:06:27 UTC
(In reply to Michal Filka from comment #1)
> Do you run it e.g. from root terminal / konsole which was started from
> non-privileged X environment?

How do I find out whether X environment is non-privileged?

I run it from gnome-terminal as superuser in standard GNOME session.

It used to work before just fine.
Comment 3 Steffen Winterfeldt 2017-07-03 14:48:22 UTC
Is the $DISPLAY environment var set?
Comment 4 Steffen Winterfeldt 2017-07-04 13:37:43 UTC
looks similar to bug 1046317
Comment 5 Vit Pelcak 2017-07-04 13:52:01 UTC
(In reply to Steffen Winterfeldt from comment #3)
> Is the $DISPLAY environment var set?

Hm. No. echo $DISPLAY says nothing.
Comment 6 Stefan Hundhammer 2017-07-05 08:44:52 UTC
(In reply to Vit Pelcak from comment #5)
> (In reply to Steffen Winterfeldt from comment #3)
> > Is the $DISPLAY environment var set?
> 
> Hm. No. echo $DISPLAY says nothing.

Then you don't have a working X11 environment. Please make sure $DISPLAY is set.
Comment 7 Steffen Winterfeldt 2017-07-07 11:23:51 UTC
Just did a tw gnome install and the DISPLAY var was correctly set in the gnome terminal. yast worked fine.

Sorry, I think this a config issue on your side. Probably you're unsetting DISPLAY in one of your scripts.
Comment 8 Vit Pelcak 2017-07-10 13:56:39 UTC
rheia:~ # export DISPLAY=:0
rheia:~ # echo $DISPLAY
:0
rheia:~ # yast2 sw_single 
No protocol specified
terminate called after throwing an instance of 'YUIException'
  what():  Can't open display 
/sbin/yast2: line 448:  7509 Aborted                 (core dumped) $ybindir/y2start $module "$@" "$SELECTED_GUI" $Y2_GEOMETRY $Y2UI_ARGS
rheia:~ # echo $DISPLAY
:0
Comment 9 Vit Pelcak 2017-07-10 13:58:37 UTC
I also tried 

> xdg-su -c yast2

(gnomesu:7687): Gtk-WARNING **: gtk_window_set_titlebar() called on a realized window
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

And yast was not started.
Comment 10 Steffen Winterfeldt 2017-07-11 09:07:50 UTC
Did you do a default installation or did you change some settings? I cannot reproduce this.
Comment 11 Vit Pelcak 2017-07-14 08:55:03 UTC
I found the reason.

It is caused by Wayland/Weston. When you install gnome-session-wayland, then Wayland is used.

Wayland is probably lacking this functionality.
When you uninstall gnome-session-wayland, it works again.

So I believe bug should be reassigned to Xorg/Wayland maintainers.

Sorry for the noise.
Comment 12 Stefan Dirsch 2017-07-14 10:00:30 UTC
I guess this happens on a GNOME session running on Wayland. I would say, that GNOME needs to make sure X apps run on Xwayland, if needed. Reassigning to GNOME component.
Comment 13 Felix Zhang 2017-07-14 10:22:45 UTC
Looks like a duplicate of bug 955101.
Comment 14 Steffen Winterfeldt 2017-07-14 11:13:40 UTC
*** Bug 1046317 has been marked as a duplicate of this bug. ***
Comment 16 Dominique Leuenberger 2017-09-18 12:55:55 UTC
(In reply to Felix Zhang from comment #13)
> Looks like a duplicate of bug 955101.

This is indeed the same issue - wayland per default does not allow 'foreign connections' of users (root is not the user owning the wayland screen output)

a workaround is posted in this bug - a more permanent solution is being worked on

*** This bug has been marked as a duplicate of bug 955101 ***