Comment 2 for bug 2045997

I can confirm this failure with a local qemu autopkgtest server. From the following lines in the log:

.dbus-daemon[2104]: [session uid=1000 pid=2104] Activating service name='org.freedesktop.secrets' requested by ':1.1' (uid=1000 pid=2105 comm="python3.11 -m pytest tests" label="unconfined")
378s ** Message: 22:28:34.588: couldn't access control socket: /tmp/autopkgtest.SbzXU7/autopkgtest_tmp/vorta/run/keyring/control: No such file or directory
378s discover_other_daemon: 0dbus-daemon[2104]: [session uid=1000 pid=2104] Successfully activated service 'org.freedesktop.secrets'
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Activating service name='org.gnome.keyring.SystemPrompter' requested by ':1.2' (uid=1000 pid=2110 comm="/usr/bin/gnome-keyring-daemon --start --foreground" label="unconfined")
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Activating service name='org.a11y.Bus' requested by ':1.3' (uid=1000 pid=2117 comm="/usr/libexec/gcr-prompter" label="unconfined")
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Successfully activated service 'org.a11y.Bus'
378s dbus-daemon[2125]: Activating service name='org.a11y.atspi.Registry' requested by ':1.0' (uid=1000 pid=2117 comm="/usr/libexec/gcr-prompter" label="unconfined")
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Successfully activated service 'org.gnome.keyring.SystemPrompter'
378s dbus-daemon[2125]: Successfully activated service 'org.a11y.atspi.Registry'
378s SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry

my guess so far is that it's launching a new gnome-keyring-daemon in the test's dbus session and blocking the tests from continuing (--foreground instead of --daemonize).

This is sort of expected, since python-secretstorage now pulls in gnome-keyring on install where it hadn't before. Although I'm not exactly sure how this request takes over the pytest process.

I've yet to get gnome-keyring-daemon to start in the test's dbus session and not block the tests from running, which I think is the proper solution.

Otherwise, if the tests are valid without an external secret service provider (like gnome-keyring), then we should patch the tests to use whatever fallback it had been using before when python-secretstorage didn't find a provider for the org.freedesktop.secrets service.