unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Timothy Sample <samplet@ngyro.com>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: 35068@debbugs.gnu.org
Subject: bug#35068: GDM crashes when it cannot find any .desktop files
Date: Thu, 25 Apr 2019 21:02:53 -0400	[thread overview]
Message-ID: <87pnp97f42.fsf@ngyro.com> (raw)
In-Reply-To: <20190425211540.3ecda900@scratchpost.org> (Danny Milosavljevic's message of "Thu, 25 Apr 2019 21:15:40 +0200")

Hi Danny,

Oh my!  I explained things very poorly.  Sorry.  I’ll provide some more
context.

Danny Milosavljevic <dannym@scratchpost.org> writes:

> Hi Timothy,
>
> On Thu, 25 Apr 2019 14:49:42 -0400
> Timothy Sample <samplet@ngyro.com> wrote:
>
>> exploding.  I did look at Danny’s patch (#35377), and it would work, but
>> it seems a little arbitrary.  Nothing understands the “Exec=custom”
>> line, and our “xinitrc” runs “~/.xsession” regardless of what desktop
>> entry is selected in the DM.
>
> gdm does know it.  It bundles gdm Xsession startup scripts and then runs
> ".xsession" (see data/Xsession.in) if available, otherwise ~/.Xclients.

By default, GDM does not bundle an Xsession script.  You have to pass
“--enable-gdm-xsession” to the configure script for it to be installed.
I added this flag in 51bc8357e8457d5d7168d8837da6e14fa2d98485, but the
script doesn’t support “~/.xsession” scripts, so (after some discussion)
I removed it in 41fa9f1815685ede0d3fdc1c561d2a9cf0ffb158.  It seems that
most distros use their own scripts and in turn, the GDM folks don’t
really give much thought to “data/Xsession.in”.

Furthermore (I was surprised by this), even though the
“data/Xsession.in” script says that it will honour “custom” in a
comment, the code says otherwise.  There’s a commit where support for it
gets removed, but they must have forgotten about the comment.

>> There are two workarounds.  The first is to keep Danny’s patch as-is,
>> but add logic to “xinitrc” so that it only uses “~/.xsession” when
>
> .xinitrc is not picked up by gdm.  Do you mean by startx?

No.  We have our own script that we use to initialize X and it is bound
to “xinitrc” in “gnu/services/xorg.scm”.  You can override it from the
GDM configuration record.

>> break other DMs that don’t install a “custom.desktop”.  Maybe we could
>> integrate it into all DMs at the service level.
>
> Well, the best way would be for gdm to support .xsession files like anyone
> else (without desktop file)--but I'm not holding my breath.

We don’t need a “.desktop” file currently.  My personal opinion is that
having the existence of the “~/.xsession” script override your
explicitly stated session selection when logging in is a little
surprising.  But if that’s conventional, then I’m happy to follow
convention.

>> This way, GDM fails cleanly when there are no “.desktop” files.  It
>> doesn’t show up in the list, either (“NoDisplay=true”), so everything
>> just kinda works as expected without any visible changes.
>
> I want it to show up in the list.  Maybe we are trying to reach different
> goals here.  I have a ~/.xsession script for close to a decade now and I
> want gdm to use it.  It's not only to keep gdm from crashing, it's so I
> can get into my normal customized desktop.
>
> Doesn't Exec=false make the login fail?  Or do you mean gdm will pick up
> .xsession anyway and run it--and after the session is terminated, the
> login will fail?  Why would it then fail?  Why not make it succeed?

Currently, our “xinitrc” script will run your “~/.xsession” script if it
exists, regardless of what session you select when logging in.  However,
GDM will crash if you do not have any “.desktop” files.  You don’t
really need a “.desktop” file for anything, but GDM goes nuts if it
can’t find any.  So, we could fix GDM, but that looks pretty tricky.  In
lieu of that, we could provide a dummy “.desktop” that is invisible and
exists only to placate GDM when no other “.desktop” file exists.  With
the dummy file, if you have a “~/.xsession” script, you will be able to
log in even if you have no other “.desktop” files.  If you have no
“.desktop” files and no “~/.xsession” script, logging in will fail
(which seems reasonable, seeing how desperate the circumstances are).

>> Danny, maybe you could adjust your patch to follow the second option and
>> apply it for the sake of everyone else who’s system profile doesn’t have
>> any “.desktop” files.  It might save people headaches in the short-term
>> regardless of what we settle on as a final solution.
>
> Sounds good in principle, as long as it actually allows me to log in to
> my desktop.

According to all the tests I did this afternoon, it should!  :)

For people with other “.desktop” files, everything should be the same.
For people with no other “.desktop” files GDM will no longer go bananas,
but rather let you log in using “~/.xsession”.

> FWIW, "Exec=custom" is the way gdm itself does it.

It’s true that most distros honour “custom” in their scripts.  It
doesn’t happen at the GDM level, though (like I wrote above).

> Still, ~/.xinitrc is not picked up either way--which is too bad.

Isn’t that script specific to “startx”?  (That’s at least what a popular
question and answer site tells me.)


-- Tim

  reply	other threads:[~2019-04-26  1:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01  8:05 bug#35068: GDM crashes when it cannot find any .desktop files Ludovic Courtès
2019-04-20 15:06 ` Danny Milosavljevic
2019-04-20 20:22   ` Ludovic Courtès
2019-04-21  9:37   ` Danny Milosavljevic
2019-04-21  9:43     ` Danny Milosavljevic
2019-04-21 20:12     ` Ludovic Courtès
2019-04-25 18:49       ` Timothy Sample
2019-04-25 19:15         ` Danny Milosavljevic
2019-04-26  1:02           ` Timothy Sample [this message]
2019-04-26  9:36             ` Danny Milosavljevic
2019-04-26  8:10         ` Ludovic Courtès
2019-04-26 18:32           ` Timothy Sample
2019-04-27 16:27             ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pnp97f42.fsf@ngyro.com \
    --to=samplet@ngyro.com \
    --cc=35068@debbugs.gnu.org \
    --cc=dannym@scratchpost.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).