GDM update!

GDM update!

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

Hello Guix!

I’m happy to report that GDM basically works, including choosing among X
session… and it has a neat Guix theme!


[-- Attachment #2: GDM screenshot --]
[-- Type: image/png, Size: 88653 bytes --]

[-- Attachment #3: Type: text/plain, Size: 516 bytes --]


The one thing I didn’t get to work is ~/.xsession support.  Any ideas?

I’d real like to get that fixed and then we can finally replace SLiM
with GDM as the default.

BTW, at the Guix Days, there were discussions about defaulting to
LightDM instead of GDM.  I forgot to mention then that using LightDM
wouldn’t solve the GNOME use case; in particular, closing the lid under
GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
have any effect, which is pretty bad.

Ludo’.

Re: GDM update!

[Marco van Hulten]

Ludovic et al—

On 10 Feb 23:30 Ludovic Courtès wrote:
> I’m happy to report that GDM basically works, including choosing among X
> session… and it has a neat Guix theme!
> [...] 
> 
> The one thing I didn’t get to work is ~/.xsession support.  Any ideas?
> 
> I’d real like to get that fixed and then we can finally replace SLiM
> with GDM as the default.
> 
> BTW, at the Guix Days, there were discussions about defaulting to
> LightDM instead of GDM.  I forgot to mention then that using LightDM
> wouldn’t solve the GNOME use case; in particular, closing the lid under
> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
> have any effect, which is pretty bad.

I have had problems (on different GNU distro's and OpenBSD) with at
least SLiM, GDM and LightDM, ranging from usability ("Do I press Tab or
Enter now?") to forgettability ("I didn't order GNOME!") to not
using .xsession.

Now I tend to use XDM where I can.  For me it is always working as
expected in all the above respects.

—Marco

Re: GDM update!

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]

Hi Ludo,

https://github.com/GNOME/gdm/commit/0bb8a777cfc0a3bc53c2c2830dd7e6e2baeeef38#diff-9b802b1ffb5f0ff95bfaa85046d262e7 says:

>custom is a magic name we used to allow for having the user decide their session by a ~/.xsession file.  We no longer support that construct and haven't for many years. Instead, users who want that functionality can just add a xsession file to accomplish it.
>This commit just removes some left over cruft that never got cleaned up.

Another part is still there:

if [ "x$command" = "xdefault" ] ; then
  if [ -x "$HOME/.Xclients" ]; then
    command="$HOME/.Xclients"
  elif [ -x /etc/X11/xinit/Xclients ]; then
    command="/etc/X11/xinit/Xclients"
  elif [ -x /etc/X11/Xclients ]; then
    command="/etc/X11/Xclients"
  else
    if [ -n "$zenity" ] ; then
        disptext=`gettextfunc "System has no Xclients file, so starting a failsafe xterm session.  Windows will have focus only if the mouse pointer is above them.  To get out of this mode type 'exit' in the window."`
      "$zenity" --info --text "$disptext"
    else
      echo "$0: Cannot find Xclients"
    fi
    exec xterm -geometry 80x24+0+0
  fi
fi

... but not sure how to use it.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: GDM update!

[Alex Griffin]

On Mon, Feb 11, 2019, at 1:55 AM, Ludovic Courtès wrote:
> BTW, at the Guix Days, there were discussions about defaulting to
> LightDM instead of GDM. I forgot to mention then that using LightDM
> wouldn’t solve the GNOME use case; in particular, closing the lid under
> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
> have any effect, which is pretty bad.

According to Hans de Goede's talk[1] at FOSDEM (around 27:00), GDM is currently the only option for running Xorg without root privileges. If true, that's a very compelling reason to default to GDM.
-- 
Alex Griffin

[1]: https://fosdem.org/2019/schedule/event/flickerfree/

Re: GDM update!

[Timothy Sample]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello Guix!
>
> I’m happy to report that GDM basically works, including choosing among X
> session… and it has a neat Guix theme!

Woohoo!  I like the background!

I have some changes that are more-or-less ready.  It’s mostly just
cleaning up, but it makes it so that GNOME does not have to be in the
system profile for GDM to work.  (Note that the GDM service references
GNOME Shell, which requires most of GNOME, but it doesn’t end up in the
profile.)

I spent some time trying to get “libgdm” split out from GDM, but GNOME
Shell kept getting killed with SIGTRAP.  This happens during the
execution of JavaScript code, and the recommended way to get a backtrace
did not work, so I’m stuck there.

I will try and send patches in the next day or two.

> The one thing I didn’t get to work is ~/.xsession support.  Any ideas?

Digging around in the source code, there’s a comment that says that the
distributed “Xsession” script should run “~/.xsession” if passed the
special keyword “custom”.  However, looking at the actual script
suggests that this comment is mistaken.  (If it did work, you might be
able to make a “custom.desktop” file with “Exec=custom” that would
trigger the right behaviour.  I did not test this.)

Debian provides a custom “Xsession” script and a custom
“default.desktop” file, which runs the script with the special argument
“default”.  With this argument, the “Xsession” does a bunch of stuff by
running all of the scripts in an “Xsession.d” directory, including one
that tries running “~/.xsession”.

In short, it looks like we have to either fix or customize the
“Xsession” script.  Making the script work like the comment suggests and
using “custom.desktop” is probably the simplest thing to do.

> I’d real like to get that fixed and then we can finally replace SLiM
> with GDM as the default.
>
> BTW, at the Guix Days, there were discussions about defaulting to
> LightDM instead of GDM.  I forgot to mention then that using LightDM
> wouldn’t solve the GNOME use case; in particular, closing the lid under
> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
> have any effect, which is pretty bad.

Of course, it is good to have a nice alternative to SLiM that is simpler
than GDM.  GDM is needed for the proper GNOME experience, but it is too
much for most non-GNOME setups.  Ultimately, Guix is nice and
configurable, so I’m everyone can find a way to be happy.  :)


-- Tim

Re: GDM update!

[Timothy Sample]

Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Ludo,
>
> https://github.com/GNOME/gdm/commit/0bb8a777cfc0a3bc53c2c2830dd7e6e2baeeef38#diff-9b802b1ffb5f0ff95bfaa85046d262e7 says:
>
>>custom is a magic name we used to allow for having the user decide
>> their session by a ~/.xsession file.  We no longer support that
>> construct and haven't for many years. Instead, users who want that
>> functionality can just add a xsession file to accomplish it.
>>This commit just removes some left over cruft that never got cleaned up.
>
> [...]

Thanks!  I didn’t see this before writing my other message, but it
explains why the comments and code don’t match.

Maybe the GDM folks expect that we write a custom “.desktop” file that
runs a custom script that checks for “~/.xsession” and runs it.  It
could use “TryExec” to figure out if “~/.xsession” exists, and offer it
to the user (in the session selector) in that case.  To be concrete, we
would create a “user.desktop” session file with the following contents.

    [Desktop Entry]
    Name=User Session
    Comment=Start a user-defined session
    Exec=run-user-xsession
    TryExec=xsession-exists-p
    Icon=
    Type=Application

Here, “run-user-xsession” and “xsession-exists-p” are custom scripts
that we would write.  If this file were somewhere that GDM knows about
(e.g., “/run/current-system/profile/share/xsessions”), it should work.


-- Tim

Re: GDM update!

[Ludovic Courtès]

Hello!

Timothy Sample <samplet@ngyro.com> skribis:

> Maybe the GDM folks expect that we write a custom “.desktop” file that
> runs a custom script that checks for “~/.xsession” and runs it.  It
> could use “TryExec” to figure out if “~/.xsession” exists, and offer it
> to the user (in the session selector) in that case.  To be concrete, we
> would create a “user.desktop” session file with the following contents.
>
>     [Desktop Entry]
>     Name=User Session
>     Comment=Start a user-defined session
>     Exec=run-user-xsession
>     TryExec=xsession-exists-p
>     Icon=
>     Type=Application
>
> Here, “run-user-xsession” and “xsession-exists-p” are custom scripts
> that we would write.  If this file were somewhere that GDM knows about
> (e.g., “/run/current-system/profile/share/xsessions”), it should work.

We could do that, or should we just arrange for GDM to honor .xsession
when it exists just like we do for SLiM?

Specifically I’m thinking of the ‘xinitrd’ procedure in (gnu services
xorg) and how we pass it to SLiM via ‘slim.cfg’.

WDYT?

Thanks,
Ludo’.

Re: GDM update!

[Ludovic Courtès]

Timothy Sample <samplet@ngyro.com> skribis:

> I have some changes that are more-or-less ready.  It’s mostly just
> cleaning up, but it makes it so that GNOME does not have to be in the
> system profile for GDM to work.  (Note that the GDM service references
> GNOME Shell, which requires most of GNOME, but it doesn’t end up in the
> profile.)

Oh, are you saying that currently GNOME must be in the system profile
for GDM to work?  I hadn’t realized.

My goal was to have GDM instead of SLiM in ‘%desktop-services’, but
‘%desktop-services’ does not necessarily imply GNOME.  So I guess your
patches will be more than welcome!

>> The one thing I didn’t get to work is ~/.xsession support.  Any ideas?

[...]

> Debian provides a custom “Xsession” script and a custom
> “default.desktop” file, which runs the script with the special argument
> “default”.  With this argument, the “Xsession” does a bunch of stuff by
> running all of the scripts in an “Xsession.d” directory, including one
> that tries running “~/.xsession”.

If Debian does it this way, then maybe we should just follow suit.

>> BTW, at the Guix Days, there were discussions about defaulting to
>> LightDM instead of GDM.  I forgot to mention then that using LightDM
>> wouldn’t solve the GNOME use case; in particular, closing the lid under
>> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
>> have any effect, which is pretty bad.
>
> Of course, it is good to have a nice alternative to SLiM that is simpler
> than GDM.  GDM is needed for the proper GNOME experience, but it is too
> much for most non-GNOME setups.  Ultimately, Guix is nice and
> configurable, so I’m everyone can find a way to be happy.  :)

Definitely.  I think we should default to GDM in ‘%desktop-services’ for
accessibility and localization and so that GNOME actually works out of
the box when people choose it, but obviously everyone is free to
customize their config!

Thanks,
Ludo’.

Re: GDM update!

[Timothy Sample]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Timothy Sample <samplet@ngyro.com> skribis:
>
>> Maybe the GDM folks expect that we write a custom “.desktop” file that
>> runs a custom script that checks for “~/.xsession” and runs it.  It
>> could use “TryExec” to figure out if “~/.xsession” exists, and offer it
>> to the user (in the session selector) in that case.  To be concrete, we
>> would create a “user.desktop” session file with the following contents.
>>
>>     [Desktop Entry]
>>     Name=User Session
>>     Comment=Start a user-defined session
>>     Exec=run-user-xsession
>>     TryExec=xsession-exists-p
>>     Icon=
>>     Type=Application
>>
>> Here, “run-user-xsession” and “xsession-exists-p” are custom scripts
>> that we would write.  If this file were somewhere that GDM knows about
>> (e.g., “/run/current-system/profile/share/xsessions”), it should work.
>
> We could do that, or should we just arrange for GDM to honor .xsession
> when it exists just like we do for SLiM?
>
> Specifically I’m thinking of the ‘xinitrd’ procedure in (gnu services
> xorg) and how we pass it to SLiM via ‘slim.cfg’.
>
> WDYT?

Do you mean that we should not use the GDM-provided “Xsession” script
and tell GDM to run an “xinitrc” script generated by the “xinitrc”
procedure?  This would work.  In fact, the way that our “xinitrc” (by
default) looks for session files in user profiles is a major
improvement.  Indeed, it makes more sense to replace the script entirely
than to try and carefully construct everything so that it does what we
want.  This is especially true considering that upstream expects distros
to replace the script anyway.

We will have to pass the script in as a variable.  I will do this on top
of my changes (which I hope to send in today).


-- Tim

Re: GDM update!

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

While supporting Xsession and xinitrc is important for backward compatibility,
Guix could also have its own way with shepherd user services (see the recent
discussion on Guix-devel), which would supersede most "initialization dotfiles".

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: GDM update!

[Timothy Sample]

Hi Pierre,

Pierre Neidhardt <mail@ambrevar.xyz> writes:

> While supporting Xsession and xinitrc is important for backward compatibility,
> Guix could also have its own way with shepherd user services (see the recent
> discussion on Guix-devel), which would supersede most "initialization dotfiles".

I agree, but we discussed this before and thought that it was too much
of a leap for right now.  Once we have session shepherd instances, we
could consider replacing the whole of “gdm-x-session” with launching a
session shepherd that would in-turn launch D-Bus and X and whatever
else.  That will be great, but it will take a lot longer.  In the
meantime, we might as well get GDM working the old way.


-- Tim