I'm not able to reproduce this. It works for me with seahorse installed and uninstalled. When seahorse-daemon is running or not running. To see if seahorse is a red herring could you try:
$ ps aux |grep warren > before-fail.log
$ bzr viz
[traceback]
$ ps aux |grep warren > after-fail.log
$ bzr viz
[success]
$ ps aux | grep warren > after-success.log
If I'm right we'll see that seahorse-daemon is not running in the before-fail case and then it will be in one of the after cases. I'm curious to know whether it's started by the time we get to after-fail or not until after-success. Also if there's anything other process that gets started in the meantime... Maybe dbus itself is having to start?
Versions of dbus and seahorse here are:
dbus-1.2.4-2.fc10.i386
dbus-python-0.83.0-3.fc10.i386
seahorse-2.24.1-1.fc10.i386
I'm not able to reproduce this. It works for me with seahorse installed and uninstalled. When seahorse-daemon is running or not running. To see if seahorse is a red herring could you try:
$ ps aux |grep warren > before-fail.log
$ bzr viz
[traceback]
$ ps aux |grep warren > after-fail.log
$ bzr viz
[success]
$ ps aux | grep warren > after-success.log
If I'm right we'll see that seahorse-daemon is not running in the before-fail case and then it will be in one of the after cases. I'm curious to know whether it's started by the time we get to after-fail or not until after-success. Also if there's anything other process that gets started in the meantime... Maybe dbus itself is having to start?
Versions of dbus and seahorse here are: 1.2.4-2. fc10.i386 python- 0.83.0- 3.fc10. i386 2.24.1- 1.fc10. i386
dbus-
dbus-
seahorse-