Hi, Ludovic Courtès <l...@gnu.org> writes:
> Hi, > > Mathieu Othacehe <othac...@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