(In reply to William Kenney from comment #0)
> Description of problem:
> 
> From the log in screen selecting Gnome Classic
> results in launching Kodi.

That sounds as if Kodi is launched, without a DE being launched :-/

Can you provide more details:

* Did you use a Live Gnome iso
** if so: in live mode or did you install?

* which arch?

Did you really mean to say that Gnome3 is launched instead of Gnome classic, and then Kodi is auto-started? 

If you did a classical installation: did you reuse an existing /home partition?

Keywords: (none) => 6dev1, NEEDINFO
CC: (none) => geiger.david68210, marja11, olav

I believe Kodi can be launched in "DE" mode, i.e. it doesn't start a DE but only Kodi in fullscreen (like what one would like to have on the TV for example).

Maybe Kodi somewhat messes with the DM entries to start the DE. Which DM are you using?

(In reply to Rémi Verschelde from comment #2)

> I believe Kodi can be launched in "DE" mode, i.e. it doesn't start a DE but
> only Kodi in fullscreen (like what one would like to have on the TV for
> example).
> 
> Maybe Kodi somewhat messes with the DM entries to start the DE. Which DM are
> you using?

This system has both Plasma and Gnome installed. In this case the last
launched was Plasma. I'll try several different launch sequences.

(In reply to Marja van Waes from comment #1)

> (In reply to William Kenney from comment #0)

> That sounds as if Kodi is launched, without a DE being launched :-/

Ya went directly to Kodi

> Can you provide more details:
> 
> * Did you use a Live Gnome iso
> ** if so: in live mode or did you install?

This was a 6dev1 install that has been successfully updating nicely.
Both Gnome and Plasma are installed.

> * which arch?

x86_64

> Did you really mean to say that Gnome3 is launched instead of Gnome classic,
> and then Kodi is auto-started? 

Select Gnome Classic from the log in screen and it goes directly to Kodi.
Of course Kodi with no mouse control:

https://bugs.mageia.org/show_bug.cgi?id=18197

Test platform:
Intel Core i7-2600K Sandy Bridge 3.4GHz
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo
GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB
RTL8111/8168B PCI Express 1Gbit Ethernet
DRAM 16GB (4 x 4GB)

Has anyone successfully launched a Gnome classic session in cauldron?

I do not have kodi installed. When I try to launch Gnome classic, ICEwm is partially launched - the panel appears but the rest of the screen remains occupied by the sddm login dialogue and background. 

I get a similar result if I use GDM.

I have task-gnome installed, including gnome-classic-session, and Gnome3 works perfectly.

@ Olav

I don't have the slightest idea what's needed to launch Gnome classical.... can you help, please?

Keywords: NEEDINFO => (none)
Assignee: bugsquad => olav
Summary: Selecting Gnome Classic launches Kodi => Selecting Gnome Classic launches Kodi (or partial IceWM when kodi is not installed)

(In reply to James Kerr from comment #5)

> I have task-gnome installed, including gnome-classic-session, and Gnome3
> works perfectly.

Gnome3 works fine here too.

See also bug 18506 

"After reboot fm installer, classical GNOME logs into AfterStep"

*** Bug 18950 has been marked as a duplicate of this bug. ***

CC: (none) => westel

*** Bug 18506 has been marked as a duplicate of this bug. ***

CC: (none) => dvgevers

Assigning to all packagers as gnome-shell-extensions has no maintainer.

Assignee: olav => pkg-bugs
Source RPM: (none) => gnome-shell-extensions-3.20.1-1.mga6

Lewis wrote in this message
https://ml.mageia.org/l/arc/qa-discuss/2016-07/msg00218.html
that Gnome Classic works when started with

LXDM
LightDM
XDM

but _not_ when using GDM and SDDM)

Adjusting the summary accordingly. 

@ everyone who reported this bug: Please (dis)confirm this is correct for 6sta1 or current network installs.

CC: (none) => mageia
Component: Release (media or process) => RPM Packages
Summary: Selecting GNOME Classic in the DM skips it and the next DE entry in queue, if any (GNOME Classic likely incorrectly packaged) => Starting GNOME Classic from GDM or SDDM fails. Gnome classic starts fine from other DMs.
Source RPM: gnome-shell-extensions-3.20.1-1.mga6 => gdm, gnome-shell-extensions-3.20.1-1.mga6

sorry, I meant: whether what I wrote is correct for 6RC or current cauldron network installs

On a clean net-install of cauldron with Gnome, when gnome-classic is selected 
at the login screen:

GDM - re-displays the login screen
      (GDM does launch Gnome3 successfully)
LXDM - re-displays the login screen 
       (LXDM does launch Gnome3 successfully)
LightDM - re-displays the login screen
	  (LightDM does launch Gnome3 successfully)
SDDM - re-displays the login screen
       (SDDM does launch Gnome3 successfully)

XDM - XDM does not seem to offer a way of selecting the DE. 
      When used it re-displays the login screen.

CC: (none) => jim

Thanks for the feedback, James.

I'm wondering whether Lewis has something installed that you don't have installed, but that helps to start Gnome classical from those lighter DMs.

Could you and Lewys please both attach output.txt that is the result of 

  rpm -qa | sort > output.txt

CC: (none) => lewyssmith
Summary: Starting GNOME Classic from GDM or SDDM fails. Gnome classic starts fine from other DMs. => Starting GNOME Classic from GDM or SDDM fails, but was reported to start from other DMs by one user.

Created attachment 8299 [details]
output from  rpm -qa | sort

My installation was a default install, selecting Gnome from the first selection screen. This is what someone who wanted gnome-classic would probably choose.

(In reply to James Kerr from comment #16)
> Created attachment 8299 [details]
> output from  rpm -qa | sort
> 
> My installation was a default install, selecting Gnome from the first
> selection screen. This is what someone who wanted gnome-classic would
> probably choose.

I'm not a gnome user, so I don't know whether my assumption that Gnome classic needs gnome-desktop-2.32.1-8.mga6 is correct.
(You only have gnome-desktop3-3.20.2-1.mga6, which sounds like it's for Gnome3)

CC'ing tv, because of a vague memory or false memory that he uses Gnome classical

CC: (none) => thierry.vignaud

I do (with GDM) but we use my wife session and we'dn't restarted it for sg like 10 days (we hourly apply cauldron updates but do not restart the session often)

I installed:

- gnome-desktop-2.32.1-8.mga6.x86_64
- gnome-desktop-common-2.32.1-8.mga6.noarch
- lib64gnome-desktop2_17-2.32.1-8.mga6.x86_64

but GDM still fails to launch gnome-classic

(In reply to Thierry Vignaud from comment #19)
> I do (with GDM) but we use my wife session and we'dn't restarted it for sg
> like 10 days (we hourly apply cauldron updates but do not restart the
> session often)

Good to know that it must be possible :-)

This bug was filed in April, so it is unlikely that you'll hit it when restarting the session.

(In reply to James Kerr from comment #20)
> I installed:
> 
> - gnome-desktop-2.32.1-8.mga6.x86_64
> - gnome-desktop-common-2.32.1-8.mga6.noarch
> - lib64gnome-desktop2_17-2.32.1-8.mga6.x86_64
> 
> but GDM still fails to launch gnome-classic

Do all the other DMs now succeed?

@ James

Could you please attach journal.txt that is the result of running, as root, in a VT (tty) from before trying to start Gnome Classic from GDM until after seeing that it fails:

    journalctl -af > journal.txt

Created attachment 8300 [details]
M6 Classic 12 July complete rpm list

12 July M6 Classic all-desktop install on real h/w.
 rpm -qa | sort > m6rpms.txt
Confirm that from GDM, Gnome Classic desktop launches apparently OK, but does not work.
Neither does it work from SDDM, in which case the login dialogue remains on-screen.
Gnome Classic desktop works OK from LightDM & LXDM; also XDM which in my case offers no desktop choice!
Beware that this comment & rpm list is out of date; I will update & repeat the Display Manager v Desktop test.

The cause is the removal of the various Xsession files. GDM starts things via /etc/X11/gdm/Xsession. This script is symlinked against /etc/X11/Xsession. This script comes from xinitrc. Until Mageia 5 we had special files to make xdm and so on work. That stuff was removed, but this Xsession script from xinitrc still relies and checks if it 'knows' about the session.

GDM itself used to supply a different Xsession script. That one actually does work.

Problem is within xinitrc.

Source RPM: gdm, gnome-shell-extensions-3.20.1-1.mga6 => xinitrc

chksession as well as the consolekit bits need to be ripped out.

Assignee: pkg-bugs => olav
Summary: Starting GNOME Classic from GDM or SDDM fails, but was reported to start from other DMs by one user. => /etc/X11/Xsession fails to start GNOME classic session

To avoid any fallout from e.g. running startx from a terminal I limited the changes to:
1. Removing obsolete stuff
2. Small non-invasive hack to make GNOME classic start

xinitrc 2.4.21-18 should work

With xinitrc 2.4.21-18 GDM successfully launches a fully functional gnome-classic

Thanks Olav for the fix

(LXDM can also launch gnome-classic, but SDDM and LightDM fail.)

(In reply to James Kerr from comment #27)
> (LXDM can also launch gnome-classic, but SDDM and LightDM fail.)

SDDM+LightDM still fail?

Yes. Both SDDM and LightDM can launch gnome3, but using either SDDM or LightDM when gnome-classic is selected the screen is blanked momentarily and then the login dialogue is re-displayed.

The behaviours are the same on a system that has Gnome as the only DE and on one where both plasma and Gnome are installed.

From what I read from the SDDM source code, I seems to assume the Exec= command is a program. Example:
Exec=foobar --with=argument

SDDM seems to assume it should find a program called "foobar --with argument", though not exactly sure on this. SDDM eventually executes things via QProcess with some path as argument.

https://github.com/sddm/sddm/blob/master/src/helper/UserSession.cpp

According to the desktop specification, this is not right, see https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#exec-variables:
  "The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments."

This requires a change in SDDM.

Forgot: QProcess would do the right thing if you'd not give any arguments. Then it would try to interpret the command. So a patch which just gives the argument (the path) should work. That's pretty much the limit of what I could do.

SDDM fixed upstream per: https://github.com/sddm/sddm/issues/658

Need someone to patch this into SDDM. https://github.com/sddm/sddm/commit/6ca33ed9b2abc10976e4bf9eaa3a8f18cf3b366e

Reassigning to KDE group.

Assignee: olav => kde

It should be fixed in cauldron then as this commit made it into SDDM 0.14.0.

The pb is that we don't use sddm Xsession.

I think we should use sddm Xsession and now our tweaked one.

Our /usr/share/sddm/scripts/Xsession  is :



#!/bin/bash -login

exec /etc/X11/Xsession $*

# Xsession ends here

maybe this can fix https://bugs.mageia.org/show_bug.cgi?id=19319 too.

maybe this can fix https://bugs.mageia.org/show_bug.cgi?id=19319 too.

Actually, on the contrary if sddm has its own Xsession we should *not* use it, it should look just like Comment 35 and use our /etc/X11/Xsession.  We need to make sure everything uses that, so things work correctly and we don't get inconsistent behavior between different DMs.

Actually, starting from sddm-0.14-9, the /usr/share/sddm/scripts/Xsession and /usr/share/sddm/scripts/Xsetup of sddm, are soft links to /usr/share/X11/xdm/Xsession and /usr/share/X11/xdm/Xsetup_0; /etc/X11/xdm/Xsession is also a link to /usr/share/X11/xdm/Xsession and /etc/X11/xdm/Xsetup_0 is a link to /usr/share/X11/xdm/Xsetup_0; both are part of the xinitrc rpm package.

CC: (none) => ghibomgx

Actually I analyzed the Xsession script and toom me almost all the day. The way actually it works is somewhat ambigue. It assumes the first and unique argument to the script is the desktop environment to run. The environment variable DESKTOP is not passed directly to the script (rather sddm uses DESKTOP_SESSION for the same purpose). But DESKTOP is assigned to the first argument or to what is find assigning the variable DESKTOP found in /etc/sysconfig/desktop. In that case the argument could not be a command but also the name of the session (e.g. KDE, Plasma, GNOME). In that case the conversion is done by the script chksession -x=<name>, which is there since old mandrake, and scans what is available in /usr/share/xsession and provide the equivalent commands to run. That's the ambiguity in the use of DESKTOP for matching.

Indeed sddm, just passes to Xsession what it has scanned in /usr/share/xsession/*desktop; for gnome classic we have this line:

env GNOME_SHELL_SESSION_MODE=classic gnome-session --session gnome-classic

which is in the Exec= line of the gnome-classic.desktop file. That while line is what is passed to Xsession, which is not able to digest. I provide a simple modification to /etc/X11/Xsession of init scripts for the same purpose, so that it would work.

Created attachment 8603 [details]
patch for xinitrc's Xsession to get sddm working with gnome-classic

This patch is for Xsession. It heuristically assumes that at a certain point the desktop is not yet the right one and consider the multiple arguments passed as the command to execute with its arguments. Note that the command is still "valid" because the first command from gnome-classic.desktop is "env" which is a valid command in /bin (or /usr/bin). I also assumed that the last argument is the SESSION name. Indeed SESSION name at that point doesn't matter much, because it's used previously to execute all the scrips in /etc/X11/xinit.d/*, passing SESSION as their first argument. At the point where I set up the SESSION var those script are already executed. But just in the case we decide to move the patch lines above in the script, or the desktop enviroment startup script uses the SESSION variable.

Note also here a first difference. The original Xsession's of sddm script (it has not included anymore in the sddm package), this one:
https://raw.githubusercontent.com/sddm/sddm/develop/data/scripts/Xsession

doesn't run the scripts in /etc/X11/xinit.d/*, as does /etc/X11/Xsession, rather it runs (or to be precise it "sources") all the scripts in /etc/X11/xinit/xinitrc.d/* without any extra arguments).

I don't know whether the xinit scripts were standardized, but the directory /etc/X11/xinit/xinitrc.d/ actually is part of "systemd" and contains only one file, called 50-systemd-user.sh. I think that a certain point all these differences should be subject to reviewed.

Created attachment 8604 [details]
patch for xinitrc's Xsession to get sddm working with gnome-classic (alternate version)

patch for xinitrc's Xsession to get sddm working with gnome-classic. This is an alternate patch, it checks the DESKTOP_SESSION env var, and set the desktop to GNOMEClassic, and then fallback to chksession. Works too.

Giuseppe: I already changed the script as explained in comment 26. Your patch is not needed. The second patch is a hack.

Dear Olaf, I've seen your changes, as it's the block:

        elif echo "$DESKTOP" | grep -q ' '; then
            # DESKTOP could refer to an actual command as given by the DM
            # For Mageia 6 release and GNOME classic, add this nasty hack to
            # check if '$DESKTOP' contains a space, assume it is a full command
            # and then to just start it
            # Mageia bug 18199
            exec /bin/sh -c "$DESKTOP"
        else

but this block fails under sddm, for instance with GNOME-Classic (in that case you log in the first session instead of GNOME-Classic, and first session detected is Plasma). That's why I posted the patch (yes the 2nd one is a hack of course).

The first patch, that I tested under sddm, works and it's also for robustness. "Robust" is something that might resist to "stronger" or "unexpected" sollecitations.

Note that the /etc/sysconfig/desktop might just containing 

DESKTOP=default
DISPLAYMANAGER=sddm

or sometimes even nothing. In that case the DESKTOP will present to your test will be always equal "desktop" and of course would fail to detect the command line, which are not in the DESKTOP var (DESKTOP var is never passed with the full command name), but rather in the ARGS of the scripts. That's exactly what happens in Xsession when ran trough sddm.

is this bugreport still valid ?

I looked at this very throughly today and it no longer looks to be a problem. Changing status to Resolved/Fixed.

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