Dear Maintainer,

Suppose you installed GNOME as default DE and also with xrdp installed, when
trying to use another computer to visit it by remote access(RDP or VNC),then
GNOME crashes:
"Oh, no! Something has gone wrong."
In this case, it influences the using of RDP and VNC. They cannot use at all.
When trying to use MATE as default DE, it works as it should. Cinnamon also
crashes, but soft rendering works. So I think it's GNOME's soft rendering bug,
it doesn't comptable with remote access.

Control: severity -1 serious

Control: severity -1 serious

Control: affects -1 ldm

This also affects LDM (the display manager used in LTSP), which uses ssh
X11Forwarding or remote X11 protocols. Basically, LTSP installations
have been encouraged to avoid using GNOME3 for quite some time due to
these sorts of issues.


live well,
  vagrant

Dear maintainer:

Maybe this bug is saying the same issue to bug #686511. But in wheezy, GNOME flashback exists with default install (as GNOME classic), so although it fallback to classic, it's still usable. (By the way, I tried using xrdp in wheezy, it also doesn't work and fallback to classic so it's also an important bug) But for now GNOME flashback is not installed by default(replaced by the new GNOME classic), and although install GNOME flashback manually, this issue also exists in GNOME 3.16. If we can make it at least usable, it will be downgraded and not exist as RC bug. Certainly it could be better if it can be fully fixed. It's really a bug with long history.

Just some tips: CentOS 7 with GNOME 3.8 seems to have a working remote desktop, I tried it with xrdp. I don't know if this can help.

Best wishes,
Gaotx

(Just a repeat because it's probably hard to read. I'm new to Debian bug tracker. 
Sorry for that.)

Dear maintainer:

Maybe this bug is saying the same issue to bug #686511. But in wheezy, GNOME 
flashback exists with default install (as GNOME classic), 
so although it 
fallback to classic, it's still usable. (By the way, I tried using xrdp in wheezy, 
it also doesn't work and fallback to classic so it's also an important bug) 
But for now GNOME flashback is not installed by default (replaced by the new GNOME 
classic), and although install GNOME flashback manually, this issue also 
exists in GNOME 3.14. If we can make it at least usable, it will be downgraded and 
not exist as RC bug. Certainly it could be better if it can be fully fixed. It's really 
a bug with long history.

Just some tips: CentOS 7 with GNOME 3.8 seems to have a working remote 
desktop, I tried it with xrdp. I don't know if this can help.

Best wishes,
Gaotx

retitle 776746 gnome-session: "Oh no! Something has gone wrong" when Composite extension is absent from X server

Nothing is actually crashing, although the user-visible symptom is the same.

Steps to reproduce:

* install jessie with only the GNOME desktop (I used a virtual machine)
* apt-get install xrdp
* connect an RDP client to the machine (I used Vinagre)
* accept the default Module, "sesman-Xvnc"; enter a valid username
  and password, e.g. the one created by the installer

You get the "Oh no!" screen as described.

~/.xsession-errors indicates why:

    Xsession: X session started for  at Sun  8 Mar 16:27:54 GMT 2015
    X Error of failed request:  BadValue (integer parameter out of range for operation)
      Major opcode of failed request:  109 (X_ChangeHosts)
      Value in failed request:  0x5
      Serial number of failed request:  6
      Current serial number in output stream:  8
    localuser:smcv being added to access control list
    openConnection: connect: No such file or directory
    cannot connect to brltty at :0
    gnome-session-is-accelerated: No composite extension.
    gnome-session-check-accelerated: Helper exited with code 256
    gnome-session-is-accelerated: No composite extension.
    gnome-session-check-accelerated: Helper exited with code 256

    ** (process:2235): WARNING **: software acceleration check failed: Child process exited with code 1

GNOME Shell is a compositing window manager. It requires the Composite
extension, and cannot operate on a display that does not have it,
regardless of whether it is provided by software rendering or 3D hardware
or what. If Xvnc does not have that extension then GNOME Shell cannot work.

There are several bugs here. IMO none of them is really RC:

* gnome-session should put different text on the "oh no!" message
  if the problem is really "your X server is not sufficiently capable to
  run GNOME"

* xrdp should allow session-selection, so remote users can select
  a non-compositing environment like LXDE or XFCE even if GNOME is
  the default

* xrdp, or whatever Xserver it uses behind the scenes (Xvnc?), should
  support the Composite extension

mate's window manager is marco, which I think is a fork of GNOME 2's
Metacity. Metacity is *optionally* a compositing window manager, but
can also run as a traditional non-compositing window manager,
so the absence of the Composite extension is non-fatal

