[Top][All Lists]

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

Re: [PATCH][WIP] Elogind update

From: Stefan Stefanović
Subject: Re: [PATCH][WIP] Elogind update
Date: Wed, 14 Nov 2018 14:39:47 +0100


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ć <address@hidden> 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/ 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.

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

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

In the same context, when I run:
$ guix build -S elogind
Then I get the modified source, without problems.

Given elogind definition is not replaced
and newer definition is added next to it.

When I run:
$ guix build elogind-next
Then I get:
The build result as expected.

I am going to do binary search (bisect) for this problem,
by replacing elogind with elogind-next, in order
to find out which use of elogind-next is problematic.

I will do that and report back.


reply via email to

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