Wo klemmt es beim präzisen Schuppentier?
Was macht aus einem Rant einen berechtigten Rant? Details und Belege. Mit Hilfe von Debugging, Tracing und Logging des (Nicht-) Betriebs von Programmen und Einstellungen von Ubuntu 12.04 «Precise Pangolin» wird hier also nun „berechtigt gemeckert“.
Gwibber
Startet man das Programm im Terminal und protokolliert alle Ausgaben, so taucht folgender Fehler gleich gehäuft auf:
** (gwibber:3628): CRITICAL **: file messages.c: line 372: unexpected error: Fehler beim Aufruf von StartServiceByName für com.Gwibber.Messages: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process /usr/bin/gwibber-service exited with status 1 (g-dbus-error-quark, 25)
Und was tut dieses Programm namens gwibber-service? Auch das lässt sich protokollieren:
process 4319: arguments to dbus_connection_send_with_reply_and_block() were incorrect, assertion "timeout_milliseconds >= 0 || timeout_milliseconds == -1" failed in file ../../dbus/dbus-connection.c line 3485.
This is normally a bug in some application using the D-Bus library.
Traceback (most recent call last):
File "/usr/bin/gwibber-service", line 82, in <module>
dispatcher = dispatcher.Dispatcher(loop)
File "/usr/lib/python2.7/dist-packages/gwibber/microblog/dispatcher.py", line 264, in __init__
self.searches = storage.SearchManager(self.db)
File "/usr/lib/python2.7/dist-packages/gwibber/microblog/storage.py", line 89, in __init__
bus_name = dbus.service.BusName("com.Gwibber.Searches", bus=self.bus)
File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 131, in __new__
retval = bus.request_name(name, name_flags)
File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 303, in request_name 'su', (name, flags))
File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 651, in call_blocking
message, timeout)
dbus.exceptions.DBusException
Gibt es hier auch ein Debugging, bevor Programme beim Anwender landen? Oder liegt es an einem Bug in der Paketverwaltung mit möglicherweise inkompatiblen Paketversionen? Obiger Fehler im Modul connection.py fällt auch dem Programm gwibber-accounts, mit dem eigentlich die Microblogs eingerichtet werden, auf die Füße:
Loading plugin for statusnet
Loading plugin for facebook
Loading plugin for identica
Loading plugin for twitter
Traceback (most recent call last):
File "/usr/bin/gwibber-accounts", line 125, in <module>
accounts.GwibberAccountManager(selected_account=selected_account, condition=condition, message=message)
File "/usr/lib/python2.7/dist-packages/gwibber/accounts.py", line 60, in __init__
self.services = json.loads(self.gwibber.GetServices())
File "/usr/lib/python2.7/dist-packages/gwibber/lib/__init__.py", line 39, in GetServices
return self.service.GetServices()
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)
Eine Alternative, Turpial, stürzt zwar beim Versuch, sich mit Twitter zu verbinden ab, läuft dafür aber problemlos mit Identi.ca. Hier könnte es wohl an der Einschränkung der Twitter-API liegen.
Empathy
Hier lässt sich die Ursache für den andauernden Absturz von empathy-chat leider nicht so ganz nachvollziehen. Laut Fehlerbericht gibt es wohl eine Ausnahme.
OpenTTD
… schaltet zwar in den Vollbildmodus, danach wird allerdings der Bildschirm schwarz. Zurück zum Desktop gelangt man mit diversen Kombinationen von ESC, ALT+F4, STRG+ALT+Backspace oder kill. Vielleicht stürzt das Programm auch nach einer bestimmten Zeit erst ab. Folgende Fehlermeldung ließ sich protokollieren:
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 129 (XFree86-VidModeExtension)
Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
Value in failed request: 0x2c00003
Serial number of failed request: 16859
Current serial number in output stream: 16861
Eventuell könnte es an der Änderung der Auflösung liegen. Teilweise kann OpenTTD nämlich die Bildschirmauflösung noch ändern, wegen des Absturzes allerdings nicht wieder zurück. Leider ist mein Rechner hier nicht leistungsfähig genug, um mit der maximalen Auflösung zu spielen, weshalb das Umschalten notwendig ist. Das Problem dabei ist mir allerdings schleierhaft, denn unter Mac OS X klappt es einfach.
