Bug 19498 - mcc doesn't start on Wayland ("No protocol specified")
Summary: mcc doesn't start on Wayland ("No protocol specified")
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: release_blocker major
Target Milestone: Mageia 6
Assignee: Martin Whitaker
QA Contact:
URL:
Whiteboard:
Keywords:
: 19345 19629 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-10-01 08:55 CEST by Claire Revillet
Modified: 2017-03-06 19:59 CET (History)
13 users (show)

See Also:
Source RPM: mcc, wayland
CVE:
Status comment: Also affects draklive-install in GNOME LiveDVD so quite critical. Upstream wayland design which behaviour is not going to change. We should either ensure that the "default" GNOME in Mageia is on X11, or find another workaround.


Attachments
fix checking for Wayland (mga#19498) (787 bytes, patch)
2016-10-09 16:57 CEST, Thierry Vignaud
Details | Diff
xdg autostart file to enable GUI applications to be run by root (252 bytes, text/plain)
2016-12-16 18:17 CET, Martin Whitaker
Details

Description Claire Revillet 2016-10-01 08:55:49 CEST
Description of problem:
Selecting MCC in the menu, it ask for administrator password and nothing happend once psswd given. (user is informed if the password is wrong, so that's not the problem)

If launched in the terminal :

$ mcc
Ignore the following Glib::Object::Introspection & Gtk3 warnings
No protocol specified
Cannot be run in console mode.


Version-Release number of selected component (if applicable):
drakconf-13.7-3.mga6
On a fresh mga6sta1 install, only gvim, firefox and thunderbird had been installed before updating the system to last version of every packages.
Gnome DE used.
David Walser 2016-10-01 17:01:31 CEST

Assignee: bugsquad => mageiatools

Claire Revillet 2016-10-08 14:14:32 CEST

Priority: Normal => release_blocker

Comment 1 Rémi Verschelde 2016-10-08 14:15:03 CEST
Can't reproduce on up-to-date Cauldron with Plasma 5 as DE.

I think we've had such issues in the past when polkit is not properly configured or something.
Comment 2 Thierry Vignaud 2016-10-08 16:49:13 CEST
Cannot be release critical as it works for most users.
As you run as user and not root, does it works better if you run "su -" first?

Keywords: (none) => NEEDINFO
Priority: release_blocker => Normal
CC: (none) => mageia, thierry.vignaud
Summary: mcc doesn't start => mcc doesn't start ("No protocol specified")
Source RPM: drakconf => drakconf, polkit?
Severity: major => normal

Comment 3 Thierry Vignaud 2016-10-08 16:50:22 CEST
Also if it never asked for a password, that's definitively a polkit agent issue.
What does report "rpm -qa '*polkit*'|sort" ?
Comment 4 Claire Revillet 2016-10-09 11:48:55 CEST
(In reply to Thierry Vignaud from comment #3)
> Also if it never asked for a password, that's definitively a polkit agent
> issue.

It does ask for the password but nothing happens after (as explained in the original description).
If launched as root in a terminal, it works but it's not the graphical software.

If the problem is present for every user with fresh gnome install, it is a release blocker. We can't expect all gnome users to either know how to use CLI nor to live with minimal install and no bugfix!

If the problem is not present for users with older installations, it may come from the installation media.

Priority: Normal => release_blocker
Severity: normal => major

Comment 5 James Kerr 2016-10-09 14:29:24 CEST
I confirm this bug (on a "pure" gnome3 fully up to date, but installed some months ago) exactly as reported in comment#4. Similar behaviour also occurs when attempting to launch any of the drakxtools in a terminal, or when selecting "Install & Remove Software" from the menu.

The ncurses version is launched, if one is available, instead of the graphical version, otherwise nothing is launched.

I don't know when this bug began, as I don't use the drakxtools in cauldron very often. I am fairly certain that it did not exist when this system was first installed on August 1st.

CC: (none) => jim

Comment 6 James Kerr 2016-10-09 14:39:44 CEST
The bug only occurs if I log in using the default "Gnome" option in the GDM menu, which I think uses Wayland. If I select "Gnome on xorg", mcc and the drakxtools function normally in all respects.
Comment 7 James Kerr 2016-10-09 14:45:45 CEST
mcc and the drakxtools also function normally in a Gnome classic session.
Comment 8 Thierry Vignaud 2016-10-09 16:42:46 CEST
Ok, we need to adjust check_for_xserver() for Wayland too:
http://gitweb.mageia.org/software/drakx/tree/perl-install/common.pm#n599

Summary: mcc doesn't start ("No protocol specified") => mcc doesn't start on Wayland ("No protocol specified")

Comment 9 Thierry Vignaud 2016-10-09 16:52:15 CEST
It looks like Gtk3::init_check() is a good candidate those days.
It wasn't binded for a while
Thierry Vignaud 2016-10-09 16:52:29 CEST

Source RPM: drakconf, polkit? => drakxtools

Comment 10 Thierry Vignaud 2016-10-09 16:57:17 CEST
Created attachment 8510 [details]
fix checking for Wayland (mga#19498)

You can try this patch by running the following commands as root:
cd /usr/lib/libDrakX
patch -p1 < /where/it/was/downloaded/0001-fix-checking-for-Wayland-mga-19498.patch
Thierry Vignaud 2016-10-09 16:59:36 CEST

Keywords: (none) => PATCH
Target Milestone: --- => Mageia 6

Comment 11 James Kerr 2016-10-09 21:40:18 CEST
# cd /usr/lib/libDrakX
# patch -p1 < /home/jim/Downloads/0001-fix-checking-for-Wayland-mga-19498.patch
can't find file to patch at input line 14
Perhaps you used the wrong -p or --strip option?

I know nothing about perl but changed the lines: 

--- a/perl-install/common.pm
+++ b/perl-install/common.pm

in the patch file to:

--- a/common.pm
+++ b/common.pm

and the patch seems to have been applied:

# patch -p1 < /home/jim/Documents/0001-fix-checking-for-Wayland-mga-19498.patch
patching file common.pm

But the bug is still present.
Marja Van Waes 2016-10-20 17:51:30 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19629

Comment 12 Nicolas Lécureuil 2016-10-23 10:39:32 CEST
thierry, any idea on this bug ?

CC: (none) => mageia

Comment 13 Hartmut Schulze 2016-10-23 15:08:30 CEST
(In reply to Nicolas Lécureuil from comment #12)
> thierry, any idea on this bug ?

Ahem: its GDM 

solved in Arch -->

 Summary:   Under Wayland apps run via su or sudo are not authorised to
>            connect to the X11 display server
> Component: gdm

CC: (none) => h.hartmut_schulze

Nicolas Lécureuil 2016-10-23 15:36:03 CEST

Assignee: mageiatools => gnome

Comment 14 Thierry Vignaud 2016-10-23 15:47:01 CEST
Any URL about that bug in archlinux?
Thierry Vignaud 2016-10-23 15:52:38 CEST

See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=1274451

Comment 15 Thierry Vignaud 2016-10-23 15:53:11 CEST
*** Bug 19629 has been marked as a duplicate of this bug. ***

CC: (none) => win10

Thierry Vignaud 2016-10-23 15:53:21 CEST

See Also: https://bugs.mageia.org/show_bug.cgi?id=19629 => (none)

Comment 16 Daniel Kjellin 2016-10-29 11:24:40 CEST
I'm a GNOME only user and recently installed Mageia 6 (Cauldron), and I have the same problem. I can not log in using "Gnome on Xorg", and when trying to start mcc it gives the error listed here. After playing around with it for a bit, I found two interesting links:
http://gparted-forum.surf4.info/viewtopic.php?id=17446
which gave the workaround to run 
'xhost +local:' which I tried and confirm it works.
I also found the following bug report over on redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=1274451
which seems to indicate it is due to running sudo, not sure if it is relevant, but the "xhost +local:" trick was good as it unblocks me and I can now use mcc, either from console or started via gnome-shell.

CC: (none) => mandriva

Samuel Verschelde 2016-11-08 13:05:06 CET

Status comment: (none) => Upstream wayland bug, present in redhat also. Will be hard to fix, probably will get an errata entry instead.
Source RPM: drakxtools => wayland

Samuel Verschelde 2016-11-08 13:05:13 CET

Status comment: Upstream wayland bug, present in redhat also. Will be hard to fix, probably will get an errata entry instead. => Upstream wayland bug, present in redhat also. Will be hard to fix in time, probably will get an errata entry instead.

Comment 17 Hartmut Schulze 2016-11-09 10:36:25 CET
(In reply to Thierry Vignaud from comment #14)
> Any URL about that bug in archlinux?

sorry little late ;-))

https://wiki.archlinux.org/index.php/Running_X_apps_as_root

and: as told earlier:
Under Wayland apps run via su or sudo are not authorised to
connect to the X11 display server
Comment 18 Hartmut Schulze 2016-11-10 07:04:50 CET
(In reply to Daniel Kjellin from comment #16)
> I'm a GNOME only user and recently installed Mageia 6 (Cauldron), and I have
> the same problem. I can not log in using "Gnome on Xorg", and when trying to
> start mcc it gives the error listed here. After playing around with it for a
> bit, I found two interesting links:
> http://gparted-forum.surf4.info/viewtopic.php?id=17446
> which gave the workaround to run 
> 'xhost +local:' which I tried and confirm it works.
> I also found the following bug report over on redhat:
> https://bugzilla.redhat.com/show_bug.cgi?id=1274451
> which seems to indicate it is due to running sudo, not sure if it is
> relevant, but the "xhost +local:" trick was good as it unblocks me and I can
> now use mcc, either from console or started via gnome-shell.

Please consider:

https://wiki.archlinux.org/index.php/Xhost

and

https://wiki.archlinux.org/index.php/Running_X_apps_as_root

no risc - no fun???????????????????????
Comment 19 Samuel Verschelde 2016-11-10 10:21:53 CET
(In reply to Hartmut Schulze from comment #18)
> Please consider:
> 
> https://wiki.archlinux.org/index.php/Xhost
> 
> and
> 
> https://wiki.archlinux.org/index.php/Running_X_apps_as_root
> 
> no risc - no fun?

That xhost trick is just that, a trick. It's not the proper fix. The proper fix is to be done in wayland, from what I understood from the redhat bug report.

Keywords: NEEDINFO, PATCH => (none)

Comment 20 Rémi Verschelde 2016-11-23 22:14:56 CET
As discussed on IRC, until this bug is fixed, we should probably ensure that the default GNOME flavour on Mageia uses X11, as we did not do an extensive integration of Wayland in Mageia 6 (contrarily to e.g. Fedora).

@ GNOME maintainers: Feel free to disagree :)

At any rate, to be added to the errata if not fixed in time for the release.

Keywords: (none) => FOR_ERRATA6
Status comment: Upstream wayland bug, present in redhat also. Will be hard to fix in time, probably will get an errata entry instead. => Upstream wayland bug, present in redhat also. We should likely ensure that the "default" GNOME in Mageia is on X11

Comment 21 Pascal Terjan 2016-11-23 23:04:50 CET
In general we probably should probably rewrite most tools to not have the UI running as root but I doubt this will happen anytime soon and certainly not before Mageia 6...

Looking at the many duplicates on the RH bug, the problem also exists with gparted or anaconda live. It was a blocker for Fedora 24, then was removed from blocker as they decided to not default to wayland, then it seems it was not fixed but was not added to blockers for Fedora 25...

Allowing all local connections with xhost in wayland doesn't sound right but it seems x credentials are not currently passed according to that redhat bug so we can't use user's credential for root :(

I agree not defaulting to wayland until we have tested it properly and at least identified all such major problems sounds best.

CC: (none) => pterjan

Comment 22 Martin Whitaker 2016-12-10 13:42:20 CET
This also stops draklive-install being run from the desktop on the GNOME Live DVDs. I'm going to switch the default to Xorg on the sta2 ISOs.

CC: (none) => mageia

Comment 23 Martin Whitaker 2016-12-11 21:32:49 CET
I've discovered that the EnableWayland option in /etc/X11/gdm/custom.conf only applies to autologin and users without passwords. For users with passwords, the default remains to use Wayland until they choose otherwise.

For the xhost trick, a little experimentation shows that

  xhost +SI:localuser:root

is a bit more secure than xhost +local:, and allows MCC to run.
Comment 24 Mika Laitio 2016-12-15 16:19:14 CET
Having same problem with gnome/wayland. If I use the xhost permission change trick

    xhost +SI:localuser:root

and launch the drakconf from terminal, I can see the ncurses non-graphical version of mcc. Launch of graphical one from the menu still does not work.

I feel that this is critical because 
mcc is often needed to select the wlan access point.
(Even at home the automatic selection of network ap does not always work and you need to re-select it with the mcc. With mga3,4 and 5, I have used to use networkmanager instead, but for some reason that fails on gnome 6)

CC: (none) => lamikr

Comment 25 Olav Vitters 2016-12-15 22:53:44 CET
This is per the design decision. No point in assigning this to GNOME maintainers. The linked Red Hat bug is clearly marked as WONTFIX. Resetting assignee.

Status comment: Upstream wayland bug, present in redhat also. We should likely ensure that the "default" GNOME in Mageia is on X11 => Upstream wayland design which behaviour is not going to change. We should likely ensure that the "default" GNOME in Mageia is on X11
CC: (none) => olav
Assignee: gnome => bugsquad
Source RPM: wayland => mcc, wayland

Comment 26 Rémi Verschelde 2016-12-16 07:35:17 CET
As far as I know it's the job of GNOME maintainers to workaround this upstream design decision so that the MCC is not broken, as per:

> We should likely ensure that the "default" GNOME in Mageia is on X11

This requires fixing the stuff GNOME serves to the DMs.

Assignee: bugsquad => gnome

Comment 27 Martin Whitaker 2016-12-16 18:17:44 CET
Created attachment 8792 [details]
xdg autostart file to enable GUI applications to be run by root

I know of a couple of cases (from the Live DVD testing) where GNOME on Wayland has worked but GNOME on Xorg has not, so disabling Wayland may not be the best way forward.

Placing the attached file in /etc/xdg/autostart fixes the problem on the Live DVDs and results in

[live@linux ~]$ xhost
access control enabled, only authorized clients can connect
SI:localuser:root
SI:localuser:live

This compares to the default under Xorg of

[live@linux ~]$ xhost
access control enabled, only authorized clients can connect
INET:localhost
INET6:localhost
SI:localuser:live

(I haven't found a way to disable the extra authorisation being added when running GNOME on Xorg, but it doesn't appear to hurt).
Comment 28 Olav Vitters 2016-12-23 01:32:18 CET
(In reply to Rémi Verschelde from comment #26)
> As far as I know it's the job of GNOME maintainers to workaround this
> upstream design decision so that the MCC is not broken, as per:

That's per what you decided.

Various options are possible. Before you decided what I should spend my time on, it stated it would be put in the errata. You changed it to this bit. There's a very long bugreport which discusses various options on why this happened. There's various other things which could be done.

Not sure if anyone noticed, but I've been not contributing for quite a while. My bot auto upgrades packages; that's an automated task.

In yet another bugreport I tell the same thing: I'm not going to be bothered. And AFAIK talking about GNOME maintainers is like talking about me while I'm in the room while pretending you cannot hear me.

> @ GNOME maintainers: Feel free to disagree :)

Disagree and then do it!


Martin apparently has the right knowledge. Please inform him to to stop trying to fix this as AFAIK he's not one of the GNOME maintainers.
Comment 29 Samuel Verschelde 2017-01-09 15:53:53 CET
(In reply to Olav Vitters from comment #28)
> (In reply to Rémi Verschelde from comment #26)
> > As far as I know it's the job of GNOME maintainers to workaround this
> > upstream design decision so that the MCC is not broken, as per:
> 
> That's per what you decided.
> 
> Various options are possible. Before you decided what I should spend my time
> on, it stated it would be put in the errata. You changed it to this bit.
> There's a very long bugreport which discusses various options on why this
> happened. There's various other things which could be done.

Wow wow and wow. First, it has been decided not by Rémi but collectively during a packagers meeting so you can't just dismiss that as a difference of opinion between you and Rémi. We chose a solution, maybe not the best one, but the one that the people actually trying to release the distro felt they could manage to implement. But if "there's various other things which could be done" and you're ready to do it or at least tell us what to do, please do. So, what should we do to make MCC able to start from GNOME in Mageia 6?

> Not sure if anyone noticed, but I've been not contributing for quite a
> while. My bot auto upgrades packages; that's an automated task.

I did notice. Actually as a bugsquad team co-leader, I know how hard it is for us to deal with GNOME bugs since the main GNOME maintainer has made it clear in the past he's not interested in fixing bugs. But then why be angry at those who try to fix them in your stead?

> In yet another bugreport I tell the same thing: I'm not going to be
> bothered. And AFAIK talking about GNOME maintainers is like talking about me
> while I'm in the room while pretending you cannot hear me.

Pascal Terjan is also listed as a member of that maintainer group in https://wiki.mageia.org/en/Maintainer_groups#Maintainers_database_management 

And he agreed that we default to X11 until wayland has been properly tested.

> > @ GNOME maintainers: Feel free to disagree :)
> 
> Disagree and then do it!
> 
> Martin apparently has the right knowledge. Please inform him to to stop
> trying to fix this as AFAIK he's not one of the GNOME maintainers.

I don't understand. We should do it but Martin shouldn't because he's not one of the GNOME maintainers? Being maintainer does not mean nobody can touch your packages when you're not fixing bugs. You haven't commented on this bug report until you just jumped in to reassign it to bugsquad (which means bugsquad has to triage it again).

I just hope I'm not understanding you correctly. You say that you are not going to help fixing the bug but you won't let anyone else do the work? So what should we do to be able to start MCC and draklive install from GNOME? If we can't fix it, then there will be no point in providing GNOME Live ISOs at all, in my opinion.
Comment 30 Olav Vitters 2017-01-09 20:38:39 CET
(In reply to Samuel Verschelde from comment #29)
> Wow wow and wow. First, it has been decided not by Rémi but collectively
> during a packagers meeting so you can't just dismiss that as a difference of

This bug is marked as release blocker. It's in the NEW state. If something is decided, then it should be feasible. Now some discussion was held outside of the bugreport and it's my fault for 1) expecting relevant information of a bugreport to be part of a bugreport 2) to be able to discuss a bugreport on a bugreport 3) to be able to clearly indicate lack of knowledge and a need of assistance.

IMO MCC should be fixed.

> > Not sure if anyone noticed, but I've been not contributing for quite a
> > while. My bot auto upgrades packages; that's an automated task.
> 
> I did notice. Actually as a bugsquad team co-leader, I know how hard it is
> for us to deal with GNOME bugs since the main GNOME maintainer has made it
> clear in the past he's not interested in fixing bugs. But then why be angry
> at those who try to fix them in your stead?

Do you call me the main person without actually using my name?

If so: nothing has been done on this bug. If it's not clear: I tried to say I have no clue, plus I think other solutions are possible. All of that feedback was unacceptable. 

Let me quote again the feedback received:

(Rémi Verschelde from comment #26)
> As far as I know it's the job of GNOME maintainers to workaround this
> upstream design decision so that the MCC is not broken[..]

And I did NOT say I'm not interested in fixing bugs. I'm stating that the expectations are ridiculous. If there's a packaging problem I'll fix it. I'm not a developer. I don't know C.

Now again:
> I did notice. Actually as a bugsquad team co-leader, I know how hard it is
> for us to deal with GNOME bugs since the main GNOME maintainer has made it
> clear in the past he's not interested in fixing bugs. But then why be angry

I highly resent this. Because I do a lot of effort, it's troublesome I don't do more. That's what your saying. Well thanks. Good to know it's about what I do NOT do and what I do NOT know how to do. Purely about me of course, because some others do way less so let's not mention them.

Why couldn't the lack of hands to fix GNOME bugs be a problem? Why does it have to be about me? I propose (being 100% sarcastic) that we take one of these other GNOME maintainers and complain about their efforts.

I clearly indicated my limitations often in dev@, etc. In this bug I reassigned because 1) I lacked knowledge 2) it clearly indicates nothing was expected to happen while being assigned to gnome@.

Further: IMO MCC should be fixed. This bug is about a "quick" workaround. I think MCC should be changed. But there's no time for a proper solution I guess.

That was not acceptable, per:
> As far as I know it's the job of GNOME maintainers to workaround this
> upstream design decision so that the MCC is not broken[..]

> > In yet another bugreport I tell the same thing: I'm not going to be
> > bothered. And AFAIK talking about GNOME maintainers is like talking about me
> > while I'm in the room while pretending you cannot hear me.
> 
> Pascal Terjan is also listed as a member of that maintainer group in
> https://wiki.mageia.org/en/Maintainer_groups#Maintainers_database_management 
> 
> And he agreed that we default to X11 until wayland has been properly tested.

The bug is release blocker and in the NEW state. I tried to reassign, it was assigned back and a clear explanation/instruction that "it's the job of GNOME maintainers". Obviously nothing happened (the reason I tried to reassign).

IMO MCC should be fixed. That's what should be done. It should use PolicyKit.

> > > @ GNOME maintainers: Feel free to disagree :)
> > 
> > Disagree and then do it!
> > 
> > Martin apparently has the right knowledge. Please inform him to to stop
> > trying to fix this as AFAIK he's not one of the GNOME maintainers.
> 
> I don't understand. We should do it but Martin shouldn't because he's not
> one of the GNOME maintainers? Being maintainer does not mean nobody can
> touch your packages when you're not fixing bugs. You haven't commented on
> this bug report until you just jumped in to reassign it to bugsquad (which
> means bugsquad has to triage it again).

You skipped what I quoted:

(In reply to Rémi Verschelde from comment #26)
> As far as I know it's the job of GNOME maintainers to workaround this
> upstream design decision so that the MCC is not broken[..]

Per packagers meeting as clarified by Rémi "it's the job of GNOME maintainers". This was clearly stated. Why come to me why nobody else should work on it? I tried to reassign it! Reassignment is not acceptable, "it's the job of GNOME maintainers".

IMO MCC should be fixed. That's what should be done. It should use PolicyKit.

Now the "you haven't commented on this bug": Why should I? Why not change MCC to e.g. use policykit?

> I just hope I'm not understanding you correctly. You say that you are not
> going to help fixing the bug but you won't let anyone else do the work? So
> what should we do to be able to start MCC and draklive install from GNOME?
> If we can't fix it, then there will be no point in providing GNOME Live ISOs
> at all, in my opinion.

My opinion is that this should be assigned to someone capable of fixing the bug. What Martin proposed seems like an awesome workaround. Unfortunately he's not allowed to work on it. But again, I didn't decide this. I tried to reassign back to default (which is bugsquad) and the response was super clear: it's the job of GNOME maintainers per packagers meeting decision.

Now obviously thanks to Martin I know how to workaround the MCC problem. It's obviously _only_ me who must fix this bug as I'm a main GNOME maintainer as per packagers meeting assignment decision. But IMO MCC should be fixed to use PolicyKit. I'm still building up the knowledge, plus enthusiasm for this directive from the packagers meeting. It takes a little bit of time.
Comment 31 Samuel Verschelde 2017-01-10 00:35:59 CET
Thanks for your reply, it clarifies some points that I and Rémi had missed.

(In reply to Olav Vitters from comment #30)
> (In reply to Samuel Verschelde from comment #29)
> > Wow wow and wow. First, it has been decided not by Rémi but collectively
> > during a packagers meeting so you can't just dismiss that as a difference of
> 
> This bug is marked as release blocker. It's in the NEW state. If something
> is decided, then it should be feasible. Now some discussion was held outside
> of the bugreport and it's my fault for 1) expecting relevant information of
> a bugreport to be part of a bugreport 2) to be able to discuss a bugreport
> on a bugreport 3) to be able to clearly indicate lack of knowledge and a
> need of assistance.
> 
> IMO MCC should be fixed.

On this we all agreed, but it seemed easier to switch back to X11 for Mageia 6 given the delays we had. I don't think anyone is currently working on porting Mageia tools so that they don't require root anymore.

> Let me quote again the feedback received:
> 
> (Rémi Verschelde from comment #26)
> > As far as I know it's the job of GNOME maintainers to workaround this
> > upstream design decision so that the MCC is not broken[..]
> 
> And I did NOT say I'm not interested in fixing bugs.

I thought I read such statement in the past on your blog, at the time of Mageia 5 developement I think, where you said you were interested in making things evolve but making things stable wasn't what interests you.

> I'm stating that the
> expectations are ridiculous. If there's a packaging problem I'll fix it. I'm
> not a developer. I don't know C.

The proposed solution was not to code anything but rather to make Mageia 6's GNOME to use X11 instead of wayland by default, add a note into errata for those who'd still use wayland, and find a better fix for Mageia 7.

We should have added a proper comment about that rather than just updating the status comment, so that everybody would have had the same level of information and that would have avoided misunderstandings. You're right to expect that all information about a bug is present in the bug report.

> 
> Now again:
> > I did notice. Actually as a bugsquad team co-leader, I know how hard it is
> > for us to deal with GNOME bugs since the main GNOME maintainer has made it
> > clear in the past he's not interested in fixing bugs. But then why be angry
> 
> I highly resent this. Because I do a lot of effort, it's troublesome I don't
> do more. That's what your saying. Well thanks. Good to know it's about what
> I do NOT do and what I do NOT know how to do. Purely about me of course,
> because some others do way less so let's not mention them.
> 
> Why couldn't the lack of hands to fix GNOME bugs be a problem? Why does it
> have to be about me? I propose (being 100% sarcastic) that we take one of
> these other GNOME maintainers and complain about their efforts.

Sorry about that. It is obvious that the lack of hands is the main issue. No one forces you to maintain GNOME at all, we all work on a benevolent basis and I'm aware of that. 
 
> I clearly indicated my limitations often in dev@, etc. In this bug I
> reassigned because 1) I lacked knowledge 2) it clearly indicates nothing was
> expected to happen while being assigned to gnome@.
> 
> Further: IMO MCC should be fixed. This bug is about a "quick" workaround. I
> think MCC should be changed. But there's no time for a proper solution I
> guess.

That's the main issue. We need to be able to start draklive-install and MCC and we know the proper solution requires a lot of work, hence the pursuit of a workaround for Mageia 6. And GNOME upstream is not making it easy for us for sure but that's not something we have power on. 


> 
> That was not acceptable, per:
> > As far as I know it's the job of GNOME maintainers to workaround this
> > upstream design decision so that the MCC is not broken[..]
> 
> > > In yet another bugreport I tell the same thing: I'm not going to be
> > > bothered. And AFAIK talking about GNOME maintainers is like talking about me
> > > while I'm in the room while pretending you cannot hear me.
> > 
> > Pascal Terjan is also listed as a member of that maintainer group in
> > https://wiki.mageia.org/en/Maintainer_groups#Maintainers_database_management 
> > 
> > And he agreed that we default to X11 until wayland has been properly tested.
> 
> The bug is release blocker and in the NEW state. I tried to reassign, it was
> assigned back and a clear explanation/instruction that "it's the job of
> GNOME maintainers". Obviously nothing happened (the reason I tried to
> reassign).

Well Rémi just said that it's GNOME's maintainer who can default GNOME to using X11 instead of wayland. But given the lack of a comment explaining that it was the chosen workaround, I understand that it was not clear.
It looks like that ping pong with the Assignee field is mainly caused by a misunderstanding about the expectations around this bug report. 

> My opinion is that this should be assigned to someone capable of fixing the
> bug. What Martin proposed seems like an awesome workaround. Unfortunately
> he's not allowed to work on it.

I don't think that he's not allowed to work on it. He has tried to use X11 and apparently it raises other problems so in the end maybe his proposal of using xhosts, even if I don't like it, is the best we'll have for Mageia 6.

Let's assign the bug report to him if he agrees (Martin, just assign back if you don't).

