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.
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") t.SbzXU7/ autopkgtest_ tmp/vorta/ run/keyring/ control: No such file or directory other_daemon: 0dbus-daemon[2104]: [session uid=1000 pid=2104] Successfully activated service 'org.freedeskto p.secrets' gnome.keyring. SystemPrompter' requested by ':1.2' (uid=1000 pid=2110 comm="/ usr/bin/ gnome-keyring- daemon --start --foreground" label="unconfined") usr/libexec/ gcr-prompter" label="unconfined") a11y.atspi. Registry' requested by ':1.0' (uid=1000 pid=2117 comm="/ usr/libexec/ gcr-prompter" label="unconfined") keyring. SystemPrompter' atspi.Registry' atspi.Registry
378s ** Message: 22:28:34.588: couldn't access control socket: /tmp/autopkgtes
378s discover_
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Activating service name='org.
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Activating service name='org.a11y.Bus' requested by ':1.3' (uid=1000 pid=2117 comm="/
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Successfully activated service 'org.a11y.Bus'
378s dbus-daemon[2125]: Activating service name='org.
378s dbus-daemon[2104]: [session uid=1000 pid=2104] Successfully activated service 'org.gnome.
378s dbus-daemon[2125]: Successfully activated service 'org.a11y.
378s SpiRegistry daemon is running with well-known name - org.a11y.
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.