GNU bug report logs - #54786
Installation tests are failing

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: othacehe <at> gnu.org, 54786 <at> debbugs.gnu.org
Subject: bug#54786: Installation tests are failing
Date: Thu, 02 Jun 2022 22:43:58 +0200

Howdy!

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

> I tried capturing the issue in the commit message, but I'll provide
> another more hands-on view: the Jami service was broken due to changes
> in Shepherd 0.9.0 that caused the blocking sleeps + concurrent
> make+forkexec-constructor/container and fork+exec-command combination
> used to not work anymore.

OK.  Thanks for sharing the strace log; at first sight I don’t see any
clear clue, but hey, maybe it’s fine to leave that as a mystery since
there’s another solution.

[...]

>> Longer-term I think this should go in Jami proper though.  It’s great
>> that Guix has an edge over the competition :-), but having to maintain
>> it is less nice.
>
> Perhaps with the Scheme bindings introduced by Olivier for the Jami
> tests (that work via an embedded libguile), it could be possible to add
> the ability to pass an init script to 'jamid' at launch time, which
> would automate importing the account.  Proper 'Scheme' bindings would be
> nice though, and I'd like to look into the feasibility to add these via
> Swig.  Food for thought.

Sounds fun.  (BTW, I’d recommend against SWIG: it’s not “pretty”, leaves
a lot of work to do, including wrapping the generated wrappers and
debugging memory management issue.  Using the FFI provides more
flexibility and is much more fun IMO.)

>> Also, in more concrete terms: one goal of the least-authority work at
>> <https://issues.guix.gnu.org/54997> is to remove
>> ‘make-forkexec-constructor/container’ and the whole (gnu build shepherd)
>> module.  Jami is one of its last remaining users (adjusting it felt like
>> beyond my abilities, precisely because it’s much more complex than the
>> other services I adjusted).
>>
>> Could you take a look at that eventually, once this patch has been
>> reviewed?
>
> I reviewed how that works, and it'd be easy; I just didn't see the
> incentive yet (there's no composition needed for the service, and it'd
> make the definition slightly less readable).  If you tell me
> mark+forkexec-constructor/container is going the way of the Dodo though,
> that's a good enough incentive :-).

Awesome.  :-)

Thanks for explaining!

Ludo’.

Previous Next

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