[Bug 2045997] Re: vorta-0.8.12-2 failing autopkgtests with python-secretstorage as trigger

[Chris Peterson]

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.

** Tags added: update-excuse

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to python-secretstorage in Ubuntu.
https://bugs.launchpad.net/bugs/2045997

Title:
  vorta-0.8.12-2 failing autopkgtests with python-secretstorage as
  trigger

Status in python-secretstorage package in Ubuntu:
  New
Status in vorta package in Ubuntu:
  New

Bug description:
  autopkgtest log:

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/amd64/v/vorta/20231202_011527_de8c9@/log.gz

  The issue appears to be:

  > Message: 08:40:57.525: couldn't access control socket:
  /tmp/autopkgtest.ifpw2s/autopkgtest_tmp/vorta/run/keyring/control: No
  such file or directory

  which results in the test timing out.

  I can't reproduce this locally, building in a noble (w/ -proposed)
  schroot and running autopkgtest in a noble (no -proposed) schroot.

  Additionally, the other other autopkgtests for vorta-0.8.12-2 don't
  have the same issue. This only happens when triggered by python-
  secretstorage/3.3.3-2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-secretstorage/+bug/2045997/+subscriptions