bug#54786: Installation tests are failing

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>  gnu/build/dbus-service.scm | 212 ++++++++++++++++
>>  gnu/build/jami-service.scm | 390 +++++------------------------
>>  gnu/local.mk               |   1 +
>>  gnu/packages/glib.scm      |  19 +-
>>  gnu/services/telephony.scm | 500 +++++++++++++++++--------------------
>>  gnu/tests/telephony.scm    | 412 +++++++++++++++---------------
>>  6 files changed, 726 insertions(+), 808 deletions(-)
>>  create mode 100644 gnu/build/dbus-service.scm
>
> Before going further, I’d like to understand: this does more than just
> fix the Jami system tests, right?
>
> It would have been nice to have surgical changes to “just” fix the
> tests, along the lines of <https://issues.guix.gnu.org/54786#9>,
> possibly followed by a rework of the whole machinery, if that’s
> possible.

It's not really possible unfortunately, because the rework from talking
to the D-Bus API via the 'dbus-send' binary to using Guile AC/D-bus was
needed or at least simplified fixing the issues.  Going back trying to
make it work the way it was would be new work that'd end up being
scrapped anyway with a subsequent commit making use of the Guile D-Bus
library, so I'm not interested in pursuing it.

> Besides, I think we should talk to Jami upstream (which shouldn’t be too
> hard :-)).  It doesn’t seem reasonable to me to have 800+ lines of code
> in the distro to start one service.  Usually the ‘start’ and ‘stop’
> methods are between 2 and 10 lines of code.
>
> What do you think is missing upstream so that starting Jami is
> simpler?

1) Lack of D-Bus support in Shepherd to easily start D-Bus services.
The upstream systemd service definition for the Jami daemon (jamid) is
this:

--8<---------------cut here---------------start------------->8---
# net.jami.daemon.service
[D-BUS Service]
Name=cx.ring.Ring
Exec=@LIBDIR@/jamid
--8<---------------cut here---------------end--------------->8---

But that's nearly not where the complexity of our jami-service-type
lies.  Rather, it's in the following:

2) The lack of a way to declaratively configure Jami and the need to use
D-Bus API to issue commands to Jami non-interactively.  For example, to
have Jami import an account it's necessary to go via either

a) the GUI or
b) the D-Bus API

The Jami service in Guix makes use of b), which introduces the need for
some Scheme bindings wrapping the low-level D-Bus interface.  Perhaps
such bindings could live in Jami itself.

The second point (2) could be addressed upstream, but since it's a
rather niche use case (the common use case is simply running the client
GUI), is already achievable via D-Bus, and would probably require a
considerable amount of work in Jami itself, I think we can keep it as is
for now, as a Guix System exclusive feature ;-).  Note that even if Jami
could be configured via configuration files, we'd still want to be able
to communicate with it via D-Bus to maintain the possible actions
currently available in our Shepherd service (listing/enabling/disable
accounts, etc.), so it'd only really help to reduce the start slot, and
that's it.  We'd still need most of the D-Bus bindings, so it wouldn't
help that much anyway.

I hope that clarifies how our jami-service-type is both complex but also
unique.

Happy video-conferencing!

Maxim