cinnamon's (default?) window manager is muffin, which I believe is a fork
of mutter, a compositing window manager which does not support
non-composited operation (GNOME Shell uses Mutter libraries for its
window-manager and compositing-manager functionality).

    S

Related ubuntu bug report
https://bugs.launchpad.net/debian/+source/gnome-session/+bug/1251281
Related Gnome bug report https://bugzilla.gnome.org/show_bug.cgi?id=731173

If this is considered as xrdp's bug, the 3rd option should be best way to
fully fix this issue. But if it's considered as GNOME's bug, probably it
should be patched to make GNOME 3 support non-compositing
environment and this may better then modifying xrdp because this is
a GNOME 3 ONLY issue and not xrdp's fault. Xrdp works well with other
desktop environments.

Gaotx

GNOME Shell, via its use of Mutter code for window management, requires
the Composite extension. This is not a feature that can be turned on or
off; Mutter's design relies on the ability to act as a compositing manager,
and it has no support for not doing so (just like Compiz and Unity,
and unlike traditional "stacking window managers" like Metacity).

The full GNOME environment as used by the GNOME and GNOME Classic
session types, in turn, requires GNOME Shell. If you want something
that superficially resembles GNOME but does not use GNOME Shell,
that's exactly GNOME Flashback, which is now packaged separately.

If your X server does not meet the requirements to run GNOME Shell,
then your only option is to use something that is not the full GNOME
environment, such as GNOME Flashback (which uses Metacity),
OpenBox's "GNOME/Openbox" session (which uses Openbox), or one of the
various GNOME forks like MATE.

I do not consider "requires modern X server features" to be a GNOME bug,
and neither do its upstream developers.

    S

But both CentOS 7 with GNOME 3.8, Fedora 20 with GNOME 3.10 and Fedora 21 
with GNOME 3.14 tell us that GNOME 3 itself can work well with xrdp without 
any issues and this is a Debian ONLY bug. You can try them as well. And maybe
you can find the difference of xrdp between Debian and those Red Hat based
OS and find how they overcome this issue. If you need any more information,
I would like to help.

Best wishes,
Gaotx

Fedora's xrdp appears to depend on tigervnc, which uses code from a modern
X server which presumably has the Composite extension. Unfortunately,
tigervnc is not yet available in Debian: <https://bugs.debian.org/650394>.

Debian's available VNC servers are:

* vnc4server, which uses code from XFree86 4.3.0 from 2003, itself based on
  X11R6.6 from 2001
* tightvncserver, which uses code from XFree86 3.3.2, based on X11R6.3
  from 1996

According to Wikipedia, the Composite extension dates from X11R6.8,
released in 2004; so it is not really surprising that neither of those
VNC servers support it, but it is also not really surprising that
the GNOME developers consider it to be an uncontroversial requirement
(after all, it's more than a decade old).

This is all very unfortunate, but I don't see any way it can change
for Debian 8, and I don't think it should be considered a release-critical
bug in GNOME. Perhaps (with your help?) tigervnc can be in Debian 9 and
we can have a standalone VNC server based on an Xserver less than a
decade old...

    S

severity 776746 normal
clone 776746 -2 -3 -4
retitle 776746 gnome-session: "Oh no! Something has gone wrong" when used under Xvnc
reassign -2 tightvncserver 1.3.9-6.5
retitle -2 tightvncserver: no support for Composite extension as required by GNOME 3, Compiz, etc.
reassign -3 vnc4server 4.1.1+X4.3.0-37.4
retitle -3 vnc4server: no support for Composite extension as required by GNOME 3, Compiz, etc.
severity -4 wishlist
retitle -4 gnome-session: please give clearer GUI message for missing Xserver features
block 776746 by -2 -3 650394
affects 776746 + xrdp

Niels in the release team doesn't think so either, so I'm downgrading
this, and cloning similarly non-RC bugs to the VNC implementations
as he suggested.

Regards,
    S

To all whom it may concern:

Nowadays Gnome on Debian uses Wayland instead of X. Even when ran/run
on X it required X11's Xcomposite extension for quite some time now.

On the other hand, Thightvnc is old software. It bases on Xfree86, an
outdated implementation of X. Thightvnc's X server doesn't comprise the
Xcomposite extension. Also, upstream does not maintain Thightvnc on
Linux any more.

Conclusion: Tightvncserver cannot serve a recent Gnome desktop.

Recommendation: Install the gnome-remote-desktop package and enable
screen sharing in your Gnome Settings.

Sven