GNU bug report logs - #75270
[PATCH 0/3] services: greetd: Improve greeter configurations.

Previous Next

Package: guix-patches;

Reported by: muradm <mail <at> muradm.net>

Date: Wed, 1 Jan 2025 22:49:02 UTC

Severity: normal

Tags: patch

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: muradm <mail <at> muradm.net>
Cc: ludo <at> gnu.org, 75270 <at> debbugs.gnu.org, pelzflorian <at> pelzflorian.de
Subject: Re: [bug#75270] [PATCH v4 1/3] services: greetd: Improve greeter
 configurations.
Date: Wed, 05 Feb 2025 14:38:22 +0900
Hi,

muradm <mail <at> muradm.net> writes:

[...]

>> OK; so the new version will need some fiddling from users to just
>> build
>> with their current config?  Or are these expected to be rare edge
>> cases?
>
> Problems may occur with complex setups, where commands provided by
> users
> are very different from "bash -l". Knowing in advance all alternatives
> is impossible. Everything sane or default, should work as is, showing
> the warnings on reconfigure.

Thanks for explaining.  That sounds reasonable to me.

[...]

>> See (info '(texinfo) @table):
>>
>>    Write the ‘@table’ command at the beginning of a line, after    a
>> blank
>>    line, and follow it on the same line with an argument that is
>> an
>>    'indicating' command, such as ‘@code’, ‘@samp’, ‘@var’,
>> ‘@option’, or
>>    ‘@kbd’ (*note Indicating::).  This command will be applied to
>> the text
>>    in the first column.  For example, ‘@table @code’ will cause
>> the text
>>    in the first column to be output as if it had been the
>> argument to a
>>    ‘@code’ command.
>>
>> I think the 'indicating' command argument to @table is required, so
>> there is no default value.
>
> I have to try, may be next time.
> You want me to update all tables in greetd service documentation?

Yes, that'd be best.  It can be done later in a different submission.

>>>>> -           (sleep 1) ;give seatd/logind some time to start up
>>>>
>>>> That's a suspicious line which already existed.  It looks fragile.
>>>> Is
>>>> it really necessary?
>>>
>>> Unfortunately, there is no good/easy way to conditionally depend
>>> on elogind or seatd. greetd-service-type and agreety greeter do not
>>> require
>>> seat, only sway based greeters may/will want it.
>>
>> I meant perhaps waiting 1 second here is no longer necessary?  1 s
>> is
>> not much at all.  Perhaps added during debug/development of the
>> service
>> and forgotten?  I'd trying taking it out and see.
>
> Unfortunately, if you take it out, you will end up with race condition
> when sometimes it works sometimes not. Technically, "sleep 1" may
> cause race as well, but for years I didn't have any issue with it.

OK.  What do other systems do?  Surely, there are better technical means
to achieve this than sleeping for one second?

> To try it, you have to configure seatd, greetd, and sway based
> greeter. Then just reboot/restart host until race.
>
> One possible is to provide additional greetd configuration that
> will expose the shepherd requirements. But I think it might
> will complicate configuration dramatically for end user.

Perhaps there could be a shepherd-requirements field attached to the
greeter configurations with a sane default value capturing the Shepherd
requirements, abstracting the complexity to most users while leaving it
configurable?

-- 
Thanks,
Maxim




This bug report was last modified 161 days ago.

Previous Next


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