[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54786: Installation tests are failing
From: |
Maxim Cournoyer |
Subject: |
bug#54786: Installation tests are failing |
Date: |
Tue, 24 May 2022 23:43:23 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux) |
Hi,
Ludovic Courtès <ludo@gnu.org> writes:
> Hi,
>
> Mathieu Othacehe <othacehe@gnu.org> skribis:
>
>> Thanks for the fix! The jami and jami-provisioning tests are also broken
>> because of what looks like to be the same issue:
>>
>> One does not simply initialize the client: Another daemon is detected
>> /gnu/store/01phrvxnxrg1q0gxa35g7f77q06crf6v-shepherd-marionette.scm:1:1718:
>> ERROR:
>> 1. &action-exception-error:
>> service: jami
>> action: start
>> key: match-error
>> args: ("match" "no matching pattern" #f)
>> Jami Daemon 11.0.0, by Savoir-faire Linux 2004-2019
>> https://jami.net/
>> [Video support enabled]
>> [Plugins support enabled]
>
> Yes, I noticed that, but I’m not sure how to apply a similar workaround.
I tried fixing that today, but so far I've only managed to understand
what seems to be going wrong, with this (not so great) workflow:
1. Add pk uses in the code.
2. $(./pre-inst-env guix system vm --no-graphic -e '(@@ (gnu tests
telephony) %jami-os)' --no-offload --no-substitutes) -m 512 -nic
user,model=virtio-net-pci,hostfwd=tcp::10022-:22
3. ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p
10022 root@localhost
and poke around with 'herd status', read /var/log/messages, experiment
with dbus-send, etc.
This allowed me to find out that (dbus-available-services) appears to be
broken. I'm not sure why the exceptions are reported so badly by
Shepherd (are exceptions raised with 'error' not handled by Shepherd or
something? -- the with-retries loop should end up printing the caught
exception arguments -- I would also have expected to see the backtrace
somewhere.
Anyway, connecting to another machine that is running the
jami-service-type still (hasn't been reconfigured in a while), I could
see:
--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> ,use (gnu build jami-service)
scheme@(guix-user)> (dbus-available-services)
;;; Failed to autoload fork+exec-command in (shepherd service):
;;; no code for module (fibers)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: fork+exec-command: unbound variable
--8<---------------cut here---------------end--------------->8---
Oh yes, so it now requires guile-fibers. After installing it:
--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> ,use (gnu build jami-service)
scheme@(guix-user)> (dbus-available-services)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
No scheduler current; call within run-fibers instead
--8<---------------cut here---------------end--------------->8---
So the users of fork+exec-command (a public API) needs to be adjusted.
I suspect that's the crux of the issue here. The rest (the jami tests
using Shepherd's start-service to check the service status and causing
multiple starts) should be easy to workaround.
To be continued...
Maxim