GNU bug report logs - #35305
[WIP] LightDM service

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35305 in the body.
You can then email your comments to 35305 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: guix-patches <at> gnu.org
Subject: [WIP] LightDM service
Date: Wed, 17 Apr 2019 16:24:43 +0200

[Message part 1 (text/plain, inline)]

Hello,

Wanted to work on Guix's website but fate led me to try my way on a
lightdm service...
So, here is what I got for now.
It fails to start a window manager but I don't think I'll be able to
debug the last mile with my sole knowledge.

Beside that, here is a list of possible improvements before merging:

* lightdm-greeter-gtk configuration is a part of lightdm's service.
It might be a good idea to give it its own service but it would
mean we need to write a service for each lightdm greeter.

* lightdm complains about the lack of
  org.freedesktop.DisplayManager.AccountsService interface.
  The lightdm package provides the relevent files but it seems
  accountsservice doesn't find them. I think it searches them in
  $XDG_DATA_DIRS/accountservices . See
  https://github.com/NixOS/nixpkgs/issues/45059

* lightdm-gtk-greeter's wrapper is handmade and ugly.

* General refining.

A thorough review would also be welcome as I'm not really sure I know
what I'm doing.

Thanks!

L  p R n  d n   

[0001-gnu-lightdm-Update-1.28.0.patch (text/x-patch, attachment)]

[0002-gnu-lightdm-Add-vala-bindings.patch (text/x-patch, attachment)]

[0003-gnu-lightdm-Re-enable-all-tests.patch (text/x-patch, attachment)]

[0004-gnu-lightdm-gtk-greeter-Update-to-2.0.6.patch (text/x-patch, attachment)]

[0005-gnu-lightdm-gtk-greeter-Fix-at-spi-runtime-dependenc.patch (text/x-patch, attachment)]

[0006-gnu-lightdm-gtk-greeter-Fix-.desktop-file.patch (text/x-patch, attachment)]

[0007-gnu-lightdm-gtk-greeter-Wrap-binary.patch (text/x-patch, attachment)]

[0008-gnu-lightdm-Build-accountsservice-files.patch (text/x-patch, attachment)]

[0009-gnu-lightdm-gtk-greeter-Fix-some-warnings.patch (text/x-patch, attachment)]

[0010-services-Add-lightDM-service.patch (text/x-patch, attachment)]

Message #8 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Jonathan Brielmaier <jonathan.brielmaier <at> web.de>
To: 35305 <at> debbugs.gnu.org
Subject: [WIP] LightDM service
Date: Thu, 18 Apr 2019 13:20:19 +0200

Please add gnu/services/lightdm.scm to gnu/local.mk

Message #11 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: Re: bug#35305: Acknowledgement ([WIP] LightDM service)
Date: Thu, 18 Apr 2019 15:20:31 +0200

[Message part 1 (text/plain, inline)]

Hello,

After some work, here is a new patch replacing the last one from
previous mail. It now seems to work as it successfully starts a window
manager.

Have a nice day,

L  p R n  d n

[0010-services-Add-lightdm-service.patch (text/x-patch, attachment)]

Message #14 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: Re: bug#35305: Acknowledgement ([WIP] LightDM service)
Date: Thu, 18 Apr 2019 18:03:08 +0200

[Message part 1 (text/plain, inline)]

New patch for addinf lightdm service replacing previous one.
Now with local.mk changes.

Have a nice day,

L  p R n  d n

