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

/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

> 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

Eclipse stürzte mit der folgenden Fehlermeldung ab:

gehaxelt@LagTop ~/android/eclipse % ./eclipse 
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f51b3dacbd1, pid=10934, tid=139991535183616
#
# JRE version: OpenJDK Runtime Environment (7.0_51-b31) (build 1.7.0_51-b31)
# Java VM: OpenJDK 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libsoup-2.4.so.1+0x6fbd1]  soup_session_feature_detach+0x11
#
# Core dump written. Default location: /home/gehaxelt/android/eclipse/core or core.10934
#
# An error report file with more information is saved as:
# /home/gehaxelt/android/eclipse/hs_err_pid10934.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
./eclipse  21,39s user 1,54s system 85% cpu 26,746 total

Im Bugtracker von Eclipse gibt es dafür einen Workaround:

Man muss einfach in die „eclipse.ini“ folgenden String eintragen:

-Dorg.eclipse.swt.browser.DefaultType=mozilla

Danach sollte Eclipse wieder ohne Probleme laufen. Zumindest hatte das bei mir geholfen.

Viele Grüße,

~Sebastian

Was war das Problem?

Das Problem bestand darin, dass auf merkwürdige Weise eine Leerzeile am Anfang des RSS Feeds eingefügt wurde. Da der RSS-Feed im XML-Format vorliegt, und der XML-Parser sehr strikt mit Fehlern umgeht, wurde einfach der RSS Feed als „kaputt“ eingestuft.

Folgender XML-Fehler erschien als Diagnose:

This page contains the following errors:

error on line 2 at column 6: XML declaration allowed only at the start of the document
Below is a rendering of the page up to the first error.

Der Lösungsversuch

Nach ein wenig Googlen wusste ich, dass das Problem enstehen kann, wenn entweder vor „<?php“ bzw. nach „?>“ eine Leerzeile in einer PHP-Datei steht. Es wurden auch einige potentielle Fehlerquellen vorgestellt, wie z.B. wp-config.php. Nach einem Check dieser Dateien schien jedoch alles soweit in Ordnung. Die Suche ging weiter…

Mein nächster Verdacht bestand in einigen Plugins. Ich nutze Yoasts SEO Plugin zum Erstellen der Sitemaps bzw. des RSS-Feeds. Eine testweise Deaktivierung des Plugins brachte allerdings nicht den gewünschten Effekt.

Die Lösung

Nach einer längeren Zeit des Verzweifelns entschied ich mich auf Empfehlung von „@Yakuza112“ alle Plugins zu deaktivieren. Dieser Schritt zeigte einen ersten Erfolg, denn der Feed war wieder in Ordnung. In dem ich jedes Plugin einzeln aktivierte, konnte ich am Ende den Übeltäter identifizieren.

Es handelte sich um das Plugin „WP-Highlight.js“. Das Ergebnis überraschte mich ein wenig, denn das Plugin lief zuvor einwandfrei. Nun gut, ein weiterer Blick in die entsprechende PHP-Datei

wp-content/plugins/wp-highlightjs/wp_highlight.js.php

brachte die überflüssige Leerzeile hervor (Am Ende der Datei). Wenn man diese Zeile löscht, und die Datei abspeichert, dann funktioniert alles wieder wie es soll. WIN!

Fazit

Es ist erstaunlich, was so eine Leerzeile alles anrichten kann :( Außerdem sollte man daraus lernen, dass halbe Sachen nichts bringen ;)

An der Stelle nochmal ein „Entschuldigung!“ an alle Leser die in dem Zeitraum unseren Feed nicht nutzen konnten.

~ Sebastian