Status comment: Upstream wayland design which behaviour is not going to change. We should likely ensure that the "default" GNOME in Mageia is on X11 => Also affects draklive-install in GNOME LiveDVD so quite critical. Upstream wayland design which behaviour is not going to change. We should either ensure that the "default" GNOME in Mageia is on X11, or find another workaround.
Assignee: gnome => mageia

Comment 32 Rémi Verschelde 2017-01-10 10:28:20 CET
(In reply to Olav Vitters from comment #30)
> (In reply to Rémi Verschelde from comment #26)
> > As far as I know it's the job of GNOME maintainers to workaround this
> > upstream design decision so that the MCC is not broken[..]
> 
> Per packagers meeting as clarified by Rémi "it's the job of GNOME
> maintainers". This was clearly stated. Why come to me why nobody else should
> work on it? I tried to reassign it! Reassignment is not acceptable, "it's
> the job of GNOME maintainers".

I'd like to clarify things about this "GNOME maintainers" group which seems to cause so much grief. This so-called GNOME maintainers group is not a euphemism to avoid mentioning your name, Olav. It's precisely a proposed (and long-discussed on the dev@ ML during several weeks) solution to help address the lack of manpower we have in specific areas. Relying on a single person for a whole stack such as GNOME + GTK+ is too much for anyone to handle, and nobody in the Mageia community wants to impose this on you. The lack of proper alternative over the past 5 years has led to almost all bugs mentioning GNOME or GTK+3 being assigned to you, and to you making it clear several times that you don't have the appropriate knowledge to address them all, which is totally fine.

The name "maintainers" might mislead you if you think it as in a Debian context, where nobody would be ever allowed to *touch* the bug reports assigned to these "GNOME maintainers". As we designed it and understand it in Mageia, this group is much looser than that, and is more a kind of SIG for all packagers and developers interested in GNOME and GTK+3 and ready to help fixing some of the bugs affecting the stack. As such, it is first and foremost a mailing list, gnome@m.o, which currently has 6 members.

Therefore, assigning a bug report to gnome@m.o does not mean "Olav must fix it". It means that it's a bug affecting the GNOME environment, and the bugsquad expects that the GNOME maintainers (i.e. all packagers interested in GNOME) should come up with a solution OR discuss with other packagers a solution which would not be of their responsibility (e.g. fixing the MCC and DrakX so that it works with polkit) and then reassign to the corresponding group (here mageiatools@, the "Mageia Tools maintainers". If Martin has a proposed solution and can work on it, he is very welcome to do it even if the bug report is not assigned to himself. He can change the assignment to himself if he believes that he has the right solution. The gnome@ assignment only means "Packagers with an interest in GNOME, please look at it, as - with the current level of understanding - this bug report affects your DE, and this one only." If *you* consider that you can't fix it, that's totally fine, but that does not mean that the assignee should be reset, until we can actually have enough insights from people who know how Wayland works to find the proper solution or workaround given the limited time schedule.

> IMO MCC should be fixed. That's what should be done. It should use PolicyKit.

That's a comment we would have welcomed months ago, which would have prevented us from trying to find workarounds in the GNOME setup that you find are not acceptable. This kind of information is *precisely* why we assign bug reports to gnome@ in the first place, so that people like you can read it, think about it a bit and *share* their understanding. If you don't share anything, we can't guess it. Just as you are not a C programmer guru who can revert upstream design decisions, we are not know-it-alls who follow the MLs of all upstream projects so that we can triage bugs to the perfection and do their debugging all the way with 0 input from packagers who actually know what we're looking at.

During a packagers meeting to which all were invited, it was decided collectively that the solution for this bug would be to default to GNOME on X11 instead of GNOME on Wayland. It was approved by Pascal, who is part of the GNOME maintainers group, and documented in this bug report in comment 20, where I asked for feedback from the "GNOME maintainers". Up to that comment you had never commented on this bug report yourself, and you only did in comment 25 to just reassign to bugsquad by saying "This is per the design decision."

> Now the "you haven't commented on this bug": Why should I? Why not change
> MCC to e.g. use policykit?

Precisely because, as one of the GNOME maintainers, and arguably our packager who knows GNOME upstream decisions the best, it's your role to ensure that such upstream decisions are properly understood downstream. If we get 0 communication with upstream, when they design something that breaks our tools, it's natural that we'll consider that upstream is just making bogus decisions that we have to workaround. If we have a packager such as you, who knows a bit about upstream decisions, and can tell us that they consider our usage of root in the drakxtools bogus, then it already brings the conversation to a higher level, and we can assess the solutions we have at our disposal:
- Fix the drakxtools so that they work with polkit for Mageia 6 (then we need to reassign this bug to mageiatools@, or create a new bug with a summarized status in the OP for clarity)
- Fix the drakxtools so that they work with polkit for Mageia 7, because it's too hard to do it fast for Mageia 6, and thus:
  * Workaround the issue by defaulting GNOME to run on X11, as our distro is not ready for Wayland yet (that was the proposed solution, and is of the responsibility of the GNOME maintainers who can do this change at the DM level), or
  * Find another workaround that allows the current drakxtools to work on Wayland, which is the solution Martin has come up with and is IMO the best one we have at this time (then the bug report can be assigned to Martin - ideally by himself to signify that he will be actively working on it, so he might have been waiting for some *constructive* feedback from people familiar with GNOME on Wayland as a "go ahead, that's a good idea").

Again, it all boils down to proper communication, not to having a PhD in C development. We all work with our limited knowledge and limited time, but if we can't communicate and have to fight each other to go anywhere near to resolving a bug, this is not sustainable.
Comment 33 Colin Guthrie 2017-01-10 11:49:37 CET
Just to jump in here (I've not read the full bug report, nor followed very much of late as you all know, but hopefully my opinion is still mildly useful even if I can't do much else other than comment!). 

(In reply to Olav Vitters from comment #30)
> IMO MCC should be fixed. That's what should be done. It should use PolicyKit.

Sadly this is something that is unlikely to happen, especially not in the timeframes. As you maybe know it's not just a matter of "using PolicyKit" (it already does!), it's a matter of fully redesigning MCC around a client-server model with granular privileges on individual operations, each protected with a suitable policy and likely based around dbus. It's the correct architecture and one I've been pushing for for several years (since before I first migrated MCC to polkit from consolehelper which was a big enough job with various knock on bugs by itself), but it takes time and effort and motivation. It's not something that's just going to magically occur, certainly not in the timeframes before this release - it's a full-release cycle task for motivated individuals, not a last minute patch job.

So, frankly, although I would agree this is the technically correct solution, it's not the pragmatic one - for this release cycle at least. [For a bit of history, we had to do make similar pragmatic choices before - specifically with the Network Manager integration in GNOME verses our ancient scripts. I've not looked into this but hopefully this is now solved too and those scripts are dead, but that's another issue!]

So in my opinion, there are only a few options here that are practical:

1. Default to X11
2. Keep Wayland default (it's been working well for me, sans a few minor sloppy focus quibbles after alt-tab) but ensure X11 privileges allow root to connect (as per comment 27 - not considered the wider security implications but for now it's "probably" fine)
3. Don't bother shipping GNOME Live (where MCC is a vital part and used in the installer) and explain in the errata why MCC doesn't work and what changes you can make (switch to X11, allow root to run GUI applications).

The option to "fix" MCC is not practical unless you want to delay Mageia 6 release for six+ months AND manage to get people to work on it.

Personally, I'd vote for option 2.

Some slightly more left field options for the next cycle:

1. Look more into ManaTools. I've discussed the design problems of MCC (for privilege separation) with Angelo and Matteo when they were developing ManaTools and I believe they operate more sensibly. I've not followed updates for a long time however, so no idea what state they are in.

2. As GNOME has improved over the years there is less need for MCC tools. Most of the stuff a general user needs is built into GNOME anyway. So with the exception of installing the LIVE distro, perhaps more focus should be given to ensuring built in gnome tools "just work", e.g. user creation (seems to work fine) and software updates. I've not tried gnome software, but I'd hope that the DNF work would mean we could ditch any work on getting urpmi integration working and just use DNF backend for GNOME software. That said there is very little to differentiate Mageia over e.g. Fedora for a "pure" GNOME experience, but ultimately, I think this is more in line with the upstream GNOME vision anyway.

My â¬0.02. Hope it helps and that everyone is well! :)
Comment 34 Thierry Vignaud 2017-01-12 15:45:32 CET
What if you use the patch + "GDK_BACKEND=x11 mcc" ?
Comment 35 Thierry Vignaud 2017-01-12 16:34:48 CET
In my tests it works (tested on FC with several mga pkgs rebuild for FC), using:
GDK_BACKEND=x11 fakeroot perl -I lib/ ./control-center
Comment 36 Mageia Robot 2017-01-12 16:35:53 CET
commit 945cc249ee06ee087157fe56082028e1a1bd4fa6
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Thu Jan 12 16:35:00 2017 +0100

    force gtk+3 to use the x11 backend
    
    even on wayland (mga#19498)
    we rely on xwayland
    It's also needed in order to have working GtkSocket/GtkPlug
---
 Commit Link:
   http://gitweb.mageia.org/software/control-center/commit/?id=945cc249ee06ee087157fe56082028e1a1bd4fa6
Comment 37 Mageia Robot 2017-01-12 16:41:02 CET
commit 912abc9725196eded7554813e4d6adb91e66f169
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Thu Jan 12 16:38:15 2017 +0100

    rely on Gtk+ for checking for Xserver (mga#19498)
    
    MCC also needs a separate fix for forcing using the X11 GDK backend b/c
    GtkPlug/Socket do not work under Wayland, thus relying on xwayland
    
    XFdrake will probably fails the same way under wayland, but anyway it's
    there for configuring xserver...
    It should probably checks for wayland before proposing to test
---
 Commit Link:
   http://gitweb.mageia.org/software/drakx/commit/?id=912abc9725196eded7554813e4d6adb91e66f169
Comment 38 Thierry Vignaud 2017-01-12 16:42:20 CET
Fixed in git
It also "nicely" takes care of care of MCC vs gtkPlug/Socket vs Wayland... :-)

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 39 Nicolas Lécureuil 2017-01-12 17:03:57 CET
thank you :)   you are the best :)
William Kenney 2017-01-12 21:12:54 CET

CC: (none) => wilcal.int

Comment 40 Martin Whitaker 2017-01-13 23:15:19 CET
Sorry, this doesn't work. fakeroot lets you start the GUI, but because you aren't really running as root, none of the actions that require root privileges can be performed. If not run via fakeroot, the GUI won't start, with the same

  No protocol specified
  Cannot be run in console mode.

message as before.

(tested locally in a fresh GNOME Live DVD build)

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 41 Thierry Vignaud 2017-01-14 09:21:54 CET
Did you do the xhost trick?
Comment 42 Martin Whitaker 2017-01-14 11:39:00 CET
(In reply to Thierry Vignaud from comment #41)
> Did you do the xhost trick?

Yes, and then it works. But because you set the bug to "fixed", I assumed you had found an alternative solution.

I'll go ahead and add my workaround to one of the GNOME packages unless you say otherwise.
Comment 43 Martin Whitaker 2017-01-14 18:23:25 CET
Should be fixed now.

@Olav, I added this to the gdm package, as that's what chooses to use Wayland, but if you think it would be more appropriate in another package, please do move it.

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED

Comment 44 Olav Vitters 2017-01-16 20:39:37 CET
(In reply to Martin Whitaker from comment #43)
> Should be fixed now.
> 
> @Olav, I added this to the gdm package, as that's what chooses to use
> Wayland, but if you think it would be more appropriate in another package,
> please do move it.

Thanks a lot!!!

Somehow "my" router again broke its port forwarding, so I missed out on everything over last few days.

Some interesting environment variables I noticed:
XDG_SESSION_TYPE=wayland
WAYLAND_DISPLAY=wayland-0

Somewhere there was a mention to limit this to just Wayland sessions. Either of those would do.


Other stuff (in no order plus I didn't read everything yet):
- I read some bugreport someone linked here that Xwayland should/could/isn't started with an xauth option (the secret code bit). Basically if that would be done this stuff wouldn't be needed. No clue where this is being started though.
- This caused problems for Fedora as well. I was assuming there'd be some more discussion elsewhere. Didn't see.
- I'm not expecting MCC to be fixed, though maybe should be a on a roadmap? I'd like to see what Fedora is planning.
- I love the GNOME maintainer alias/group, but think atm it cannot be relied upon yet. That's why reassignment. Assignee is responsible to fix the bug. Keeping the assignee means that progress is to be expected. Reassignment in such cases is entirely logical.
- I'll try and spam more; I thought that e.g. that PolicyKit was well known (plus I didn't see it as anything other than MCC thing; not for me to comment)
- It takes me ages before I actually fix some stable Mageia bug. I've committed to various in the past and it takes me months to do a simple packaging fix. Entire time I feel guilty because I promised I'd do something. I don't get why setting clear expectations should be controversial.
- I think I've set myself as a maintainer for almost no packages. The spirit of Mageia is that if you make a clear improvement, in doubt maybe ask a more experienced person. But please please please: just make changes! Especially in Cauldron. Having some ask "hey can I do this change that I fully understand, committed and fixed for this package that you're not a maintainer for but your bot did some commits for because it fixes a problem you indicated had no knowledge for".. that's maybe too a bit too polite :P
Comment 45 Olav Vitters 2017-01-17 20:13:09 CET
*** Bug 19345 has been marked as a duplicate of this bug. ***
Comment 46 Marja Van Waes 2017-03-06 19:59:21 CET
Some closed bugs do still contain some information that needs to go in the Errata, but I fail to see what that could be for this (fixed) bug, so removing the keyword.

Keywords: FOR_ERRATA6 => (none)
CC: (none) => marja11


Note You need to log in before you can comment on or make changes to this bug.