Bugfix Archives - Technik - Blogbasis.net https://technik.blogbasis.net/tag/bugfix Die Basis des freien Wissens – Technik Sat, 06 Dec 2014 20:48:14 +0000 de hourly 1 https://wordpress.org/?v=6.8.1 wicd-curses – Fix für „AttributeError: ‚Screen‘ object has no attribute ‚get_input_nonblocking'“ https://technik.blogbasis.net/wicd-curses-fix-fuer-attributeerror-screen-object-no-attribute-get_input_nonblocking-04-12-2014 https://technik.blogbasis.net/wicd-curses-fix-fuer-attributeerror-screen-object-no-attribute-get_input_nonblocking-04-12-2014#respond Thu, 04 Dec 2014 21:49:00 +0000 http://technik.blogbasis.net/?p=1273 Hallo Leute,

als Arch-User hat man öfters (eigentlich nicht so oft)  mit Problemen zu kämpfen. Seit dem letzten Update von python-urwid läuft „wicd-curses“ nicht mehr. Da laut Arch-Wiki „wicd“ nicht mehr weiterentwickelt wird, hab ich mich an einem (erfolgreichen) Fix probiert.

Der Bug

Es handelt sich um folgende Fehlermeldung:

$> wicd-curses 
Traceback (most recent call last):
 File "/usr/share/wicd/curses/wicd-curses.py", line 1063, in <module>
 main()
 File "/usr/share/wicd/curses/wicd-curses.py", line 995, in main
 ui.run_wrapper(run)
 File "/usr/lib/python2.7/site-packages/urwid/display_common.py", line 757, in run_wrapper
 return fn()
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 1003, in run
 app = appGUI()
 File "/usr/share/wicd/curses/wicd-curses.py", line 591, in __init__
 self.update_status()
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 734, in update_status
 self.set_status):
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 161, in check_for_wireless
 ('$C', ip))
 File "/usr/share/wicd/curses/wicd-curses.py", line 781, in set_status
 self.update_ui()
 File "/usr/share/wicd/curses/wicd-curses.py", line 88, in wrapper
 return func(*args, **kargs)
 File "/usr/share/wicd/curses/wicd-curses.py", line 930, in update_ui
 input_data = ui.get_input_nonblocking()
AttributeError: 'Screen' object has no attribute 'get_input_nonblocking'

Nach einem Blick in den Quellcode (Zeile 930) und etwas Backtracking der Funktionen/Variablen stößt man auf:

import urwid.raw_display
ui = urwid.raw_display.Screen()

Der Fix

Werfen wir doch mal einen Blick in die Dokumentation: http://urwid.org/reference/display_modules.html

Dort wird nur noch „get_input()“ für das raw_display genannt, so dass die Eingabe blockierend verarbeitet wird. Mein erster Gedanke war, einen Thread für die Eingabe zu schreiben, aber dann las ich diese Zeile:

If there is no input pending it will wait before returning an empty list. The wait time may be configured with the set_input_timeouts function.

Also habe ich einfach die dazu passende Zeile eingebaut:

ui.set_input_timeouts(max_wait=0, complete_wait=0)

Der Patch

Noch zwei weitere kleine Änderungen waren nötig. Am Ende kommt dann folgender Patch raus:

--- /usr/share/wicd/curses/wicd-curses.py	2013-08-20 15:09:54.000000000 -0400
+++ /tmp/wicd.py	2014-12-05 23:32:05.303349880 -0500
@@ -927,9 +927,11 @@
         if not ui._started:
             return False
 
-        input_data = ui.get_input_nonblocking()
+        # input_data = ui.get_input_nonblocking()
+        ui.set_input_timeouts(max_wait=0)
+        input_data = ui.get_input()
         # Resolve any "alarms" in the waiting
-        self.handle_keys(input_data[1])
+        self.handle_keys(input_data) # [1]
 
         # Update the screen
         canvas = self.frame.render( (self.size),True )

Diesen speichert man sich als Datei unter „/tmp/wicd.patch“ und führt danach folgendes Kommando aus:

sudo patch /usr/share/wicd/curses/wicd-curses.py < /tmp/wicd.patch

Danach sollte „wicd-curses“ wieder laufen.

Die Mankos

Dadurch, dass das Einlesen der Tastendrücke nicht mehr wirklich im Hintergrund läuft, kam es bei der Nutzung der „ESC“-Taste zu Problemen. Diese wurde erst nach einem weiteren Tastendruck (z.B. Pfeil-runter) verarbeitet. Aber nunja, besser als ein kaputtes wicd-curses ist es allemal :)

~ Sebastian

]]>
https://technik.blogbasis.net/wicd-curses-fix-fuer-attributeerror-screen-object-no-attribute-get_input_nonblocking-04-12-2014/feed 0
Arch – undefined symbol: cairo_surface_set_device_scale https://technik.blogbasis.net/arch-undefined-symbol-cairo_surface_set_device_scale-16-10-2014 https://technik.blogbasis.net/arch-undefined-symbol-cairo_surface_set_device_scale-16-10-2014#respond Thu, 16 Oct 2014 21:42:32 +0000 http://technik.blogbasis.net/?p=1231 Hallo Leute,
nach dem Einspielen der Updates erhielt ich beim Starten von GTK-Anwendungen folgende Fehlermeldung:

/usr/lib/libgdk-3.so.0: undefined symbol: cairo_surface_set_device_scale

Wie immer, lässt sich das Problem leicht beheben.

Die libgdk wird u.a. vom Paket namens „cairo“ bereitgestellt. Nach ein wenig googlen, stieß ich auf die vorteilhaften Hinweise, ich solle meine Pakete aktualisieren.

Es stellte sich heraus, dass ich das Paket „cairo-ubuntu“ aus dem AUR nutzte. Dieses ist jedoch als „orphaned“ markiert und lässt den o.g. Fehler entstehen.

Um das Problem zu beheben, braucht man nur das Paket „cairo“ zu installiere, um „cairo-ubuntu“ damit zu ersetzen. Auf die Konfliktmeldung kann einfach mit „j“ geantwortet werden.

sudo pacman -S cairo

Problem gelöst ;)

~ Sebastian

 

]]>
https://technik.blogbasis.net/arch-undefined-symbol-cairo_surface_set_device_scale-16-10-2014/feed 0
Arch Java – Zu viele Ebenen aus symbolischen Links https://technik.blogbasis.net/arch-java-zu-viele-ebenen-aus-symbolischen-links-06-09-2014 https://technik.blogbasis.net/arch-java-zu-viele-ebenen-aus-symbolischen-links-06-09-2014#respond Sat, 06 Sep 2014 13:14:14 +0000 http://technik.blogbasis.net/?p=1173 Ich wollte nach einer Reihe Updates ein Java-Programm starten und wurde von folgender Fehlermeldung begrüßt:

> java 
/usr/bin/java: Zeile 2: /usr/lib/jvm/default/bin/java: Zu viele Ebenen aus symbolischen Links
/usr/bin/java: Zeile 2: exec: /usr/lib/jvm/default/bin/java: Kann nicht ausführen: Zu viele Ebenen aus symbolischen Links

Der Fix ist schnell angewandt.

/usr/bin/java ist zunächst nur ein Link:

> file /usr/bin/java
/usr/bin/java: symbolic link to `/usr/lib/java-common-wrapper'

Die verlinkte Datei ist ein Shell-Script:

> file /usr/lib/java-common-wrapper 
/usr/lib/java-common-wrapper: Bourne-Again shell script, ASCII text executable
> cat /usr/lib/java-common-wrapper 
#!/bin/bash
exec "${JAVA_HOME:-/usr/lib/jvm/default}/bin/${0##*/}" "$@"

Ein Blick auf  /usr/lib/jvm/default bringt die Erkenntnis, dass der symbolische Link kaputt ist:

> file /usr/lib/jvm/default 
/usr/lib/jvm/default: broken symbolic link to `default'

Diesen Link müssen wir reparieren und auf das „java-7-openjdk“-Verzeichnis zeigen lassen:

sudo mv default default.bak
sudo ln -s java-7-openjdk default

Jetzt passen die symbolischen Links wieder und man kann „java“ ausführen.

~ Sebastian

]]>
https://technik.blogbasis.net/arch-java-zu-viele-ebenen-aus-symbolischen-links-06-09-2014/feed 0
Upgrade auf Piwik 2.2.0: Weiße Seite nach dem Upgrade https://technik.blogbasis.net/upgrade-auf-piwik-2-2-0-weisse-seite-nach-dem-upgrade-18-04-2014 https://technik.blogbasis.net/upgrade-auf-piwik-2-2-0-weisse-seite-nach-dem-upgrade-18-04-2014#respond Fri, 18 Apr 2014 18:51:17 +0000 http://technik.blogbasis.net/?p=1097 Hallo Leute,

ich habe eben Piwik auf die aktuellste Version 2.2.0 geupdated und in zwei Fällen lief das Update nicht korrekt durch. Man sah nur noch eine weiße Seite und nichts passierte mehr. Das Problem lässt sich aber leicht fixen.

Wenn man ins Errorlog schaut, dann findet man dort eine ähnliche Zeile:

PHP Fatal error:  Class 'ComposerAutoloaderInitadfdb97940eb3fa831axxxxxxxx' not found in /var/www/virtual/gehaxelt/piwik.blogbasis.net/vendor/autoload.php on line 7

In der fehlerhaften Datei (/vendor/autoload.php) findet man die folgende Zeile:

return ComposerAutoloaderInitadfdb97940eb3fa831xxxxxxxxxxxxx:getLoader();

Wie man erkennt, stimmen diese beiden Klassen überein. Nur scheinen diese falsch zu sein bzw. nicht mehr zu existieren.

Den richtigen Klassennamen findet man in der „/vendor/composer/autoload_real.php“.

// autoload_real.php @generated by Composer
class ComposerAutoloaderInitf46e47e7b0ce25ef7dxxxxxxx

Man kopiert sich diesen Klassennamen und ersetzt den alten in der „/vendor/autoload.php“ damit.

Das sollte dann so aussehen:

return ComposerAutoloaderInitf46e47e7b0ce25ef7d1d8dxxxxx::getLoader();
//return ComposerAutoloaderInitadfdb97940eb3fa831a2c3xxxxx::getLoader();

Jetzt kann man Piwik neuladen und alles sollte wie gewohnt funktionieren.

~ Sebastian

]]>
https://technik.blogbasis.net/upgrade-auf-piwik-2-2-0-weisse-seite-nach-dem-upgrade-18-04-2014/feed 0