[0010-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

Message #17 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: [PATCH] LightDM service
Date: Thu, 23 May 2019 13:04:44 +0200

[Message part 1 (text/plain, inline)]

Hello,

New patch for adding the lightDM service replacing the previous one.
Added some doc, simplified lightdm-configuration to look a little bit
more like other display manager's services and use xorg-configuration.
We can always add more options later if needed.
I also made an attempt at factoring out the lightdm-gtk-greeter
configuration. It should be easier to add configuration of other greeter
but there might be better ways.
I'm open to suggestions but otherwise it should be mergeable.
Thanks,

Have a nice day,

L  p R n  d n

[0010-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

Message #20 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: Re: bug#35305: Acknowledgement ([WIP] LightDM service)
Date: Mon, 26 Aug 2019 17:58:49 +0200

ping

Message #23 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Nicolò Balzarotti <anothersms <at> gmail.com>
To: L  p R n  d n <guix <at> lprndn.info>, 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] Acknowledgement ([WIP] LightDM service)
Date: Sun, 15 Mar 2020 22:50:07 +0100

Cool, I was wondering why the lightdm package was available but no
service was provided for it.  Anything blocking this patch?

Thanks, Nicolò

L  p R n  d n    <guix <at> lprndn.info> writes:

> ping

Message #26 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: Nicolò Balzarotti <anothersms <at> gmail.com>
Cc: 35305 <at> debbugs.gnu.org, L p R n d n <guix <at> lprndn.info>
Subject: Re: [bug#35305] Acknowledgement ([WIP] LightDM service)
Date: Mon, 16 Mar 2020 09:34:50 +0200

[Message part 1 (text/plain, inline)]

On Sun, Mar 15, 2020 at 10:50:07PM +0100, Nicolò Balzarotti wrote:
> Cool, I was wondering why the lightdm package was available but no
> service was provided for it.  Anything blocking this patch?
> 
> Thanks, Nicolò
> 
> L  p R n  d n    <guix <at> lprndn.info> writes:
> 
> > ping

I don't think anyone got around to reviewing it :/

-- 
Efraim Flashner   <efraim <at> flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 35305 <at> debbugs.gnu.org,
 Nicolò Balzarotti <anothersms <at> gmail.com>
Subject: Re: [bug#35305] Acknowledgement ([WIP] LightDM service)
Date: Mon, 16 Mar 2020 09:36:46 +0100

Hello,

Also a rebase on latest master might be necessary. I was waiting for
staging to be merged so if I got time, I'll probably take care of this
during the week. ;)

Have a nice day,

L  p R n  d n   

Message #32 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Thu, 19 Mar 2020 12:54:30 +0100

[Message part 1 (text/plain, inline)]

Hello,

Here is the new set of reworked patches. I tested it quickly in a
vm with xfce and gnome (login, logout, switch user) and it seems ok.
I also attach a little scm file with a simple system definition with
lightdm and xfce for those willing to test it.
(also the password is "q" without quotes).

Have a nice day,


L  p R n  d n

[0001-gnu-lightdm-Update-1.30.0.patch (text/x-patch, attachment)]

[0002-gnu-lightdm-Add-vala-bindings.patch (text/x-patch, attachment)]

[0003-gnu-lightdm-Disable-python-tests-only.patch (text/x-patch, attachment)]

[0004-gnu-lightdm-gtk-greeter-Update-to-2.0.7.patch (text/x-patch, attachment)]

[0005-gnu-lightdm-gtk-greeter-Fix-at-spi-runtime-dependenc.patch (text/x-patch, attachment)]

[0006-gnu-lightdm-gtk-greeter-Fix-.desktop-file.patch (text/x-patch, attachment)]

[0007-gnu-lightdm-gtk-greeter-Wrap-binary.patch (text/x-patch, attachment)]

[0008-gnu-lightdm-Build-accountsservice-files.patch (text/x-patch, attachment)]

[0009-gnu-lightdm-gtk-greeter-Fix-some-warnings.patch (text/x-patch, attachment)]

[0010-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

[lightdm-desktop-test.scm (text/plain, attachment)]

Message #35 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Brice Waegeneire <brice <at> waegenei.re>
To: guix <at> lprndn.info
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Tue, 07 Apr 2020 17:06:34 +0000

Hello L p R n d n,

I never did a review before but I would like to see this patch merged, 
so
bear with me.

The indentation of lightdm's origin should probably be done in the 
commit
01 not 03.

> `("XDG_DATA_DIRS" ":" prefix (,(string-append (assoc-ref inputs 
> "hicolor-icon-theme")
>                                               "/share")
>                               ,(string-append (assoc-ref inputs "glib")
>                                               "/share")
>                               ,(string-append (assoc-ref inputs 
> "shared-mime-info")
>                                               "/share")
>                               ,(string-append (assoc-ref inputs "gtk+")
>                                               "/share")
>                               ,(string-append (assoc-ref inputs "exo")
>                                               "/share")
>                               ,(string-append (assoc-ref outputs "out")
>                                               "/share")
>                               "/run/current-system/profile/share"))
This part can use a map procedure.

It would be nice if “lightdm-service-type” support 
“set-xorg-configuration”
like the other login manager now does by using 
“handle-xorg-configuration”
see 50be0da7bfd5c108697679effeb2a893d2f37598 for how it's done in GDM, 
SLIM
and co.

> +         (comment "LighDM user")
                          ^ a “t” is missing here

> +(define (lightdm-shepherd-service config)
> +  "Return a <lightdm-service> for LightDM with CONFIG."
> +
> +  (define lightdm-command
> +    #~(list (string-append #$(lightdm-configuration-lightdm config) 
> "/sbin/lightdm")))
[…]
> + (fork+exec-command
> + (list #$(file-append
> + (lightdm-configuration-lightdm config)
> + "/sbin/lightdm"))

“lightdm-command” isn't used, I get the hint it ought to be the argument 
of
“fork+exec-command.”


> +(define (lightdm-etc-service config)
> +  (list `("xdg/lightdm/lightdm.conf.d/lightdm.conf"
> +          ,(lightdm-configuration-file config))
> +        `(,(string-append "xdg/lightdm/"
> +                          (computed-file-name
> +                           
> (lightdm-configuration-greeter-configuration config)))
> +          ,(lightdm-configuration-greeter-configuration config))))

I've been told, in Guix, it's better to avoid putting configuration in
“/etc” since it cause edge case during rollback and such, specifying the
configuration by passing the “--config” argument to “lightdm” would be 
more
appropriate.

> +        (define %user
> +          (getpw "lightdm"))
> +        (let ((directory "/var/lib/lightdm-data"))
> +          (mkdir-p directory)
> +          (chown directory (passwd:uid %user) (passwd:gid %user))))))

“%user” could go in the “let”. BTW can't lightdm use its user home
directory instead of “/var/lib/lightdm-data” or the reverse; IOW does it
need to have to own two directories in “/var/lib”?

Several lines in “gnu/services/lightdm.scm” exceed the maximal line 
length.


Thank you very much for this patch series. I'm impatient seeing it in 
Guix
proper.

- Brice

Message #38 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Brice Waegeneire <brice <at> waegenei.re>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Thu, 09 Apr 2020 18:02:15 +0200

[Message part 1 (text/plain, inline)]

Hello,

Brice Waegeneire <brice <at> waegenei.re> writes:

> Hello L p R n d n,
>
> I never did a review before but I would like to see this patch merged, so
> bear with me.

Thank you for the review! It's my first service for guix so we're
probably even here. ;)

> The indentation of lightdm's origin should probably be done in the commit
> 01 not 03.

Done.

>> `("XDG_DATA_DIRS" ":" prefix (,(string-append (assoc-ref inputs
>> "hicolor-icon-theme")
>>                                               "/share")
>>                               ,(string-append (assoc-ref inputs "glib")
>>                                               "/share")
>>                               ,(string-append (assoc-ref inputs
>> "shared-mime-info")
>>                                               "/share")
>>                               ,(string-append (assoc-ref inputs "gtk+")
>>                                               "/share")
>>                               ,(string-append (assoc-ref inputs "exo")
>>                                               "/share")
>>                               ,(string-append (assoc-ref outputs "out")
>>                                               "/share")
>>                               "/run/current-system/profile/share"))
> This part can use a map procedure.

Done. + cleaned some things that weren't necessary.

> It would be nice if “lightdm-service-type” support “set-xorg-configuration”
> like the other login manager now does by using “handle-xorg-configuration”
> see 50be0da7bfd5c108697679effeb2a893d2f37598 for how it's done in GDM, SLIM
> and co.
>
>> +         (comment "LighDM user")
>                           ^ a “t” is missing here

Huh.. Done (I think...) and done!

>> +(define (lightdm-shepherd-service config)
>> +  "Return a <lightdm-service> for LightDM with CONFIG."
>> +
>> +  (define lightdm-command
>> +    #~(list (string-append #$(lightdm-configuration-lightdm config)
>> "/sbin/lightdm")))
> […]
>> + (fork+exec-command
>> + (list #$(file-append
>> + (lightdm-configuration-lightdm config)
>> + "/sbin/lightdm"))
>
> “lightdm-command” isn't used, I get the hint it ought to be the argument of
> “fork+exec-command.”

Done.

>
>> +(define (lightdm-etc-service config)
>> +  (list `("xdg/lightdm/lightdm.conf.d/lightdm.conf"
>> +          ,(lightdm-configuration-file config))
>> +        `(,(string-append "xdg/lightdm/"
>> +                          (computed-file-name
>> +                           (lightdm-configuration-greeter-configuration
>> config)))
>> +          ,(lightdm-configuration-greeter-configuration config))))
>
> I've been told, in Guix, it's better to avoid putting configuration in
> “/etc” since it cause edge case during rollback and such, specifying the
> configuration by passing the “--config” argument to “lightdm” would be more
> appropriate.

Need some advices here as even if "--config" works for LightDM, greeters
also search their config in /etc. They're all different so they might or
might not provide a convenient way to do it... :/
In the meantime, kept the etc-service-extension + prevented errors in
case a file wasn't provided.

>> +        (define %user
>> +          (getpw "lightdm"))
>> +        (let ((directory "/var/lib/lightdm-data"))
>> +          (mkdir-p directory)
>> +          (chown directory (passwd:uid %user) (passwd:gid %user))))))
>
> “%user” could go in the “let”. BTW can't lightdm use its user home
> directory instead of “/var/lib/lightdm-data” or the reverse; IOW does it
> need to have to own two directories in “/var/lib”?

Reworked everything a little bit to match what is done for gdm.
I think we can use a CFLAG to change "/var/lib/lightdm-data" to
"/var/lib/lightdm/lightdm-data" for example. However, I think lightdm
sometime cleans or delete stuff in "/var/lib/lightdm" so it might
explain why there are two directories. I don't know what
"/var/lib/lightdm-data" is used for but LightDM does complain if it
doesn't exist. Advices needed here too.

> Several lines in “gnu/services/lightdm.scm” exceed the maximal line length.
>

Tried to keep them below 80. Is it ok?

>
> Thank you very much for this patch series. I'm impatient seeing it in Guix
> proper.
>
> - Brice


+ Corrected some typos in the documentation and added an extra-config
field to lightd and lightdm-gtk-greeter's configuration.

Hope it's better now, new patches are attached below.

Have a nice day,

L  p R n  d n

[0001-gnu-lightdm-Update-1.30.0.patch (text/x-patch, attachment)]

[0002-gnu-lightdm-Add-vala-bindings.patch (text/x-patch, attachment)]

[0003-gnu-lightdm-Disable-python-tests-only.patch (text/x-patch, attachment)]

[0004-gnu-lightdm-gtk-greeter-Update-to-2.0.7.patch (text/x-patch, attachment)]

