guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#35305] LightDM service


From: L p R n d n
Subject: [bug#35305] LightDM service
Date: Mon, 11 May 2020 12:14:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello,

Ricardo Wurmus <address@hidden> writes:

> L p R n d n <address@hidden> writes:
>
>>> I built a VM and noticed that all icons are missing.  Should the service
>>> arrange for a certain fallback icon theme to be installed?
>>
>> If you only added (service-type lightdm-service-type) without any
>> greeter, it's expected.
>> LightDM without autologin needs a greeter. So in this case you just get
>> a "fallback" session to avoid unnecesseraly breaking the user's
>> system. I choose not to bring lightdm-gtk-greeter's assets to give the
>> user a little push toward adding a greeter service.
>
> Ah, now I understand the comment in lightdm-profile-service.

Sorry, my comment was not clear :/

> I think the default configuration should take care of all this.  It
> seems problematic to me that users specify “greeter-session” as a mere
> string, but the corresponding greeter may not even be installed.  That’s
> also what’s bothering me about the greeter search directories.

I agree but just to clarify the current behavior:
* A user can either define only a lightdm-service, only greeter-service.s
or both.
* There can be multiple greeter services defined hence allowing
different greeters, greeter configurations or assets for different seats
* Greeters' services extend the lightdm-service so the latter is really only 
needed
if you want to modify the default confiuration or do not define any
greeter.
* A seat defined in a greeter service have its `greeter-session
overwritten + get the greeter package for free. This is why defining
seats through the greeter is preferred.

Hope it's clear, I had some troubles with the possessive in those sentences...

> Would it make sense to let “greeter-session” be a *package* instead of a
> string?  Then we could specify the lightdm-gtk-greeter package as the
> default and use its output directory as the lookup directory for
> greeters — instead of the global system profile.

Yet, it's better, yes! So we remove the `greeters-directory field from the
`lightdm-configuration and use a package as input of the greeter-session
field of `lightdm-seat-configuration, right?

> I think this would be more elegant and reduce potential for
> misconfiguration.  What do you think about this?
>
>> It's very arguable
>> so if you think we should bring in assets too, let's do it. I can
>> prepare a patch if you want.
>
> What do you mean by assets?  Which package provides them?

I meant the assets used by the greeter. They're defined in the
`lightdm-gtk-greeter-configuration-assets field of the
lightdm-gtk-greeter's configuration. It's really the only thing lacking
in the fallback session. A little patch that should be enough to fix the
missing icons.

diff --git a/gnu/services/lightdm.scm b/gnu/services/lightdm.scm
index fa5330aade..0ef7f43215 100644
--- a/gnu/services/lightdm.scm
+++ b/gnu/services/lightdm.scm
@@ -291,7 +291,9 @@ remote-sessions-directory = " ,remote-sessions-directory "
   (let ((seats (lightdm-configuration-seats config))
         (lightdm (lightdm-configuration-lightdm config)))
     (if (null? seats)
-        (list lightdm lightdm-gtk-greeter)
+        (list lightdm lightdm-gtk-greeter
+              ;; assets
+              adwaita-icon-theme gnome-themes-standard)
         (list lightdm))))
 
 (define lightdm-service-type
>>> I also haven’t actually been able to log in as root with an empty
>>> password, which is what the VM generates by default.  Can this be
>>> supported with lightdm?
>>
>> Didn't succeed either but it should be possible... :/
>> Looking on the web, on passwordless login, the lightdm-autologin pam is
>> often cited so this line:
>>
>> (pam-entry (control "required") (module "pam_succeed_if.so")
>>            (arguments (list "uid >= 1000")))
>>
>> might be related. But I'm really not knowledgeable enough on this matter
>> to give a proper answer.
>
> I can take a look at this and the other PAM questions you had.

That would be nice! Beside this point, it's really checking that
there are no errors.

> --
> Ricardo

Have a nice day,

L  p R n  d n

reply via email to

[Prev in Thread] Current Thread [Next in Thread]