Open shanttu opened 11 years ago
Hi,
Similar issue on fedora 18 with gnome shell:
Traceback (most recent call last):
File "/usr/bin/everpad", line 9, in
I'm happy with dirty scripting on boot. Start, wait, kill and restart.
And so what ? Does it works ?
edit your command of startup application to this: bash -c "sleep 30; everpad"
[Aporie@Aporie-laptop everpad]$ bash -c "sleep 30; everpad"
Traceback (most recent call last):
File "/usr/bin/everpad", line 9, in
Seems to be the same ...
Everpad not starting on boot. After killing and launching from terminal I get the following:
everpad u% ERROR:dbus.proxies:Introspect error on :1.213:/EverpadService: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. ERROR:dbus.proxies:Introspect error on :1.213:/EverpadService: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Traceback (most recent call last): File "/usr/bin/everpad", line 9, in
load_entry_point('everpad==2.4dev', 'gui_scripts', 'everpad')()
File "/usr/lib/pymodules/python2.7/everpad/pad/indicator.py", line 313, in main
pad.create_wit_attach(args.attach)
File "/usr/lib/pymodules/python2.7/everpad/tools.py", line 31, in wrapper
return getattr(self.interface, name)(_args, *_kwargs)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 70, in call*
return self._proxy_method(_args, _keywords)
File "/usr/lib/python2.7/dist-packages/dbus/proxies.py", line 145, in call__
keywords)
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.