[0005-gnu-lightdm-gtk-greeter-Fix-at-spi-runtime-dependenc.patch (text/x-patch, attachment)]

[0006-gnu-lightdm-gtk-greeter-Fix-.desktop-file.patch (text/x-patch, attachment)]

[0007-gnu-lightdm-gtk-greeter-Wrap-binary.patch (text/x-patch, attachment)]

[0008-gnu-lightdm-Build-accountsservice-files.patch (text/x-patch, attachment)]

[0009-gnu-lightdm-gtk-greeter-Fix-some-warnings.patch (text/x-patch, attachment)]

[0010-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

Message #41 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Brice Waegeneire <brice <at> waegenei.re>
To: L  p R n  d n <guix <at> lprndn.info>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Sun, 12 Apr 2020 09:53:41 +0000

Hello L p R n d n,

Using `set-xorg-configuration` with `lightdm-service-type` seems to be
working.

There is an error on vt1 at startup about some dbus stuff related to
“accountservice”. The cursor theme isn't set as well as the icon theme, 
it
seems; it may come from some missing environment variable as NixOS set a
few of them in their service[0].

After digging in the new service file I keep wondering if it's the right
way to go about implementing it. I tried to set a simple setting
for `lightdm-gtk-greeter` and I ended up with the following which 
doesn't
look intuitive:

--8<---------------cut here---------------start------------->8---
(service lightdm-service-type
         (lightdm-configuration
          (greeter-configuration-file
           (lightdm-gtk-greeter-configuration-file
            (lightdm-gtk-greeter-configuration
             (extra-config "hide-user-image=true"))))))
--8<---------------cut here---------------end--------------->8---

Furthermore `lightdm-service-type` only set a single seat while lightdm 
can
have many of them. So maybe there should be a lightdm-seat` record used 
as
a list of seats in `lightdm-service-type`. Each greater will be able to
expand `lightdm-service-type` by appending a seat to it. Then the
configuration could look like this:

--8<---------------cut here---------------start------------->8---
(service lightdm-service-type)
(service lightdm-gtk-greeter-service-type
         (lightdm-gtk-greeter-configuration
          (assets (list guix-artwork))
          (theme-name "Guix")
          (extra-config "hide-user-image=true")))
--8<---------------cut here---------------end--------------->8---

Using this approch would also avoid populating “/etc”, at least for
`lightdm-grk-greeter`, since each greeter would be defined as a service 
and
could expand “/etc” if it really needs it. For `lightdm-gtk-greeter`
specifically avoiding putting config in “/etc/” can be done by compiling 
it
with `-DCONFIG_FILE` pointing to `/run/current-system` And `lightdm` can 
be
started with `--config`.

Here is an example in how to make a conjuration file procedure more
readable while keeping under the line length limit by using 
`match-record`:

--8<---------------cut here---------------start------------->8---
(define (lightdm-gtk-greeter-configuration-file config)
  (match-record config <lightdm-gtk-greeter-configuration>
    (theme-name icon-theme-name cursor-theme-name cursor-size background
                extra-config)
   (mixed-text-file "lightdm-gtk-greeter.conf" "
[greeter]
theme-name = "           theme-name                   "
icon-theme-name = "      icon-theme-name              "
cursor-theme-name = "    cursor-theme-name            "
cursor-theme-size = "    (number->string cursor-size) "
background = "           background                   "
" extra-config                                        "
")))
--8<---------------cut here---------------end--------------->8---

BTW the default background could use one from Guix artwork repo like
“(file-append %artwork-repository "/grub/GuixSD-fully-black-16-9.svg")”.

WDYT? I may be completely off on the `lightdm-seat` part.

[0]: 
https://github.com/NixOS/nixpkgs/blob/release-19.09/nixos/modules/services/x11/display-managers/lightdm-greeters/gtk.nix#L18

Cheers,
- Brice

Message #44 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Brice Waegeneire <brice <at> waegenei.re>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Tue, 14 Apr 2020 11:38:18 +0200

Hello,

Thanks again for the feedbacks.

Brice Waegeneire <brice <at> waegenei.re> writes:

[...]
> There is an error on vt1 at startup about some dbus stuff related to
> “accountservice”. The cursor theme isn't set as well as the icon theme, 
> it
> seems; it may come from some missing environment variable as NixOS set a
> few of them in their service[0].

For the cursor, setting "XCURSOR_PATH" seems to solve the problem.
Preparing a patch.

As for dbus, from what I found at NixOS[0][1], it's a accountsservice
bug. I'll send a bug report. In the meantime, it doesn't appear to
affect LightDM too much so it might be ok...?

> After digging in the new service file I keep wondering if it's the right
> way to go about implementing it. I tried to set a simple setting
> for `lightdm-gtk-greeter` and I ended up with the following which 
> doesn't
> look intuitive:
>
> (service lightdm-service-type
>           (lightdm-configuration
>            (greeter-configuration-file
>             (lightdm-gtk-greeter-configuration-file
>              (lightdm-gtk-greeter-configuration
>               (extra-config "hide-user-image=true"))))))

Yeah, far from elegant. Did it that way in case someone wanted to
provide its own file but dropping
lightdm-gtk-greeter-configuration-file gives one level less of nesting.

> Furthermore `lightdm-service-type` only set a single seat while lightdm 
> can
> have many of them. So maybe there should be a lightdm-seat` record used 
> as
> a list of seats in `lightdm-service-type`. Each greater will be able to
> expand `lightdm-service-type` by appending a seat to it. Then the
> configuration could look like this:
>
> (service lightdm-service-type)
> (service lightdm-gtk-greeter-service-type
>           (lightdm-gtk-greeter-configuration
>            (assets (list guix-artwork))
>            (theme-name "Guix")
>            (extra-config "hide-user-image=true")))

I didn't know one could use a different greeter for each seat. Indeed,
it would be nice to have that feature!
The only thing that bothers me is that you don't get a working
default LightDM service by default. I feel that just adding (service
lightdm-service-type) to your configuration should get you a fully
working LightDM, specially for newcomers. Here one would lack a greeter.
:/

I believe there is a solution that would give us the best of both
worlds. If someone has a clue, an idea or even a patch, please share it!
:)

Also, merging as is and improving the service later is possible too.

>
> Using this approch would also avoid populating “/etc”, at least for
> `lightdm-grk-greeter`, since each greeter would be defined as a service 
> and
> could expand “/etc” if it really needs it. For `lightdm-gtk-greeter`
> specifically avoiding putting config in “/etc/” can be done by compiling 
> it
> with `-DCONFIG_FILE` pointing to `/run/current-system` And `lightdm` can 
> be
> started with `--config`.

I will make a patch to use --config for lightdm.
For lightdm-gtk-greeter, how would one put the config file in
"/run/current-system"? Do we need to make a package out of it?

