Hello Stefan,

Thank you very much for this work!

Stefan Stefanović <stefanx2ovic@gmail.com> writes:

> Hello,
> Ludo’.
>
> Thank you, for the response.
>
> Sorry for the verbose and long message,
> it is low priority, so read it only you have time. :)
>
>>> Stefan Stefanović <stefanx2ovic@gmail.com> skribis:
>>>
>>> All that remains is to figure out how to integrate this update to
>>> Guix, following the next release of elogind (v239.2).
>>>
>>> Any advice and suggestion is appreciated, since I am relatively new to
>>> Scheme and Guix.
>
>> We would squash this /run/systemd/elogind.pid patch with the one that
>> actually updates elogind and that’s it.
>
> Yes I can do that.
> But I was originally wondering about,
> should we change the Scheme symbolic-name,
> and should we keep the older elogind definition.
> This is in the context of the problematic
> in-place-update of elogind definition I described.
> I assume that we should fix this in-place-update.

Are you referring to the case of a stale /var/run/elogind.pid?  Or the
D-Bus versus Shepherd issue?

For the latter I think it may make sense to prevent D-Bus from starting
elogind.  For the former: /var/run should be automatically cleaned upon
booting, is this not the case?

>> If you could check on a system that uses ‘%desktop-services’ (and thus
>> elogind) that you can still log in, etc., that’d be great.  You can do
>> that in a VM with ‘guix system vm’.
>
> I tested elogind-next on my system (not in VM),
> using mingetty auto-login service and starting
> sway (Wayland compositor) with the
> dbus-launch wrapper.
> (Off topic: I plan to send patches for sway,
> when it releases its 1.0, it is in beta right now.)
> Status:
> New elogind works fine, using it daily.
> I have no problems, but I do not use the default:
> display-manager, session-manager and window-manager.
>
> I will try and test it in VM, but I need to make sure that
> all the packages that depend on elogind depend
> on elogind-next.
> This could be challenging. Not sure how to approach this.
> Maybe by using higher order procedure: package-input-rewriting.

It's probably easiest to do this from a git checkout of the Guix
repository and modify the "elogind" package directly.  Then you can
either `guix pull --url=./repo`, or use the "./pre-inst-env" script (see
<https://www.gnu.org/software/guix/manual/en/guix.html#Building-from-Git>).

>>> Issue: Replacing elogind package definition in place did not work for
>>> me the last time I tried it.  Problem is the guix commands were
>>> stuck/busy (not stuck building or anything like that, just stuck like
>>> "in an infinite loop") every time I tried to build elogind, with the
>>> newer package definition as replacement for the older one.
>
>> What did ‘guix build elogind’ print?
> Given elogind definition is replaced with the newer definition.
>
> When I run:
> $ guix build elogind
> Then I get:
> guix command hangs after printing:
> "Updating channel 'guix' from Git repository...".

I don't know why "guix build" would ever print "Updating channel ...",
but the hang sounds like a circular dependency issue.  Do you have the
in-place diff available?  It could be that some of the new dependencies
depend on elogind, directly or indirectly.

In that case we will have to investigate how to break the circular
dependency.  A typical solution is to add a "foo-sans-elogind" variant
which is used as the elogind input.