Bug 498138
| Summary: | bzr viz always fails first attempt, succeeds second | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Warren Togami <wtogami> |
| Component: | bzr-gtk | Assignee: | Toshio Ernie Kuratomi <a.badger> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | a.badger, shahms |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-11-11 16:43:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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
This looks like the upstream bug. Trying the patch proposed here: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cbb631e240905260124h7fefe79btb0fdf911c96e7b64%40mail.gmail.com%3E Built for RawHide. Leaving this open until we see if upstream comes up with what the problem is: http://koji.fedoraproject.org/koji/taskinfo?taskID=1380071 This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Looks like when upstream figured out that it's a bug in seahorse, they reverted the workaround in bzr-gtk. Warren will try the patch in the seahorse bug http://bugzilla.gnome.org/show_bug.cgi?id=583356 If that works, we can see if the seahorse maintainer would be willing to inlude it in a bugfix release. Fixed in F-12 |
[warren@newcaprica ltsp-trunk]$ rpm -qa 'bzr*' bzr-1.14-0.2.rc1.fc11.x86_64 bzr-gtk-0.95.0-4.fc11.x86_64 [warren@newcaprica ltsp-trunk]$ bzr info Standalone tree (format: pack-0.92) Location: branch root: . Related branches: push branch: bzr+ssh://wtogami.net/%7Eltsp-upstream/ltsp/ltsp-trunk/ parent branch: bzr+ssh://wtogami.net/%7Eltsp-upstream/ltsp/ltsp-trunk/ [warren@newcaprica ltsp-trunk]$ bzr viz /usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/ui.py:224: DeprecationWarning: bzrlib.progress.ProgressBarStack was deprecated in version 1.12. self._progress_bar_stack = progress.ProgressBarStack(klass=widget) bzr: ERROR: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0 Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/bzrlib/commands.py", line 727, in exception_to_return_code return the_callable(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/bzrlib/commands.py", line 922, in run_bzr ret = run(*run_argv) File "/usr/lib64/python2.6/site-packages/bzrlib/commands.py", line 559, in run_argv_aliases return self.run(**all_cmd_args) File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/__init__.py", line 288, in run pp = start_viz_window(br, revids, limit) File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/__init__.py", line 256, in start_viz_window from bzrlib.plugins.gtk.viz import BranchWindow File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/viz/__init__.py", line 14, in <module> from branchwin import BranchWindow File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/viz/branchwin.py", line 18, in <module> from bzrlib.plugins.gtk.tags import AddTagDialog File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/tags.py", line 27, in <module> from bzrlib.plugins.gtk.revisionview import RevisionView File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/revisionview.py", line 32, in <module> from bzrlib.plugins.gtk import seahorse File "/usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk/seahorse.py", line 33, in <module> crypto = dbus.Interface(bus.get_object(BUS_NAME, CRYPTO_PATH), File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 244, in get_object follow_name_owner_changes=follow_name_owner_changes) File "/usr/lib/python2.6/site-packages/dbus/proxies.py", line 241, in __init__ self._named_service = conn.activate_name_owner(bus_name) File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 183, in activate_name_owner self.start_service_by_name(bus_name) File "/usr/lib/python2.6/site-packages/dbus/bus.py", line 281, in start_service_by_name 'su', (bus_name, flags))) File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 630, in call_blocking message, timeout) DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 0 bzr 1.14rc1 on python 2.6 (linux2) arguments: ['/usr/bin/bzr', 'viz'] encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_US.utf8' plugins: gtk /usr/lib64/python2.6/site-packages/bzrlib/plugins/gtk [0.95.0.final.1] launchpad /usr/lib64/python2.6/site-packages/bzrlib/plugins/launchpad [unknown] netrc_credential_store /usr/lib64/python2.6/site-packages/bzrlib/plugins/netrc_credential_store [unknown] *** Bazaar has encountered an internal error. Please report a bug at https://bugs.launchpad.net/bzr/+filebug including this traceback, and a description of what you were doing when the error occurred.