> Here is an example in how to make a conjuration file procedure more
> readable while keeping under the line length limit by using 
> `match-record`:
>
> (define (lightdm-gtk-greeter-configuration-file config)
>    (match-record config <lightdm-gtk-greeter-configuration>
>      (theme-name icon-theme-name cursor-theme-name cursor-size background
>                  extra-config)
>     (mixed-text-file "lightdm-gtk-greeter.conf" "
> [greeter]
> theme-name = "           theme-name                   "
> icon-theme-name = "      icon-theme-name              "
> cursor-theme-name = "    cursor-theme-name            "
> cursor-theme-size = "    (number->string cursor-size) "
> background = "           background                   "
> " extra-config                                        "
> ")))

Way better! Preparing a patch for that.

> BTW the default background could use one from Guix artwork repo like
> “(file-append %artwork-repository "/grub/GuixSD-fully-black-16-9.svg")”.

Yeap!

> WDYT? I may be completely off on the `lightdm-seat` part.
>
> [0]: 
> https://github.com/NixOS/nixpkgs/blob/release-19.09/nixos/modules/services/x11/display-managers/lightdm-greeters/gtk.nix#L18
>
> Cheers,
> - Brice

Have a nice day!

L  p R n  d n

Message #47 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n <guix <at> lprndn.info>
To: Brice Waegeneire <brice <at> waegenei.re>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Tue, 14 Apr 2020 15:17:09 +0200

Hey!

Le 14.04.2020 11:38, L  p R n  d n a écrit :
> Hello,
> 
> Thanks again for the feedbacks.
> 
> Brice Waegeneire <brice <at> waegenei.re> writes:
> 
> [...]
>> There is an error on vt1 at startup about some dbus stuff related to
>> “accountservice”. The cursor theme isn't set as well as the icon 
>> theme,
>> it
>> seems; it may come from some missing environment variable as NixOS set 
>> a
>> few of them in their service[0].
> 
> For the cursor, setting "XCURSOR_PATH" seems to solve the problem.
> Preparing a patch.
> 
> As for dbus, from what I found at NixOS[0][1], it's a accountsservice
> bug. I'll send a bug report. In the meantime, it doesn't appear to
> affect LightDM too much so it might be ok...?

Better with actual links:

[0]: https://github.com/NixOS/nixpkgs/pull/45107
[1]: https://github.com/NixOS/nixpkgs/issues/72396

Have a nice day,

L  p R n  d n

Message #50 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Wed, 22 Apr 2020 17:26:04 +0200

[Message part 1 (text/plain, inline)]

Hello,

Here is the new set of patches with quite a few modifications for the
service, everything rebased on 1.1.0.
After a discussion with bricewge on irc, a new design has been adopted
allowing use of multiple seats.
To use the service, you can instantiate a lightdm-service-type, a
lightdm-gtk-greeter-service-type or both. The service should always find
a way to start a working instance of LightDM. :) 
A non exhaustive list of changes that might need further review:

* lightdm-gtk-greeter has its own service extending lightdm-service and
  others.
  
* Seats configuration use now the lightdm-seat-record-type and can be
  defined both in the lightdm-service and lightdm-gtk-greeter-service.
  The greeter now extends the LightDM's service by providing a list of
  seats.

* The `compose` and `extend` field of the lightdm-service-type have seen
  work for this purpose while keeping compatibility with
  `set-xorg-configuration`.

* extra-config fields are list of strings to avoid weird indentation in
  the user's config.

* Fixed customization of lightdm-gtk-greeter's cursor.

* Added some fields to deal with accessibility for
  lightdm-gtk-greeter-configuration.

* Takes default background from guix-artwork.

Also a review of PAM services might be nice as I'm not versed in security.

However, I didn't get rid of etc-service-type's extension as LightDM's
seems to ignore `sessions-directory` when configuration is passed
through `--config`. Patches to fix that are welcome but can wait a
future patch submission, I think.

Otherwise, tested in a WM: default configurations, autologin, sway,
changing greeter appearance and everything worked fine. For passwordless
login, had to actually delete user's password manually to make it work.
I don't know if it's expected.

Have a nice day and good review :)


L  p R n  d n

[0001-gnu-lightdm-Update-1.30.0.patch (text/x-patch, attachment)]

[0002-gnu-lightdm-Add-vala-bindings.patch (text/x-patch, attachment)]

[0003-gnu-lightdm-Disable-python-tests-only.patch (text/x-patch, attachment)]

[0004-gnu-lightdm-gtk-greeter-Fix-at-spi-runtime-dependenc.patch (text/x-patch, attachment)]

[0005-gnu-lightdm-gtk-greeter-Fix-.desktop-file.patch (text/x-patch, attachment)]

[0006-gnu-lightdm-gtk-greeter-Wrap-binary.patch (text/x-patch, attachment)]

[0007-gnu-lightdm-Build-accountsservice-files.patch (text/x-patch, attachment)]

[0008-gnu-lightdm-gtk-greeter-Fix-some-warnings.patch (text/x-patch, attachment)]

[0009-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

[0010-gnu-lightdm-gtk-greeter-Set-XCURSOR_PATH-in-wrapper.patch (text/x-patch, attachment)]

Message #53 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Wed, 06 May 2020 16:05:05 +0200

[Message part 1 (text/plain, inline)]

Hello,

New set of patches with some modifications according to the feedbacks
from rekado.

One notable change is that all tests are now enabled for LightDM's
package. The package builds but there might be some non deterministic
tests failures sometimes (not necessarily those that have been re-enabled). 

Have a nice day,

L  p R n  d n

[0001-gnu-lightdm-Update-1.30.0.patch (text/x-patch, attachment)]

[0002-gnu-lightdm-Add-vala-bindings.patch (text/x-patch, attachment)]

[0003-gnu-lightdm-gtk-greeter-Fix-at-spi-runtime-dependenc.patch (text/x-patch, attachment)]

[0004-gnu-lightdm-gtk-greeter-Fix-.desktop-file.patch (text/x-patch, attachment)]

[0005-gnu-lightdm-gtk-greeter-Wrap-binary.patch (text/x-patch, attachment)]

[0006-gnu-lightdm-Build-accountsservice-files.patch (text/x-patch, attachment)]

[0007-gnu-lightdm-gtk-greeter-Disable-indicator-services.patch (text/x-patch, attachment)]

[0008-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

[0009-gnu-lightdm-gtk-greeter-Set-XCURSOR_PATH-in-wrapper.patch (text/x-patch, attachment)]

Message #56 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: L p R n d n <guix <at> lprndn.info>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Sat, 09 May 2020 00:18:14 +0200

[Message part 1 (text/plain, inline)]

I have applied all patches locally, pushed some of them to the master
branch already, and also made these local changes:

[lightdm.diff (text/x-patch, inline)]

diff --git a/doc/guix.texi b/doc/guix.texi
index 14a42e7070..d1f6ed6685 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -80,6 +80,7 @@ Copyright @copyright{} 2020 Brice Waegeneire@*
 Copyright @copyright{} 2020 R Veera Kumar@*
 Copyright @copyright{} 2020 Pierre Langlois@*
 Copyright @copyright{} 2020 pinoaffe@*
+Copyright @copyright{} 2020 L  p R n  d n@*
 
 Permission is granted to copy, distribute and/or modify this document
 under the terms of the GNU Free Documentation License, Version 1.3 or
@@ -14933,9 +14934,9 @@ auto-login session.
 
 @cindex LightDM, login manager
 @defvr {Scheme Variable} lightdm-service-type
-Service type for the LightDM graphical login manager.
-It uses the @code{lightdm-gtk-greeter} as default greeter.
-See @code{lightdm-configuration} below for configuration and greeters'
+Service type for the LightDM graphical login manager.  It uses the
+@code{lightdm-gtk-greeter} as default greeter.  See
+@code{lightdm-configuration} below for configuration and greeters'
 services for their specific configuration.
 @end defvr
 
@@ -14950,22 +14951,22 @@ The LightDM package to use.
 Whether to allow logins with empty passwords.
 
 @item @code{xorg-configuration} (default: @code{(xorg-configuration)})
-Default configuration of the Xorg graphical server. This configuration
+Default configuration of the Xorg graphical server.  This configuration
 will be used for all seats unless explicitly defined.
 
-@item @code{sessions-directory} (default:"/run/current-system/profile/share/xsessions:/run/current-system/profile/share/wayland-sessions")
+@item @code{sessions-directories} (default: @code{'("/run/current-system/profile/share/xsessions" "/run/current-system/profile/share/wayland-sessions")})
 Directories where LightDM will search for sessions' @code{.desktop} files.
 
-@item @code{remote-sessions-directory} (default:"/run/current-system/profile/share/remote-session")
+@item @code{remote-sessions-directories} (default: @code{'("/run/current-system/profile/share/remote-session")})
 Directories where LightDM will search for remote sessions'
 @code{.desktop} files.
 
 @item @code{seats} (default: @code{'()})
-A list of @code{lightdm-seat-configuration} records (see below)
-to include in configuration. Note that needed additional packages or
-configuration will need to be done manually. Thus, we recommend using a
-greeter service for defining seats. If none are provided here or by a greeter,
-a fallback one is added.
+A list of @code{lightdm-seat-configuration} records (see below) to
+include in configuration.  Note that needed additional packages or
+configuration will need to be done manually.  Thus, we recommend using a
+greeter service for defining seats.  If none are provided here or by a
+greeter, a fallback one is added.
 
 @item @code{extra-config} (default: @code{'()})
 A list of strings each describing a custom setting to append to the LightDM
@@ -14981,8 +14982,8 @@ Record representing a seat configuration for LightDM.
 @item @code{name-glob} (default: @code{"*"})
 Seat configuration is matched to all seats matching the name glob.
 
-@item @code{type} (default: @code{"local"})
-Type of seat. @code{"local"} or @code{"xremote"}.
+@item @code{type} (default: @code{'local})
+Type of seat.  @code{'local} or @code{'xremote}.
 
 @item @code{xorg-configuration} (default: @code{#f})
 Configuration of the Xorg graphical server.
@@ -14998,9 +14999,9 @@ The name of the default @code{.desktop} file describing a session.
 Will be used for @code{user-session} and @code{autologin-session} if necessary.
 
 @item @code{autologin-user} (default: "")
-If @code{autologin-user} is set, LightDM logs in directly
-as @code{autologin-user} to the session defined in
-@code{default-user-session}. This user should be part of the
+If @code{autologin-user} is set, LightDM logs in directly as
+@code{autologin-user} to the session defined in
+@code{default-user-session}.  This user should be part of the
 @code{autologin} group.
 
 @item @code{extra-config} (default: @code{'()})
@@ -15043,7 +15044,7 @@ The size of the cursor.
 Path to the background image to be used.
 
 @item @code{a11y-state} (default: "contrast; font; keyboard; reader")
-String describing states of accessibility features. @code{"name"} saves state
+String describing states of accessibility features.  @code{"name"} saves state
 on exit, @code{"-name"} disables at start and @code{"+name"} enables it.
 
 @item @code{reader} (default: "")
@@ -15051,8 +15052,8 @@ Command to launch screen reader.
 
 @item @code{seats} (default: @code{'()})
 List of @code{lightdm-seat-configuration} records (see above) to add to
-lightdm.conf through extension. @code{greeter-session} fields
-will be forced to @code{"lightdm-gtk-greeter"}
+@file{lightdm.conf} through extension.  @code{greeter-session} fields
+are forced to @code{"lightdm-gtk-greeter"}.
 
 @item @code{extra-config} (default: @code{'()})
 A list of string each describing a custom setting to append to the greeter
diff --git a/gnu/services/lightdm.scm b/gnu/services/lightdm.scm
index fa5330aade..8b0c1fcebd 100644
--- a/gnu/services/lightdm.scm
+++ b/gnu/services/lightdm.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2019,2020 L  p R n  d n   <guix <at> lprndn.info>
+;;; Copyright © 2019, 2020 L  p R n  d n   <guix <at> lprndn.info>
+;;; Copyright © 2020 Ricardo Wurmus <rekado <at> elephly.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -60,7 +61,7 @@
   (name-glob lightdm-seat-configuration-name-glob
              (default "*"))
   (type lightdm-seat-configuration-type
-        (default "local"))
+        (default 'local))
   (xorg-configuration lightdm-seat-configuration-xorg-configuration
                       (default #f))
   (session-wrapper lightdm-seat-configuration-session-wrapper
@@ -74,9 +75,9 @@
   (extra-config lightdm-seat-configuration-extra-config
                 (default '())))
 
-
 (define (lightdm-seat-configuration->list seat default-xorg-configuration)
-  "Given a seat, outputs a list to be used by mixed-text-file through `apply."
+  "Given a seat, outputs a list of configuration file chunks to be passed as
+arguments to mixed-text-file."
   (match-record seat <lightdm-seat-configuration>
                 (name-glob
                  type xorg-configuration session-wrapper
@@ -84,7 +85,7 @@
                  autologin-user extra-config)
                 (list "
   [Seat:"               name-glob                              "]
-  type = "              type
+  type = "              (symbol->string type)
   ;; If no xorg-configuration is set by the seat use the one provided
   ;; by the lightdm service
   "
@@ -114,15 +115,15 @@
            (default lightdm))
   (allow-empty-passwords? lightdm-configuration-allow-empty-passwords?
                           (default #f))
-  (sessions-directory
-   lightdm-configuration-sessions-directory
-   (default
-     "/run/current-system/profile/share/xsessions:/run/current-system/profile/share/wayland-sessions"))
+  (sessions-directories
+   lightdm-configuration-sessions-directories
+   (default '("/run/current-system/profile/share/xsessions"
+              "/run/current-system/profile/share/wayland-sessions")))
   (greeters-directory lightdm-configuration-greeters-directory
                       (default "/run/current-system/profile/share/xgreeters"))
-  (remote-sessions-directory lightdm-configuration-remote-sessions-directory
-                             (default
-                               "/run/current-system/profile/share/remote-sessions"))
+  (remote-sessions-directories
+   lightdm-configuration-remote-sessions-directories
+   (default '("/run/current-system/profile/share/remote-sessions")))
   ;; Having a xorg-configuration field here allows us
   ;; to benefit from set-xorg-configuration.
   (xorg-configuration lightdm-configuration-xorg-configuration
@@ -135,25 +136,27 @@
 (define (lightdm-configuration-file config)
   (match-record config <lightdm-configuration>
                 (allow-empty-passwords?
-                 sessions-directory greeters-directory
-                 remote-sessions-directory xorg-configuration
+                 sessions-directories greeters-directory
+                 remote-sessions-directories xorg-configuration
                  seats extra-config)
-                ;; Little trick to allow unquote-splicing of seats
-                (apply mixed-text-file `("lightdm.conf" "
+                (apply mixed-text-file "lightdm.conf"
+                       `("\
 [LightDM]
 greeter-user = lightdm
 greeters-directory = " ,greeters-directory "
-sessions-directory = " ,sessions-directory "
-remote-sessions-directory = " ,remote-sessions-directory "
+sessions-directory = " ,(string-join sessions-directories ":") "
+remote-sessions-directory = " ,(string-join remote-sessions-directories ":") "
 
 #Seats
- " ,@(if (null? seats)
-         (lightdm-seat-configuration->list (lightdm-seat-configuration)
-                                           xorg-configuration)
-         (concatenate
-          (map (lambda (seat)
-                 (lightdm-seat-configuration->list seat xorg-configuration))
-               seats))) "
+"
+,@(if (null? seats)
+      (lightdm-seat-configuration->list (lightdm-seat-configuration)
+                                        xorg-configuration)
+      (concatenate
+       (map (lambda (seat)
+              (lightdm-seat-configuration->list seat xorg-configuration))
+            seats)))
+"
 #Extra config
 " ,(string-join extra-config "\n")))))
 
@@ -337,8 +340,8 @@ remote-sessions-directory = " ,remote-sessions-directory "
                            (seats (append (assoc-ref extensions "seats")
                                           (lightdm-configuration-seats config))))))
                 (default-value (lightdm-configuration))
-                (description "Return a service that spawns the
- LightDM graphical login manager.")))
+                (description "Return a service that spawns the LightDM
+graphical login manager.")))
 
 ;; GREETERS
 
@@ -418,5 +421,5 @@ a11y-states = "         a11y-states                        "
                                      lightdm-gtk-greeter-profile-service)))
                 (default-value (lightdm-gtk-greeter-configuration))
                 (description
-                 "Set-up lightdm-gtk-greeter as well
-as its configuration file and extends LightDM with its seats.")))
+                 "Set-up lightdm-gtk-greeter as well as its configuration file
+and extend LightDM with its seats.")))

[Message part 3 (text/plain, inline)]

What do you think about these changes?  I felt that a list of
directories should be expressed as a list and not a colon-separated
string.  I realize that this clashes with the lightdm configuration
file, which speaks of “directory” even though it accepts a
colon-separated list of directories.

If that’s fine I’ll fold them into your patch that adds the service.

I built a VM and noticed that all icons are missing.  Should the service
arrange for a certain fallback icon theme to be installed?

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?

--
Ricardo

Message #59 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Sat, 09 May 2020 17:09:50 +0200

[Message part 1 (text/plain, inline)]

Hello,


Ricardo Wurmus <rekado <at> elephly.net> writes:

> I have applied all patches locally, pushed some of them to the master
> branch already, and also made these local changes:

Thanks for the review!

[...]
>  
>  @item @code{autologin-user} (default: "")
> -If @code{autologin-user} is set, LightDM logs in directly
> -as @code{autologin-user} to the session defined in
> -@code{default-user-session}. This user should be part of the
> +If @code{autologin-user} is set, LightDM logs in directly as
> +@code{autologin-user} to the session defined in
> +@code{default-user-session}.  This user should be part of the
>  @code{autologin} group.

My bad but here, the `autologin group thing is not applicable in
Guix at least for now. + adding a user to this group outputs an error
So I tried to make a quick fix of the documentation with this patch:

[no-autologin.diff (text/x-patch, inline)]

diff --git a/doc/guix.texi b/doc/guix.texi
index 54eba225d3..3dd5fe216a 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -14792,10 +14792,9 @@ The name of the default @code{.desktop} file describing a session.
 Will be used for @code{user-session} and @code{autologin-session} if necessary.
 
 @item @code{autologin-user} (default: "")
-If @code{autologin-user} is set, LightDM logs in directly
-as @code{autologin-user} to the session defined in
-@code{default-user-session}. This user should be part of the
-@code{autologin} group.
+If @code{autologin-user} is set, LightDM logs in directly as
+@code{autologin-user} to the session defined in
+@code{default-user-session}.
 
 @item @code{extra-config} (default: @code{'()})
 A list of strings each describing a custom setting to append to the seat

[Message part 3 (text/plain, inline)]

However it might be interesting to set this up in Guix as it seems to be
used in other linux distribution and looks like a relatively good security
feature. I'm not versed in security but we would at least need to create
this group and modify the pam services. Should I open an issue for that?

[...]

>
> What do you think about these changes?  I felt that a list of
> directories should be expressed as a list and not a colon-separated
> string.  I realize that this clashes with the lightdm configuration
> file, which speaks of “directory” even though it accepts a
> colon-separated list of directories.

Everything is looking fine! And the directories as lists is indeed way better.

> If that’s fine I’ll fold them into your patch that adds the service.
>
> 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. 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. The documentation might also be lacking
here. So adding a little comment in the lightdm-service description
might also be enough. What do you think?

> 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.

> --
> Ricardo

Have a nice day,

L  p R n  d n   

Message #62 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: L  p R n  d n <guix <at> lprndn.info>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Sun, 10 May 2020 21:21:08 +0200

L p R n d n <guix <at> lprndn.info> 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.

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.

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.

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 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.

--
Ricardo

Message #65 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Mon, 11 May 2020 12:14:25 +0200

[Message part 1 (text/plain, inline)]

Hello,

Ricardo Wurmus <rekado <at> elephly.net> writes:

> L p R n d n <guix <at> lprndn.info> 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.

[add-default-assets.diff (text/x-patch, inline)]

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

[Message part 3 (text/plain, inline)]

>>> 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

Message #68 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Tue, 12 May 2020 11:59:14 +0200

[Message part 1 (text/plain, inline)]

Hello,

Little from my side, I forgot to add the polkit extension of the lightdm
service so here is a patch.

Have a nice day,

L  p R n  d n

[0010-services-lightdm-Extend-polkit-service.patch (text/x-patch, attachment)]

Message #71 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: L  p R n  d n <guix <at> lprndn.info>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Wed, 20 May 2020 22:51:21 +0200

Hey,

I’m very sorry for the delay.

What took me so long is that I’m conflicted about how to move forward.
On one hand I really don’t want to delay this.  I think your patches are
a great and important addition to Guix.  On the other hand I feel that
the relationship between these new components isn’t quite right.

It still doesn’t feel quite right to me that there’s a
lightdm-service-type and an independent
lightdm-gtk-greeter-service-type.  I know that there can be any number
of greeters, but only one will be used with lightdm-service-type
dependent on the string value of greeter-session.  This leads to
potential misconfiguration as we don’t (and can’t) validate this string.

It also feels wrong to me to have a global directory as the only
location for greeter desktop files, which means that all greeters must
be installed globally.

What I envision is something like this: we only have a single
lightdm-service-type and it has a field “greeters”, which by default is
a list of just one item: a <greeter> record containing the
lightdm-gtk-greeter and its configuration.

Other greeters could be added; they would all be record values of type
<greeter> and come with their own extensions of the
ligthdm-service-type.

The lightdm-service-type would go through each of the greeters in the
list and apply their specified extensions to itself.

The reason why I haven’t implemented this yet is because a) I don’t want
to break what already works with your patches and b) I don’t know if
that’s ultimately a clearer implementation.

I feel that this would be a more intuitive configuration and result in
clearer relationships between the display manager and its swappable
components.  It would also allow for better defaults (so less
configuration needed) and avoid the problem of stringy types that are
easy to get wrong.

Maybe we are already really close to this solution, though: maybe the
proposed “greeter” field could simply accept service types like the
lightdm-gtk-greeter-service-type you already defined.

I’m going to play with this a little bit more, but if this doesn’t lead
anywhere I’ll merge the current version.

My apologies for delaying this!

-- 
Ricardo

Message #74 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: brice <at> waegenei.re, 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Thu, 21 May 2020 10:28:51 +0200

Hello,

Ricardo Wurmus <rekado <at> elephly.net> writes:

> Hey,
>
> I’m very sorry for the delay.

Again, there's no hurry. ;)

> What took me so long is that I’m conflicted about how to move forward.
> On one hand I really don’t want to delay this.  I think your patches are
> a great and important addition to Guix.  On the other hand I feel that
> the relationship between these new components isn’t quite right.
>
> It still doesn’t feel quite right to me that there’s a
> lightdm-service-type and an independent
> lightdm-gtk-greeter-service-type.  I know that there can be any number
> of greeters, but only one will be used with lightdm-service-type
> dependent on the string value of greeter-session.  This leads to
> potential misconfiguration as we don’t (and can’t) validate this string.

Just to clarify, as per my understanding, there can be multiple
`greeter-session fields defined. It's not a global value but a per seat
one. Each seat should be able to use a different greeter, I
think. Personally, I have a very standard use whith only one seat so
there are no questions in that case. However there might be use-cases
where it's needed. I CC bricewge, they might be more knowledgeable on
this issue.

> It also feels wrong to me to have a global directory as the only
> location for greeter desktop files, which means that all greeters must
> be installed globally.

Isn't using packages as inputs of `greeter-session solving this issue?
We can collect them from seats and string-join them into the
`greeter-directory field.

> What I envision is something like this: we only have a single
> lightdm-service-type and it has a field “greeters”, which by default is
> a list of just one item: a <greeter> record containing the
> lightdm-gtk-greeter and its configuration.
>
> Other greeters could be added; they would all be record values of type
> <greeter> and come with their own extensions of the
> ligthdm-service-type.
>
> The lightdm-service-type would go through each of the greeters in the
> list and apply their specified extensions to itself.

If I understand correctly, the main difference would be that the
greeters would be defined from within the lightdm-service (as a list of records?), right?
The current implementation was chosen to avoid too much field nesting
but I don't mind.
Also, you can have a look at the previous implementation (see
mail from 19th of March). It lacks seats and some featurse but it looks a
little closer to what you're describing. It might give some ideas.

> The reason why I haven’t implemented this yet is because a) I don’t want
> to break what already works with your patches and b) I don’t know if
> that’s ultimately a clearer implementation.
>
> I feel that this would be a more intuitive configuration and result in
> clearer relationships between the display manager and its swappable
> components.  It would also allow for better defaults (so less
> configuration needed) and avoid the problem of stringy types that are
> easy to get wrong.
>
> Maybe we are already really close to this solution, though: maybe the
> proposed “greeter” field could simply accept service types like the
> lightdm-gtk-greeter-service-type you already defined.

We're close. :)
Just curious here, if we use a list of services (for example) as input of
the greeters field, how do we take care of it? Can we "merge" the
different services into the lightdm one? If it's possible, this might be
a good solution.

> I’m going to play with this a little bit more, but if this doesn’t lead
> anywhere I’ll merge the current version.
>
> My apologies for delaying this!

Everything is going a lot faster than it was a few months ago so it's
already fine.

Have a nice day,

L  p R n  d n

Message #77 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: L  p R n  d n <guix <at> lprndn.info>
Cc: brice <at> waegenei.re, 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Thu, 21 May 2020 11:23:43 +0200

L p R n d n <guix <at> lprndn.info> writes:

> Hello,
>
> Ricardo Wurmus <rekado <at> elephly.net> writes:
>
>> Hey,
>>
>> I’m very sorry for the delay.
>
> Again, there's no hurry. ;)
>
>> What took me so long is that I’m conflicted about how to move forward.
>> On one hand I really don’t want to delay this.  I think your patches are
>> a great and important addition to Guix.  On the other hand I feel that
>> the relationship between these new components isn’t quite right.
>>
>> It still doesn’t feel quite right to me that there’s a
>> lightdm-service-type and an independent
>> lightdm-gtk-greeter-service-type.  I know that there can be any number
>> of greeters, but only one will be used with lightdm-service-type
>> dependent on the string value of greeter-session.  This leads to
>> potential misconfiguration as we don’t (and can’t) validate this string.
>
> Just to clarify, as per my understanding, there can be multiple
> `greeter-session fields defined. It's not a global value but a per seat
> one. Each seat should be able to use a different greeter, I
> think. Personally, I have a very standard use whith only one seat so
> there are no questions in that case. However there might be use-cases
> where it's needed. I CC bricewge, they might be more knowledgeable on
> this issue.

Right, I realized this after composing my message.  However, currently
the lightdm-gtk-greeter-service-type inherits all the seats and then
overrides the greeter-session value for each of them, which seems rather
rude.  So maybe it is wrong to let greeters do that at all.

I wondered why there’s a service type for the greeter at all, so I
looked at the service extensions it provides:

* lightdm-service-type: only used to override greeter-session in all
  defined seats, which seems like an anti-feature.  If other greeters
  do the same, then effectively there can only be one greeter for all
  seats, and that would be wrong.  So seat configuration really should
  remain in lightdm-service-type and not be an extension.

* etc-service-type: that’s to provide the greeter’s global configuration
  file.  Ideally, we would not need to use a global configuration file.
  It looks like lightdm-gtk-greeter respects the XDG_CONFIG_DIRS
  variable, so we should be able to generate its configuration file in
  an arbitrary location and then add it to XDG_CONFIG_DIRS in the
  environment of lightdm itself.

* profile-service-type: that’s to install lightdm-gtk-greeter and its
  assets into the system profile.  Again, that’s something we should aim
  to avoid.  It seems that we can avoid it with the use of environment
  variables in the lightdm shepherd service.

If we can avoid all three extensions then we don’t need a
lightdm-gtk-greeter-service-type at all.  If we don’t need a service we
can specify greeters as record type values with a name and configuration
file generator.

-- 
Ricardo

Message #80 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: brice <at> waegenei.re, 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Mon, 08 Jun 2020 17:35:14 +0200

Hello,

I spent some time thinking about the lightdm service and what are our
possibilities so here are my thoughts and conclusions.

(Here, I'll only describe relations between seats, greeters and the lightdm
service as it's our main source of problems)

So if we get rid of the greeter's services, we can have:

1:
(service lightd-service-type
    (lightdm-configuration
        (greeters
            (list
                (lightdm-gtk-greeter-configuration
                  (seats
                      (list
                          (lightdm-seat-configuration ...))))))))

Here seats are defined by greeters. This way the user doesn't need to
fill `greeter-session field as we can do it automatically. But there's a lot of nesting
(and two lists.) + How do we define autologin?

2:
(service lightd-service-type
    (lightdm-configuration
        (seats
            (list
                (lightdm-seat-configuration
                    (greeter-session
                        (lightdm-gtk-greeter-configuration ...)))))))

Defining greeters inside seats allows in the `greeter-session field make
it a little simpler. However, we would get errors or conflicts if a user
define two different configurations of the same greeter for two
different seats. The thing is that we can only have one configuration
per greeter as it will always look for a hardcoded file in /etc/ (worst
case) or a file we hardcoded at build time (best case). :/

3:
(service lightd-service-type
    (lightdm-configuration
        (seats
            (list
                (lightdm-seat-configuration
                    (greeter-session 'lightdm-gtk-greeter))))
        (greeters
            (list
                (lightdm-gtk-greeter-configuration
                  )))))

We can have separate fields for greeters and seats. The user will have
to define `greeter-session by himself. And what happen if they define
multiple occurences of one greeter's configuration?


So my conclusion is that the current implementation using a different service for lightdm and its
greeters is probably not so bad as it prevents most of these
issues. Unless someone has an even better idea, indeed. :D

Ricardo Wurmus <rekado <at> elephly.net> writes:

> L p R n d n <guix <at> lprndn.info> writes:
>
>> Hello,
>>
>> Ricardo Wurmus <rekado <at> elephly.net> writes:
[...]
> Right, I realized this after composing my message.  However, currently
> the lightdm-gtk-greeter-service-type inherits all the seats and then
> overrides the greeter-session value for each of them, which seems rather
> rude.  So maybe it is wrong to let greeters do that at all.
>
> I wondered why there’s a service type for the greeter at all, so I
> looked at the service extensions it provides:
>
> * lightdm-service-type: only used to override greeter-session in all
>   defined seats, which seems like an anti-feature.  If other greeters
>   do the same, then effectively there can only be one greeter for all
>   seats, and that would be wrong.  So seat configuration really should
>   remain in lightdm-service-type and not be an extension.

As disussed on IRC, a greeter service only overwrites its own
`greeter-session field. But we could get rid of the `greeter-session
field altogether as it's probably not necessary if they're filled by the
greeters' service or record (depending of what we choose).

> * etc-service-type: that’s to provide the greeter’s global configuration
>   file.  Ideally, we would not need to use a global configuration file.
>   It looks like lightdm-gtk-greeter respects the XDG_CONFIG_DIRS
>   variable, so we should be able to generate its configuration file in
>   an arbitrary location and then add it to XDG_CONFIG_DIRS in the
>   environment of lightdm itself.

I didn't find any informations about lightdm-gtk-greeter using
XDG_CONFIG_DIRS. Could you provide further explaination as it could
impact what I wrote earlier.

> * profile-service-type: that’s to install lightdm-gtk-greeter and its
>   assets into the system profile.  Again, that’s something we should aim
>   to avoid.  It seems that we can avoid it with the use of environment
>   variables in the lightdm shepherd service.

Yeah ;)

> If we can avoid all three extensions then we don’t need a
> lightdm-gtk-greeter-service-type at all.  If we don’t need a service we
> can specify greeters as record type values with a name and configuration
> file generator.

Hope it's clear, I'm really just dumping my thoughts... :)
Please tell me what you think.

Have a nice day,

L  p R n  d n

Message #83 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: L  p R n  d n    <guix <at> lprndn.info>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: brice <at> waegenei.re, 35305 <at> debbugs.gnu.org
Subject: Re: [bug#35305] LightDM service
Date: Fri, 19 Jun 2020 16:47:01 +0200

[Message part 1 (text/plain, inline)]

Hello,

Here I come again with a new attempt for the LightDM service.
This one is a little too complex to my taste but it succeeds IMHO at
dealing with most cases nicely. Also I didn't find any other occurence
of this in Guix, so it might just not fit in. It's a draft and it's
ugly, it probably needs some refactoring/renaming, maybe using methods?
or just alists?

In the meantime, the chosen design is to have the lightdm-service and
greeter services to extend another, private service (lightdm-aggregate)
that deals with mergin everything all configuration and extending the
needed services accordingly. This way, data can be shared between
lightdm's and greeters' configurations (here, greeters' desktop file
directories and a list of greeters needed by the seats definition)

It features:

* A user can define only the a lightdm-service or only a greeter service
  or both, he should always get a working LightDM. If a seats asks for a
  greeter which is not defined in the user config, the lightdm-aggregate
  service adds its service with default config.

* Seats are defined only in the lightdm service so, on one hand, the user needs to
  manually set the `greeter-session field but, on the other hand, we get
  a clear distinction between configurations.

* Too many (cond ...). There might be better solutions.


Please give me your opinion. I think I'll try one last design which will
be the complete opposite of this one. (lightdm-service deals with its
conf, greeters deal with theirs. The user deals with the rest. Also
(service lightdm-service-type) is not enough for a working
display-manager).

Have a nice day,

L  p R n  d n

[0001-services-Add-lightdm-service-type.patch (text/x-patch, attachment)]

Message #86 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: L p R n d n <guix <at> lprndn.info>
Cc: 35305 <at> debbugs.gnu.org
Subject: Re: bug#35305: [WIP] LightDM service
Date: Wed, 03 Aug 2022 22:19:18 -0400

Hi,

> Hello,

> New set of patches with some modifications according to the feedbacks
> from rekado.

> One notable change is that all tests are now enabled for LightDM's
> package. The package builds but there might be some non deterministic
> tests failures sometimes (not necessarily those that have been re-enabled). 

> Have a nice day,

> L  p R n  d n

> [2. text/x-patch; 0001-gnu-lightdm-Update-1.30.0.patch]...

> [3. text/x-patch; 0002-gnu-lightdm-Add-vala-bindings.patch]...

> [4. text/x-patch; 0003-gnu-lightdm-gtk-greeter-Fix-at-spi-runtime-dependenc.patch]...

> [5. text/x-patch; 0004-gnu-lightdm-gtk-greeter-Fix-.desktop-file.patch]...

> [6. text/x-patch; 0005-gnu-lightdm-gtk-greeter-Wrap-binary.patch]...

> [7. text/x-patch; 0006-gnu-lightdm-Build-accountsservice-files.patch]...

> [8. text/x-patch; 0007-gnu-lightdm-gtk-greeter-Disable-indicator-services.patch]...

> [9. text/x-patch; 0008-services-Add-lightdm-service-type.patch]...

> [10. text/x-patch; 0009-gnu-lightdm-gtk-greeter-Set-XCURSOR_PATH-in-wrapper.patch]...

All the above changes except for the service have now been merged into
master.  I'll now look at the service various versions.

Thank you!

Maxim

Message #89 received at 35305 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: L p R n d n <guix <at> lprndn.info>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, brice <at> waegenei.re,
 35305 <at> debbugs.gnu.org
Subject: Re: bug#35305: [WIP] LightDM service
Date: Thu, 04 Aug 2022 01:09:38 -0400

Hi,

L  p R n  d n    <guix <at> lprndn.info> writes:

> Hello,
>
> I spent some time thinking about the lightdm service and what are our
> possibilities so here are my thoughts and conclusions.
>
> (Here, I'll only describe relations between seats, greeters and the lightdm
> service as it's our main source of problems)
>
> So if we get rid of the greeter's services, we can have:
>
> 1:
> (service lightd-service-type
>     (lightdm-configuration
>         (greeters
>             (list
>                 (lightdm-gtk-greeter-configuration
>                   (seats
>                       (list
>                           (lightdm-seat-configuration ...))))))))
>
> Here seats are defined by greeters. This way the user doesn't need to
> fill `greeter-session field as we can do it automatically. But there's a lot of nesting
> (and two lists.) + How do we define autologin?
>
> 2:
> (service lightd-service-type
>     (lightdm-configuration
>         (seats
>             (list
>                 (lightdm-seat-configuration
>                     (greeter-session
>                         (lightdm-gtk-greeter-configuration ...)))))))
>
> Defining greeters inside seats allows in the `greeter-session field make
> it a little simpler. However, we would get errors or conflicts if a user
> define two different configurations of the same greeter for two
> different seats. The thing is that we can only have one configuration
> per greeter as it will always look for a hardcoded file in /etc/ (worst
> case) or a file we hardcoded at build time (best case). :/
>
> 3:
> (service lightd-service-type
>     (lightdm-configuration
>         (seats
>             (list
>                 (lightdm-seat-configuration
>                     (greeter-session 'lightdm-gtk-greeter))))
>         (greeters
>             (list
>                 (lightdm-gtk-greeter-configuration
>                   )))))
>
> We can have separate fields for greeters and seats. The user will have
> to define `greeter-session by himself. And what happen if they define
> multiple occurences of one greeter's configuration?

After reading more about lightdm (and there's not much to read about
it... [0]), I can better understand your points above, and I find #3
perhaps the most natural.  The negative points (leaving place for user
errors) can be mitigated by a validating the configuration (e.g. that
all the configuration types listed in greeters are different).

I'll try to adjust your code to use the above layout when I get a
chance.

Thanks,

Maxim

[0]  https://wiki.ubuntu.com/LightDM

Message #94 received at 35305-done <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: 35305-done <at> debbugs.gnu.org
Subject: [WIP] LightDM service
Date: Wed, 31 Aug 2022 09:13:03 +0200

A variation of this has been pushed to the master branch with commit
0ea62e84a787fe94cfeadf67ef27ea995a382b84.

-- 
Ricardo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.